![[Web3] Bitget 被攻击事件复盘：私钥没泄露，钱是怎么走出去的](http://pic.xiahunao.cn/yaotu/[Web3] Bitget 被攻击事件复盘：私钥没泄露，钱是怎么走出去的)
💡交易所被盗这件事，过去两年大家已经看得有点麻木了：报个数、说句"已排除私钥泄露"、然后把提现关掉几天。
但 2026 年 9 月这次 Bitget 的事件，我觉得值得后端工程师重新看一遍。原因不是金额——约 3.88 亿美元在交易所被盗案里排不进第一梯队——而是它的攻击路径完全没有走"偷钥匙"这条路。攻击者用的是 Bitget 自己采购的某第三方安全产品里的零日漏洞，拿到高级内部凭证，然后往钱包后端里注入伪造的提现指令。这些指令被当成正常提现处理了。
说白了，钱不是被"偷"出去的，是被系统自己"提"出去的。
所以这一篇我想把 Bitget 官方公布的那条链路摊开讲一讲：五个步骤分别落在哪一层、风控为什么形同虚设、官方那句"已排除私钥泄露"到底排除了什么、以及一个做后端和安全的人能从这次事件里带走什么。
1. 先把时间线摆正：处置窗口是 3 小时 13 分
很多二手报道把这次事件写成"一夜之间被掏空"，但官方时间线其实给得很细，而且第一段恰恰是最关键的：从第一次未授权转移到签名服务被关闭，只有三个多小时。
下面这张图是 Bitget 学院页（页面标注更新于 2026 年 10 月 14 日）里给出的时刻，全部 UTC+8。
把关键节点单独列一遍：
| 时刻（UTC+8） | 发生了什么 | 这一动的性质 |
|---|---|---|
| 9/24 02:31 | 部分热钱包、温钱包基础设施首次发生未授权资产转移 | 攻击已经得手 |
| 9/24 03:05 | 对账系统发现重大差异，风控自动拦截全平台提现请求 | 系统自己发现的，不是人 |
| 9/24 03:14 | 启动最高级别应急响应 | 组织响应 |
| 9/24 03:40 | 开始采取控制措施 | 止血 |
| 9/24 04:40 | 私钥泄露尚未排除，钱包团队把资金转移至冷钱包 | 在不确定下的保守动作 |
| 9/24 05:44 | 钱包提现服务关闭，包括签名服务，提现相关访问权限被隔离 | 真正掐住源头 |
这里最值得注意的是 03:05 那一步。它不是安全团队告警，是对账系统发现账不平。也就是说，攻击者伪造的提现指令在"指令层"是合规的——它进了提现流程、过了风控；只有在钱真的动了、账对不上的时候，才暴露出来。
Q1：为什么 04:40 要先转冷钱包，而不是先查攻击者？
因为那一刻"私钥有没有泄露"还是个未知数。官方时间线里明确写了这个前提：因尚未排除私钥泄露可能，所以先把资金转进冷钱包。这是一个典型的在信息不完整时按最坏假设行动的决策——如果热钱包的签名能力已经暴露，留在里面的每一分钟都在增加风险，而转冷这个动作本身不需要先搞清楚攻击者是谁。
顺带说一句，04:40 转冷、05:44 关签名服务，这两个动作的顺序也说明问题：转冷是"把资产挪出危险区"，关签名是"把危险区本身断电"。前者保护存量，后者防止继续失血。
2. 攻击路径：五步，没有一步碰到私钥
这是整件事里技术含量最高、也最容易在传播中被写歪的一段。好在 Bitget 官方给出的根因描述相当具体，可以直接照着拆。
官方表述拆开是这几层：
- 攻击者利用了 Bitget 使用的某第三方安全产品中的零日漏洞，取得高级内部凭证；
- 用这些凭证访问钱包相关后端服务器；
- 直接注入伪造的提现指令；
- 这些指令被当作正常提现处理，使资金从热钱包与温钱包转出，并在正常提现记录生成前绕过风控验证；
- 完成转移后，删除了与伪造指令有关的痕迹。
第 4 步是真正的要害。我把它单独说一下，因为这里面有一个所有做业务系统的人都熟悉的结构性问题：
风控校验的问题： 这笔提现请求合不合规？（金额、限额、地址、频率） 攻击者绕开的问题：这条请求是不是从合法业务流程里产生的？前者是业务规则校验，后者是指令来源可信性校验。这两件事在很多系统里被混在一起做——只要请求带着合法的会话凭证进来、字段都过得了规则，风控就认为它没问题。但攻击者拿到的恰恰就是"合法的会话凭证"，甚至是高级内部凭证。这时候风控越自动化，放行得越干脆。
第 5 步"删痕迹"也值得注意。它说明攻击者清楚自己走的是正常提现通道，只要提现记录生成出来，事后一定能查到；所以要在记录生成之前把伪造指令的残留抹掉。官方也承认这一点增加了根因识别难度——从 02:31 发现到 9 月 25 日 16:43 才确定根本原因，中间隔了将近 38 小时。
Q2：那第三方安全产品为什么要背这个锅？
这里要把话说准。Bitget 官方、Mandiant、SlowMist、以及做威胁研究的 Aviatrix，四家都没有点名是哪一家厂商、哪一款产品。所以正文里我只能写"某第三方安全产品"，具体厂商属于未能核实。
但从结构上讲，问题不在于"安全产品比业务系统更特殊"，而在于它所在的位置：安全类软件通常要求很高的系统权限（要读流量、要落探针、要有调试能力），并且往往运行在服务进程下。权限高、暴露面大、更新链路又依赖供应商，这三件事凑在一起，就是供应链攻击的标准靶位。Aviatrix 那份报告里给出的 MITRE 映射第一条就是 T1195.002（供应链 Compromise），后面跟着 T1190（公共应用利用）、T1505.003（Web Shell）、T1552.001（凭据在文件中）。
那份报告还补了两个 Bitget 官方没细说的中间环节，我把它当作二手来源记录在这里：初始立足时间是2026-08-31，比 9/24 早了约 24 天；载体是两台第三方安全设备；提权方式是从环境变量里提取数据库凭据，再用 web shell 建 C2 横向移动到生产钱包服务器。这几个动作和"零日 → 高级内部凭证"这条官方主线是自洽的，只是更具体，也更难看——它意味着攻击者在系统里蹲了将近一个月。
3. 三个"没碰到"，和它们各自的边界
官方声明里有三句"没受影响"，这三句经常被连在一起当成"还好问题不大"来读。但它们各自的边界其实很不一样，值得分开看。
| 结论 | 官方依据 | 这个结论的边界在哪 |
|---|---|---|
| 私钥未泄露 | 已排除私钥泄露；Mandiant 与 SlowMist 的独立调查与 Bitget 确定的攻击路径一致 | 排除的是"私钥外泄"，不排除"签名能力被滥用"。这次钱正是通过提现流程被合法签出去的 |
| 冷钱包未受影响 | 冷钱包全部未受影响 | 冷钱包的边界来自"不参与在线签名"。一旦哪天为了业务方便给冷钱包加了在线签名通道，这条边界就没了 |
| Bitget Wallet 未波及 | 它是独立的非托管产品 | 独立部署是这次没被连带的原因。但"独立"是架构事实，不是承诺，用户侧仍需自己核对 |
我比较在意第一条。“已排除私钥泄露"这句话在传播中给人的感觉是"系统核心守住了”，但把它和攻击路径放在一起读，结论其实更微妙：攻击者根本不需要私钥。他要的是能让系统用私钥去签一条他写的指令的能力。私钥保管得再好，只要"什么值得签名"这一层判断是外包给业务系统的，而业务系统又能被内部凭证注入，那私钥的安全性就只是一个必要条件，不是充分条件。
这也解释了为什么 05:44 那一步是关签名服务而不是改私钥。团队很清楚要断的是调用链，不是密钥本身。
4. 金额、时区、基金：几个口径为什么对不上
这类事件里，"到底丢了多少"永远不是一个数。我把能查到的口径并列出来，顺便说明差异从哪来。
| 口径 | 数值 | 来源与说明 |
|---|---|---|
| 最初报道 | 约 3.51 亿美元 | 事发初期的媒体数字 |
| Decrypt 跟进 | 约 3.875 亿美元 | 链上统计随时间补齐后的值 |
| Aviatrix 报告 | 3.875 亿美元（写作 $387.5M） | 威胁研究报告 |
| Bitget 官方最终核实 | 约 3.88 亿美元 | 官方强调这是对 9/24 原始事件相关交易的最终核算与分类结果，不代表控制措施完成后又有额外未授权转移 |
| 影响面 | 12 个热/温钱包相关地址、11 条区块链 | 以太坊、XRP Ledger、Zcash、TRON、Arbitrum、Optimism、Base、BNB Smart Chain、Avalanche、Algorand、Celestia |
| 已识别资产 | XRP、ETH、USDT、ZEC、ATOM、USDC、USD0、XAUt、BNB、AVAX、TRX、ALGO、TIA | 官方列出的清单；各链逐项金额分布没有公开表 |
三个数（3.51 / 3.875 / 3.88）之间的差别主要是统计时点：链上归集需要时间，早期只能看到已经流出的部分。官方最后给的 3.88 亿是把交易分类完的结果，所以它比早期媒体数略高是正常的，不必解读成"又丢了一笔"。
还有一个更容易搞混的地方：时区。安全客那篇译文把首次转移写成"UTC 时间 9 月 24 日 18 点 31 分"，而官方写的是"9/24 02:31（UTC+8）"。这两个其实是同一个时刻——译文把 UTC+8 的时间标成了 UTC，差了 8 小时。这类错误在跨时区事件报道里非常常见，看时间线时先确认基准时区，比看数字更重要。
保护基金也有两个口径：官方在 9 月 30 日 17:00 说"补充至超过 3 亿美元"，而安全客译文引 CEO 说法是"Bitget 名下用户保护基金 4.64 亿美元"。差异原因我没能核实到，两个数都记在这里，不做取舍。
至于归因，目前只到"CEO 口头指认攻击者使用的 IP 与某些朝鲜黑客组织的 VPN 偏好匹配"这一层，没有执法机构或研究公司的正式认定。对比之下，2025 年 2 月 Bybit 那起 14 亿美元的事件，是 FBI 在数周后才给出归因结论的。所以这类判断的合理预期是：事发当天不会有可信答案。
5. 从后端工程师的角度，这次事件能带走什么
前面都在讲别人的系统。这一节讲我自己的判断：如果同样的路径放在一个普通的业务后端上，哪些环节我这边也一样会漏。
我的判断是：这次事件里没有任何一个环节是"交易所才有的特殊问题"。第三方组件高权限运行、内部凭证能直接写业务表、风控只校验业务规则不校验指令来源、审计日志和业务流程走同一套权限——这四条在绝大多数中小公司的后端里都成立。
笔者（后端 & 架构）会把这几件事列进整改清单，但每条都有代价，我按"能做到什么程度"来排：
| 动作 | 针对这次路径的哪一步 | 代价 / 边界 |
|---|---|---|
| 提现等资金动作走双重来源校验：业务规则之外，再校验指令是否由用户侧发起流程生成 | 第 4 步（注入伪造指令） | 需要给"指令来源"引入一个独立于服务端凭证的可信因子（比如用户侧签名），改造涉及提现主链路，回归成本高 |
| 对账从"事后 T+1"改成准实时，并把对账差异设成一级告警 | 03:05 才由对账发现 | 准实时对账要常驻跑批与额外存储；高频链上确认数不同，误报需要人工消化 |
| 高权限组件（含安全类 agent）单独网段 + 单独凭证域，不与业务库共用凭据 | 第 1、2 步（零日 → 内部凭证） | 运维复杂度上升，出问题时的排查链路变长；小团队容易只做一半，等于没做 |
| 数据库凭据不进环境变量，改用短时效凭据（KMS / Secrets 轮换） | Aviatrix 补的那一步 | 需要有可用的凭据签发服务；应用重启、长连接池、灰度期间的兼容都要处理 |
| 关键操作的审计日志写到独立存储、只追加，与业务库权限隔离 | 第 5 步（删痕迹） | 只能提高删痕迹的成本，挡不住；且日志保留周期要与合规要求对齐 |
| 供应商组件纳入资产清单，明确"哪些第三方进程有 root/系统级权限" | 整条链的前置条件 | 这是最便宜也最容易漏的一条；清单要维护，否则半年后就失真 |
比较有意思的是最后一条。它几乎不需要预算，但很多团队答不出"我们生产环境里有哪些第三方 agent 在以系统权限运行"。而这次事件里，攻击面恰恰就在这上面。
Q3：储备金证明（PoR）能防住这类事吗？
不能，但它在这次事件里扮演了一个挺耐人寻味的角色。Bitget 在 9 月 29 日 23:59 发布了第 47 期储备金证明，19 项覆盖资产整体储备率 131%——注意这个时间点：距离被盗已经五天，距离全面恢复还有三天。
PoR 证明的是"此刻链上的资产够不够覆盖用户余额"，它不证明"资产是怎么到那里的"，更不证明"签名链路可不可信"。所以它在这次事件里的作用是信心修复，不是防御。这两件事在讨论里经常被混起来，一混就会得出"上了 PoR 就安全了"这种错误结论。
Q4：那这次事件里有没有做得对的地方？
有，而且是三处，我按可复制性从高到低排：
- 发现机制是真的。03:05 由对账系统自动发现并立刻拦下全平台提现，说明自动化对账这条线在关键时刻起作用了。很多事故是用户投诉才发现的。
- 在不确定下按最坏假设行动。04:40 那句"因尚未排除私钥泄露可能"就把资金转冷，没有等根因查清。
- 恢复是分阶段而不是拍脑袋一次性开闸。从 9/26 确认安排，到 9/28 放 BTC、9/29 放 ETH 系、9/30 放 USDT 系，10/2 才全面恢复，中间还夹了两份独立报告。
这三条里，前两条是可以直接抄的；第三条需要业务侧承受住"提现怎么还不开"的用户压力，这个成本要如实说。
6. 最后总结
- 如果你只想知道这次事件的技术结论：攻击者没有偷私钥，他偷的是"让系统替他签名"的能力。这两件事的防御位置完全不同。
- 如果你是做后端的：这次路径上的四个环节（高权限第三方组件、内部凭证、只校验业务规则的风控、与业务同权限的审计日志）在你的系统里大概率也都在。
- 如果你是普通用户：这次事件里"冷钱包未受影响""独立非托管产品未波及"这两条边界是清楚的，但它依赖的是架构选择，不是承诺。
- 对我个人最有价值的一条是："已排除私钥泄露"和"资产被合法签出去"这两句话可以同时为真。以后再看到前者，我会先问一句那后者是怎么回事。
参考资料 & 致谢
- Bitget 学院 - 《Bitget 安全事件说明：时间线、影响及安全响应》（官方根因、五步路径、三个排除项、完整时间线，页面标注更新日期 2026-10-14）
- Bitget 支持中心 - 《Update On Slowmist and Mandiant Report》（独立调查与官方攻击路径一致的表述，2026-09-30）
- Bitget 公告 - 《[SECURITY NOTICE] Bitget exchange hot wallets Incident — September 24, 2026》《Bitget to Resume Withdrawals in Phases》（分阶段恢复安排）
- 安全客 - 《3.5亿美元一夜蒸发！黑客没偷密钥，Bitget是怎么被掏空的》（3.51 亿 / 3.875 亿口径演变、XRP 1.03 亿枚、时区写法差异、保护基金 4.64 亿口径，译文 2026-09-29）
- Aviatrix Threat Research Center - 《How Zero-Day Supply Chain Attacks Cost Bitget $387 Million》（8/31 立足、两台第三方安全设备、环境变量取凭据、web shell 建 C2、MITRE ATT&CK 映射，2026-10-01）
- EIP-7702 规范（用于对照另一起交易所事件中"签名链路"的技术口径）
