[Web3] Bitget 被攻击事件复盘：私钥没泄露，钱是怎么走出去的

交易所被盗这件事过去两年大家已经看得有点麻木了报个数、说句已排除私钥泄露、然后把提现关掉几天。但 2026 年 9 月这次 Bitget 的事件我觉得值得后端工程师重新看一遍。原因不是金额——约 3.88 亿美元在交易所被盗案里排不进第一梯队——而是它的攻击路径完全没有走偷钥匙这条路。攻击者用的是 Bitget 自己采购的某第三方安全产品里的零日漏洞拿到高级内部凭证然后往钱包后端里注入伪造的提现指令。这些指令被当成正常提现处理了。说白了钱不是被偷出去的是被系统自己提出去的。所以这一篇我想把 Bitget 官方公布的那条链路摊开讲一讲五个步骤分别落在哪一层、风控为什么形同虚设、官方那句已排除私钥泄露到底排除了什么、以及一个做后端和安全的人能从这次事件里带走什么。1. 先把时间线摆正处置窗口是 3 小时 13 分很多二手报道把这次事件写成一夜之间被掏空但官方时间线其实给得很细而且第一段恰恰是最关键的从第一次未授权转移到签名服务被关闭只有三个多小时。下面这张图是 Bitget 学院页页面标注更新于 2026 年 10 月 14 日里给出的时刻全部 UTC8。把关键节点单独列一遍时刻UTC8发生了什么这一动的性质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.003Web 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:31UTC8。这两个其实是同一个时刻——译文把 UTC8 的时间标成了 UTC差了 8 小时。这类错误在跨时区事件报道里非常常见看时间线时先确认基准时区比看数字更重要。保护基金也有两个口径官方在 9 月 30 日 17:00 说补充至超过 3 亿美元而安全客译文引 CEO 说法是Bitget 名下用户保护基金 4.64 亿美元。差异原因我没能核实到两个数都记在这里不做取舍。至于归因目前只到CEO 口头指认攻击者使用的 IP 与某些朝鲜黑客组织的 VPN 偏好匹配这一层没有执法机构或研究公司的正式认定。对比之下2025 年 2 月 Bybit 那起 14 亿美元的事件是 FBI 在数周后才给出归因结论的。所以这类判断的合理预期是事发当天不会有可信答案。5. 从后端工程师的角度这次事件能带走什么前面都在讲别人的系统。这一节讲我自己的判断如果同样的路径放在一个普通的业务后端上哪些环节我这边也一样会漏。我的判断是这次事件里没有任何一个环节是交易所才有的特殊问题。第三方组件高权限运行、内部凭证能直接写业务表、风控只校验业务规则不校验指令来源、审计日志和业务流程走同一套权限——这四条在绝大多数中小公司的后端里都成立。笔者后端 架构会把这几件事列进整改清单但每条都有代价我按能做到什么程度来排动作针对这次路径的哪一步代价 / 边界提现等资金动作走双重来源校验业务规则之外再校验指令是否由用户侧发起流程生成第 4 步注入伪造指令需要给指令来源引入一个独立于服务端凭证的可信因子比如用户侧签名改造涉及提现主链路回归成本高对账从事后 T1改成准实时并把对账差异设成一级告警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-14Bitget 支持中心 - 《Update On Slowmist and Mandiant Report》独立调查与官方攻击路径一致的表述2026-09-30Bitget 公告 - 《[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-29Aviatrix Threat Research Center - 《How Zero-Day Supply Chain Attacks Cost Bitget $387 Million》8/31 立足、两台第三方安全设备、环境变量取凭据、web shell 建 C2、MITRE ATTCK 映射2026-10-01EIP-7702 规范用于对照另一起交易所事件中签名链路的技术口径