慢雾 SlowMist

8月28日、香港ではステーブルコイン、スマートエージェント決済、AIエージェント、ビットコインのインフラに焦点を当てた複数の業界イベントが開催されます。ブロックチェーン・エコシステムのセキュリティに注力する企業として、SlowMistは香港で開催される複数のイベントにて登壇・参加し、自社のセキュリティ研究と実践を踏まえ、業界パートナーと関連テーマについて交流を行います。
霧を抜けて信頼できる決済へ｜世界のステーブルコインのコンプライアンスとスマートエージェント決済の新たなフロンティア
日時：8月28日 09:30–12:30
場所：香港 CAI Building
登録：https://luma.com/0c4fawzv
8月28日午前、SlowMistはME Groupとともに香港で「霧を抜けて信頼できる決済へ｜世界のステーブルコインのコンプライアンスとスマートエージェント決済の新たなフロンティア」という業界交流イベントを開催します。会場には、ステーブルコイン、決済、AIエージェント、コンプライアンス、安全などの分野から、エコシステムのパートナーが一堂に会し、世界のステーブルコインのコンプライアンスと活用、スマートエージェント決済の技術進化、そして信頼できる決済の仕組みにおける安全性の構築について意見交換が行われます。

背景
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 が取引に参加し始めるとき、安全で信頼できる取引メカニズムをどのように構築するか――これらは業界が向き合う必要がある新たな課題となっています。

著者：Johan & Lisa
編集：77
この記事は人とAIの共作です。AIを読み込めば再現できます。
背景
2026年7月30日、オンチェーン上である一群のアドレスが連続して外部へ送金しました。41分間で、1,196件の単独署名アドレスが空になり、約1,082BTCが消失しました。これは単なる第一波です。8月上旬までに確認された損失は少なくとも1,719BTCで、約1.11億ドルに相当します。関係したアドレスは5,200以上で、攻撃の前後で3〜4波に分かれていました。
最も人を混乱させるのは、これらのウォレットの状態がどうなっているのかという点です。資金の大半はコールドウォレットに眠ったままで、数か月、数年まったく動かされていないものもあります。失われたのは、その「秘密鍵の層」です。秘密鍵はすべて Coldcard のハードウェアウォレットによって生成されており、所有者は追加でダイスのエントロピーをクリックしたこともなく、BIP-39 のパスフレーズも開いていません。被害に遭ったのはいずれも、最も手間が少ない使い方をしていたケースです。

近日，慢雾科技（SlowMist）与 AgentOn 正式达成战略合作伙伴关系。双方将围绕 AI Agent 安全能力建设、安全评估体系及生态实践展开合作，共同推动 AI Agent 生态朝更加安全、可信的方向发展。
背景
AI Agent 从演示逐步走向真实场景的过程中，Agent 的安全问题正成为整个行业最关注的话题。与传统 Web3 产品相比，AI Agent 具备调用工具、访问数据、管理钱包、执行交易等能力，一旦出现安全问题，影响范围将更为广泛。

背景
最近、MistEyeは、採用を餌にしてWeb3従事者を狙う情報窃取攻撃の事例を確認しました。攻撃者は採用担当者を装って求職者と接触し、面接に関するやり取りを行った後、標的を誘導してrelay.lcにアクセスさせ、オンラインでのコミュニケーションを開始させます。
このサイトは、自らを「Relay」という名称のAI会議コラボレーションツールとして偽装し、リアルタイム文字起こし、共同メモ、AIによる要約、アクションアイテム、クロスプラットフォームのクライアントなどの機能を提供できると主張しています。リモート面接に参加している人にとっては、この説明も不自然ではありません。次の面談段階に進むために「会議ソフト」をインストールする——これは採用プロセス上の通常の準備に見えるからです。relay.lcの公開ページも、まさにこれらの機能を中心に製品イメージを構築しており、WindowsおよびmacOSのダウンロード導線を用意しています。

ミスト（慢雾）セキュリティチームが正式に MistEye DNS Guard をリリースしました。Rust で実装された軽量なローカル DNS リレーおよび脅威監視ツールで、macOS および Linux ホスト向けに、システム DNS の引き継ぎ、ドメイン名とパブリック IP の検出、プロセスの外部通信の観察、悪性イベントの保存、Webhook によるアラート機能を提供します。特に、悪性ドメインへのアクセス、DNS 応答での悪性指標の返却、プログラムによる悪性 IP への直結など、よくあるリスクシナリオを重点的にカバーします。
MistEye DNS Guard は DNS フォワーディングと、その後の脅威検知を相互に切り離します。問い合わせは通常どおり完了し、ドメイン名と IP はバックグラウンドで非同期に MistEye の検知へ投入されるため、セキュリティ検知が通常のネットワークアクセスに与える影響をできるだけ抑えます。

