先说没泄露，Chainalysis改口：所有用户实时令牌被看光

区块链分析公司 Chainalysis 的客户名单里有 FBI、美国移民和海关执法局、美国空军、微软、Coinbase 和巴克莱。这家公司替政府和交易所追踪加密货币交易、做合规筛查。2026 年 10 月 30 日，它发布第一份声明，说调查没有发现"未经授权访问调查内容、认证凭证或会话令牌"的证据。

五天后的 11 月 4 日，同一页面换了一句话：调查发现"包括姓名、用户名、密码哈希和所有 Chainalysis 用户的实时令牌在内的某些客户信息，已暴露给恶意行为者"。

同一份事件，前后两种说法。10 月 30 日说会话令牌没事，11 月 4 日把实时令牌列进了暴露清单。这中间的落差，是整件事最该被盯着看的地方。

从"已控制"到"必须轮换"

两份声明之间夹着两个操作决定。11 月 2 日，公司以防万一，把 Reactor 和 Data Solutions 下线。11 月 4 日，检测到异常活动后，KYT 界面和 API 连同其他地址筛查产品、登录页一起下线——这一刻，一个合规产品停止为客户筛查交易。

公司描述得最仔细、解释得最少的，是那起"路径上攻击"（on-path attack）。11 月 4 日它告诉客户，这类攻击暴露了一部分客户密码，攻击路径已被控制并修复，账户作为预防措施被锁定。

路径上攻击，指的是对手坐在两方通信的路径中间。接下来的问题是：入侵发生在哪一段，被截获的流量是否加密。Ars Technica 在 11 月 6 日把这两个问题都提给了公司，报道称两个都没得到回答，还有第三个：调查两天前就发现了全部客户个人信息暴露，为什么到周三才披露。Chainalysis 对 Ars 表示，只通过博文中的声明置评。

"已控制"对客户有实际含义：修复路径能挡住新的截获，但已被抓到的凭证仍然需要吊销或替换。所以同一次更新要求用户在所有复用过该密码的地方重置密码，后续更新则把重点从改密码转向轮换 API 密钥。

实时令牌意味着什么

密码哈希是派生值，攻击者可以离线慢慢破解；实时令牌是一把正在生效的钥匙，谁拿着它，在过期或被吊销之前都能用。

Chainalysis 说暴露范围包括所有用户的实时令牌。对客户来说，有用的问题是：这些令牌被允许做什么，活了多久。公司用一条要求回答了后半截——在交易重新登记之前，必须先轮换密钥。

另一半影响面在于谁持有账户。对一家合规供应商而言，元数据本身就是敏感资产，哪怕调查内容没被打开：谁在什么时候筛查了哪个地址，就是关于一项调查的情报。

公司自己的说法是，没有证据表明调查数据被访问、归因数据被篡改。10 月 30 日的声明说，没有发现调查内容（如图谱、笔记、案件）被访问的证据；11 月 4 日的更新重复了这一点。持有这份保证的客户应当把它读作关于平台记录存储的陈述，而把令牌暴露当作另一个独立问题来处理。

恢复顺序本身就是答案

恢复指引是整起事件里最可迁移的部分，因为它规定了一个顺序：客户先提交可信 IP 地址供公司加入允许列表，然后重置密码、轮换 API 密钥，之后才能登记交易。

这个顺序存在，是因为只轮换会留下缺口。攻击者手里有实时令牌时，改密码只换掉一个凭证，令牌在签发系统吊销它之前照样能用；允许列表在凭证变更的同时收窄了网络路径。顺序还把恢复绑定在客户的可信网络路径上，减少对一个可能已经躺在别人日志里的共享密钥的依赖。

有两个细节值得任何想照搬这套流程的人注意。公司锁定了受影响账户，并要求用户直接访问登录页——这关上了每次事件中都会打开的密码重置钓鱼窗口。它还提醒密码重置不会立刻生效，因为登录页本身就在故障范围内。当身份、应用和网络控制分属三个不同团队时，这类顺序问题就会冒出来。

攻击者一侧的行业背景

Chainalysis 把攻击者描述为使用了进攻性智能体技术。相关报道补上了这个词在实践中的含义：《黑客新闻》引用微软对一个名为 ARTEX 的智能体框架的描述，该框架在公开仓库里搜索暴露的密钥；微软报告了其中一个案例，智能体从扫描 GitHub 到从 Azure Key Vault 窃取数据，用了五分钟，相关活动被评估为自 2026 年 8 月起持续进行。

同一篇报道还点名了同期披露 AI 驱动攻击的其他公司，包括 Chainstack、OpenCode、Warp 和 WorkOS，并描述了一个转售市场：被盗模型凭证的访问权被代理给付费客户。对防守方来说，方向很重要：过去需要有人坐在键盘前做的凭证发现，现在以机器速度运行，而值得拿走的凭证包括 AI 服务的 API 密钥。

对加密货币行业之外的团队，教训落在令牌清单上。一个智能体找到一个有效令牌，就能直接使用它授予的访问权；这个令牌的价值取决于范围和寿命，而这两项是团队在事件之前做的决定、在事件之后要审计的东西。

现在能自查的三件事

从这起事件可以引出三项检查，用的都是现有控制手段：

• 令牌清单：列出体系内签发的每一个长期 API 密钥和服务令牌，记录其范围，缩短那些没人能说清为何要活这么久的令牌。
• 供应商范围审查：尤其是持有身份或筛查数据的供应商，供应商出事，暴露会转移给客户。
• 吊销路径演练：从没在时间压力下轮换过生产 API 密钥的团队，会在事件中发现自己那套顺序问题。

记录上还留着两个未解问题。公司没有说明路径上的位置是怎么拿到的，也没有说明那段流量是否加密；它也没有描述自己所说的那些智能体。在这些答案出现之前，对客户而言安全的假设是：令牌在暴露到吊销之间是可用的，这些令牌授权过的任何操作都值得复查。