背景
最近、SlowMist セキュリティチームは、複数のチャネルを通じて数か月にわたり継続して実施されたフィッシング攻撃の事案を捕捉しました。攻撃者は複数の Web3 ウォレットブランドになりすましていました。
私たちは最初に、2通のフィッシングメールを通じてこの件に気づきました。攻撃者はそれぞれ Keystone と OneKeyになりすまし、「利用規約の更新」「アカウントの検証」「規制コンプライアンス」などの理由で、受信者に期限内に手続きを完了するよう求めます。メール内のボタンは被害者を偽の DocuSign ページへ誘導し、「デスクトップ署名プログラム」と称するものをダウンロードさせることで誘導します。

背景
2026年7月、金融活動作業部会（FATF）が第7回（仮想資産と仮想資産サービス提供者の規制に関する特別の進捗報告）を公表[1]。
FATFは、2025年以来、仮想資産に関わる違法活動がより複雑化し、融合する傾向が見られると指摘している。具体的には、組織犯罪グループに関連する詐欺拠点の運営、「豚養（ピギーブッチャリング）」詐欺、北朝鮮に関連するサイバー窃盗、テロ資金供与／拡散金融（TF/PF）、制裁の回避、ならびに越境のマネーロンダリングなどが含まれる。ステーブルコイン、非ホスティング型ウォレットによる個別間（P2P）取引、オフショアVASP、店頭（OTC）ブローカー、クロスチェーン・ツール、そしてDeFiに関連する活動は引き続き重大なリスクを構成しており、公私の連携強化、監視の強化、ならびに各法域および民間部門が講じる具体的なリスク低減措置の必要性が浮き彫りになっている。

背景
近日、MistEye は、採用を餌にして開発者を狙う悪意あるコードの投下を行う活動を確認しました。攻撃者はまず LinkedIn 経由で開発者に連絡し、Web3 プロジェクトの採用担当者を装います。職務経験や面接の段取りをやり取りした後、相手は標的に GitHub のリポジトリを送付し、そこに「面接前に体験すべき MVP がある」と称します。
チャット履歴によると、攻撃者はまず標的の職務経験や製品経験を尋ね、その後、今後の面接の予定について話し合います。その後、相手は具体的な問題について面接で話し合うためには、事前に製品を体験する必要があると述べ、それを口実に、標的が運用しているリポジトリ内のプロジェクトを実行するよう求めます。

Open VSX から削除された悪意のある拡張機能であるにもかかわらず、現在も TRAE IDE の拡張マーケットからダウンロード可能です。この拡張機能は、よくある Solidity 言語対応プラグインを装っており、パッケージ名は juannegro.solidity です。2026 年 7 月 18 日時点で、TRAE のプラグインマーケット API は当該拡張機能の 0.0.189 バージョン（VSIX ファイル）を依然として提供しています。
逆向解析の結果、この拡張機能は実際には、クロスプラットフォーム（Windows、macOS、Linux）対応の悪意あるペイロード投下ツール（ドロッパー）であることが判明しました。IDE の起動後に自動で実行され、システム内にユーザーレベルの自動起動項目を作成したうえで、イーサリアムのスマートコントラクトを通じて、後続の悪意あるコードのダウンロードアドレスを取得します。あるいは、リモート制御用シェルのアドレスに直接接続します。

事件の背景
きっかけは、山哥（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 でトラフィック捕捉の3経路を使い、相互に交差検証した。そして、コミュニティが既に分析した 0.2.93 とバージョン比較も行った——アップロード機構は2つのバージョンで完全に一致していた。

近日、香港のデジタルポート（数码港）で開催された第1回 Web4.0 とエージェント革新サミットおよびデジタルポート OPC Hub の始動式において、デジタルポートは正式に Web4.0 とエージェントの安全連盟の設立を発表しました。SlowMist（スローミスト）は連盟の創設メンバーの一人として、連盟パートナーとともに Web4.0 とエージェントの安全に関する標準およびベストプラクティスの構築を推進し、信頼できる Web4.0 エコシステムの発展に向けて専門的な力を提供します。
Web4.0 とエージェントの安全連盟
随着 Agentic AI 与区块链技术不断融合，智能体正逐步具备自主执行任务、调用工具及链上交互等能力，在提升生产效率和应用创新的同时，也带来了プロンプトインジェクション、サプライチェーン攻撃、権限の悪用、AIエージェントのトラストチェーン等の新しいセキュリティリスク。

背景
近日、MistEye の安全監視システムが、macOS 上で動作するスパイウェア型の窃密マルウェアを検知しました。慢霧セキュリティチームはすぐに分析を開始しました。
窃取リストから見ると、このサンプルは重点の定まらないデータ収奪を行っているようです。macOS Keychain、Safari の Cookie、Apple Notes、Telegram Desktop のローカルデータ、そして十数種類の暗号ウォレットのデータベースがすべて対象リストに含まれています。
前文《Google Sites 社群申请钓鱼与 macOS 窃密木马分析》 では、「マルウェアは何を盗んだのか」にお答えしました。しかし、ファイルがコピーされたことは、アカウントがすでに侵害されたことと同義ではありません。ウォレットのデータベースが持ち去られたからといって、シードフレーズが漏えいしたとは限りません。そこで本記事ではさらに踏み込みます。

背景
今回の調査の出発点は、一見すると普通の開発プロセスでした。つまり、開発者が Injective の公式 SDK をインストールし、ウォレットを生成したり、ニーモニックをインポートしたり、あるいは既存の秘密鍵を SDK のインターフェイスに渡したりするという流れです。プログラムのインストール段階ではすべて問題なく、ウォレット操作も正常に結果が返ることがあります。ですが、その一方で、プログラムのバックグラウンドでは、通常の業務ロジックには存在しないネットワークリクエストが 1 つ追加されていました。
近日、安全研究会社 Socket は、npm エコシステムに対する脅威のハンティング中に、@injectivelabs/sdk-ts バージョン 1.20.21 に異常な挙動があることを発見しました。SlowMist MistEye のセキュリティ監視システムも、この悪意あるサプライチェーン攻撃の事例を同様に検知しています。分析の結果、当該サンプルは攻撃者が作り直した模倣パッケージではなく、悪意あるコードを含む正規の SDK ビルド成果物であることが確認されました。関連する公開背景については (Compromised Injective SDK npm Package) を参照してください。

概要
2026 年 7 月 8 日、Bruce Xu（ @brucexu_eth ）は、BuilDAO / Builder コミュニティの申請ページを装ったフィッシングリンクを報告しました。攻撃者はページを Google Sites 上でホスティングし、sites.google.com の信頼できる外観を利用してユーザーの警戒心を低下させました。ページ前半ではコミュニティ申請フォームを模し、居住地、身分、プロジェクトのリンク、参加への要望などの情報の入力を求めます。送信後は通常の審査プロセスに進まず、偽のセキュリティ検証ページへリダイレクトされます。
第 2 段階のページで、攻撃者は API エラー 401、OAuth 2.0、macOS のセキュリティ検証などの技術用語を偽装し、ユーザーに .scpt ファイルをダウンロードさせる、または Terminal Command をターミナルに貼り付けて実行させます。デコードすると、このコマンドは攻撃者のサーバーから unix32385485 という名前の macOS Mach-O トロイの木馬をダウンロードし、バックグラウンドで実行することが確認できます。

SlowMist、メンバー募集！
もし興味があるなら、ぜひ続きを読んでください。
/ 募集職種 /
職種名：AMLプロダクトGTMマーケティング責任者
勤務地：厦門／深圳／香港（選択可）
給与・待遇：要相談（経験、能力、これまでの実績を総合評価）
このポジションはどんな仕事ですか？
AMLプロダクトGTMマーケティング責任者として、SlowMistのAMLプロダクト（MistTrack / SlowMist KYT）の市場投入戦略、プロダクトポジショニング、ブランディング発信、営業支援、成長・転換を担当し、プロダクトの市場影響力を継続的に拡大することに貢献します。

TrackAgent：実際の盗難事件に向けたオンチェーン AI 情報官
TrackAgent は、オンチェーンでの盗難資金の追跡シーン向けに開発した AI Agent 分析システムです。これは従来型のアドレス照会ツールでも、固定手順を実行するだけの自動化スクリプトでもありません。むしろ、オンチェーン上の探偵のように、案件の目的に基づいて資金経路を継続的に分析し、重要なノードを特定し、追跡の方向性を判断し、複雑なオンチェーンの挙動を理解しやすく、検証可能で、さらに前に進められる手がかりとして整理します。
ユーザーが盗難アドレス、ハッカーのアドレス、取引ハッシュ、盗まれた通貨の種類、金額、事件発生時刻を送信すると、TrackAgent はまず資金の起点を照合し、その後ブロックチェーン上の経路に沿って段階的に追跡します。資金が取引所、DEX、クロスチェーンブリッジ、ミキサー、または集約アドレスに入ったとき、Agent はこれらの重要なノードを特定しようとします。資金が両替、クロスチェーン、分割、または再集約された場合にも、Agent は単一の取引の表面で止まらず、引き続き次の経路を探し続けます。

分量の都合により、この記事では分析レポートの主要な内容のみを列挙します。完全版は以下のリンクからアクセスできます：
https://drive.google.com/file/d/1zfngTKU3_dr10QqXKsQNe1kMhHtfQ7J0/view
一、概要
2026年上半期、ブロックチェーン業界は継続的に急速な発展を遂げる一方で、安全上の脅威と規制環境がさらに進化し、全体のリスク構造は体系的な拡張傾向を示しています。DeFi、クロスチェーン基盤インフラ、AI Agentなどのアプリケーションが加速して実装されるにつれ、攻撃対象領域は継続的に拡大し、安全リスクはスマートコントラクトから開発者エコシステム、サプライチェーン、端末のインタラクション環境、そしてユーザーの認可に関わる信頼のリンクへと広がっています。同時に、AI技術の普及はソーシャルエンジニアリングおよび自動化攻撃の参入障壁を大幅に引き下げ、攻撃活動は専門化・大規模化・継続化へと進化を促しています。