Bitget 3.875亿美元链下漏洞事件：不止于密钥与合约

2026年9月24日,约3.875亿美元资金从Bitget的部分运营钱包中被转出,涉及以太坊及其他EVM网络、XRP Ledger、Zcash和TRON。Bitget将受影响的钱包描述为热钱包和温钱包。链上交易带有有效的钱包签名。Bitget将攻击入口归因于第三方安全产品中的一个漏洞,并表示私钥和冷钱包未受到影响[1, 2]。

根据截至2026年9月29日16:35 UTC可获得的公开披露信息和链上证据,第一部分总结了已披露的攻击序列、后续资金转移、服务恢复情况,以及生态系统参与者的不同应对方式。第二部分将这些观察结果与我们的安全经验相结合,为加密机构提出一个纵深防御框架,并给出可行的安全建议。

1. 从链下访问到链上损失与恢复

Bitget将攻击入口归因于第三方安全产品中的一个漏洞,但尚未披露该产品、受影响的组件或技术利用机制[1, 2]。其公开说明将下游路径描述为:内部访问、伪造提款指令、绕过风险验证、有效签名以及链上转账。

1.1 攻击时间线与归因

Bitget首席执行官Gracy Chen披露的时间线,结合链上记录,展示了事件的发展过程[3]:

• 9月24日18:31 UTC:首批转移金额为0.84 ETH和93 TRX。两者均低于交易所的风险控制阈值。
• 18:58-20:09 UTC:Chen描述了跨以太坊、XRP Ledger、Zcash、BNB Chain、Base、Arbitrum、Optimism和Avalanche的17笔较大金额转账,总计约3.61亿美元[3]。链上记录还显示,19:16 UTC在TRON上发生了一笔2059万 TRX的转账。
• 首笔大额转账发生七分钟后:Bitget的对账系统检测到差异,并停止了用户发起的提款。Bitget的时间线将该操作与21:44 UTC后续关闭钱包提款和签名服务的行动区分开来[1]。

Chen表示,攻击者删除了欺诈指令留下的痕迹[3]。在初步归因方面,她还表示IP地址行为和链上模式与已知的朝鲜黑客组织高度一致[4]。这仍是初步归因,而非最终结论;Bitget的官方事件页面尚未指名负责方,调查仍在进行中[1]。

1.2 资金流向与运营恢复

Bitget官方追踪工具所反映的链上记录显示,被盗的稳定币在几分钟内被转换为ETH[5]。与USDT或USDC不同,像ETH这样的原生资产不存在发行方控制的冻结功能。这一行为与试图降低发行方冻结风险的意图相符,但并不能确定攻击者的身份或经验水平。

随着Bitget纳入更完整的核算(包括Zcash和TRON),官方受影响金额后来上升至约3.875亿美元[1]。Bitget公布了攻击者地址、资金追回报告门户和地址API[1, 6],以及实时追踪网站[5]。该网站的持仓视图报告当前的分布情况,而其资金流图则映射出下游地址、服务、跨链桥和跨链路径。

9月29日16:35:28 UTC,官方追踪工具报告称攻击者当前持有3.2267亿美元,八个实体共冻结约632,700美元,发行方可冻结的稳定币为312,500美元,还有5,587万美元处于转移中或仍在分析中[5]。冻结总额包括NEAR Intents的293,507美元(其在执行过程中报告冻结约503,000美元[12])、Tether冻结的239,242美元,以及Circle冻结的99,990美元。公开资料未能将NEAR Intents的数字相互对账。

同一时间点,地址浏览器显示已确认归属地址的余额集中在BTC(2.8851亿美元)、ZEC(2891万美元)和ETH(717万美元)[5]。该浏览器采用与概览页面不同的分类范围,因此其地址层面3.2769亿美元的总额与概览中3.2267亿美元的当前持仓数字无法直接比较。

运营恢复也在推进。Bitget于9月29日08:00 UTC恢复了ETH提款。截至09:00 UTC,其报告约有9,674 ETH流入和9,023 ETH流出,因此流入比流出多出约651 ETH[7]。

1.3 资金离开之后:社区响应

一旦资产离开受影响机构的钱包,追回工作就依赖于原安全边界之外的组织。Bitget开放了其追踪数据,并针对能够冻结或追回资金的有效协助设立了赏金[1, 6]。Binance表示其安全团队分享了情报、追踪了资金并支持追回工作[8]。Bybit首席执行官Ben Zhou提供了协助,并更新了LazarusBounty追回平台,同时指出Bitget在2025年Bybit自身发生事件时曾提供过帮助[9]。Bybit的响应延续了两家交易所之间相互协助的模式。

由于技术设计和治理模式的不同,基础设施提供商拥有不同的应对选项。Bitget要求THORChain拒绝为已公开列出并被积极追踪的攻击者地址提供服务。Gracy Chen认为,"去中心化是一种设计原则,而不是为已知被盗资金提供便利的保护罩"[10]。THORChain解释说,它不支持选择性黑名单:其紧急控制机制只能暂停更广泛的活动或某条链路径,而不能针对单一地址或交易。部分被盗资产通过该网络继续从ETH转移到BTC[11]。

NEAR Intents的应对方式则有所不同。其SHIELD风控系统在过滤重复尝试后,识别并阻止了与攻击者相关的超过5,000万美元的尝试流转;执行过程中约冻结了503,000美元,而约166,000美元的资金得以通过。NEAR Intents还放弃了其在Bitget追回赏金中应得的份额[12]。这5,000万美元是系统拒绝处理的尝试性流转金额,并非被冻结或追回的金额。

大规模跨链追回通常需要多方参与者的配合。交易所可以暂停存款或提款,稳定币发行方可以冻结代币,路由服务可以在其设计允许的范围内拒绝已确认归属的流转,而基础协议或许只能监控并共享指标信息。有效的协调始于每个参与者明确说明自己能采取的行动以及所需的证据。

干预本身也伴随风险。错误的归因可能封锁无辜用户,而持续存在的黑名单可能从事件响应工具演变为更广泛的交易限制机制。可辩护的应对方式应基于相互印证的证据、范围狭窄且有时限的限制措施、申诉流程、透明的行动记录以及事后审查。在系统缺乏选择性控制能力的情况下,透明的能力披露有助于建立合理的预期。在存在自主裁量空间的情况下,公开的判定标准和可问责的决策机制有助于形成一致的应对方式。

2. 阻断并遏制利用路径:系统化的纵深防御安全框架

结合第1节所记录的事件路径与应对情况,以及我们的经验和专业知识,我们提出以下两层框架。关于代码审计和监控为何无法覆盖整个资金处理路径的更多内容,请参见《Why Crypto Institutions Need Blockchain Penetration Testing》[13]。

• 已披露的利用路径从第三方安全产品延伸至链上转账。
• 该框架的预防与检测层包含前三项安全实践。2.1节和2.2节探讨了权限访问控制和独立的意图验证如何防止基础设施据点进一步演变为签名操作。2.3节涵盖资产流监控,该机制可检测并升级异常的出账行为,并能够暂停有风险的入账存款。
• 响应与恢复层包含第四项实践。它可以由预防与检测层中任何位置发出的高置信度信号触发,也可以由运营故障触发。2.4节涵盖了独立暂停受影响操作或将受威胁资产转移至已验证安全目的地的能力。

每一小节都遵循相同的结构:安全目标、事件路径所暴露的风险,以及机构可以建立的预防、检测或响应能力。这些实践应依赖于各自独立的权限和证据。它们共同作用,可以降低对任何单一保障措施的依赖,并为机构提供遏制损失的预先准备好的选项。

2.1 权限访问与提款指令

其目标是防止基础设施或权限系统遭到入侵后,足以生成一条可信的提款指令。

第三方产品不需要拥有直接的签名访问权限就能影响资产转移。对塑造提款指令的凭证或系统的访问权限,可能就足以决定另一个系统将签署什么内容。此类产品属于机构级Web3攻击面[14]。其风险取决于它们能够影响的价值以及能够触及的系统。

所需的控制措施包括最小权限原则、网络分段、受限的更新与管理路径、短期有效凭证、防篡改日志,以及经过测试的权限撤销流程。内部访问权限不应自动赋予生成可信提款指令的能力。每条指令都应携带经过身份验证的来源、不可变的请求标识符,以及经签名或以其他方式验证过的配置版本。指令的创建、批准、签名和广播应分属于不同的权限,下游系统应拒绝来源未知、配置过期或绑定信息不完整的指令。

2.2 提款意图与签名

其目标是防止伪造或篡改的提款指令变成一笔经过有效签名的交易。

有效签名只能证明相应的私钥对交易数据进行了签名;它无法证明底层的提款请求是真实的,或经过了独立批准。

签名边界应根据独立可信记录重建预期交易,并比对每一个能够转移价值的字段。批准操作至少应绑定链、资产、金额、接收方、来源钱包、交易nonce、手续费范围、有效期,以及原始的提款或资金调拨请求。

构建提款请求的组件不应是用于对其进行授权的唯一来源。策略评估应使用独立的账户和风险数据,而签名系统应验证最终交易数据是否与已批准的意图相符。当前有效的授权签名人集合、签名门限、交易nonce以及配置都必须与预期的生产环境状态相符。人工审核人员需要的是从待签名的确切字节生成的规范化交易视图,而不是由发起请求的后端系统提供的可被篡改的摘要信息。

2.3 出账与入账资产流

其目标是检测实际资产流转与独立重建的业务意图之间出现的偏差。

一家加密机构既可能是数字资产流转的来源方,也可能是接收方。出账监控应将实际链上活动与一组独立重建的已批准提款请求进行比对。为保持独立性,该监控机制不应仅依赖于提款系统所生成的同一条指令。

该监控机制应从独立的业务记录中推导出预期的链、资产、金额、接收方、时间和钱包信息。它应汇总跨多个维度的行为,而这些是单笔交易限额所无法察觉的:

• 小额测试转账后紧随快速升级的行为。
• 跨账户、资产或链重复使用新的接收地址。
• 提款速度或总敞口的突然增加。
• 多个运营钱包层级同时出现资金流出。
• 转向更难冻结的原生资产。
• 已批准的请求、已签名的交易数据与已广播的交易之间存在差异。

控制措施应在一个时间窗口内评估累计金额、速度、目标地址是否为新地址、钱包层级、资产的可兑换难易程度,以及跨链行为。Bitget最初的ETH和TRX转账很好地说明了将交易作为一个序列而不仅仅作为孤立事件进行评估的价值[3]。高置信度的不匹配情况应触发第2.4节所述的紧急响应路径。置信度较低的异常情况可能需要二次批准、目标地址冷静期、降低限额,或暂时暂停提款。

入账监控应在存款入账之前对其进行筛查,并在提款之前重新进行筛查。它应追踪资金经过跨链桥、去中心化交易所(DEX)、基于意图的路由服务以及中间地址的流转情况,因为仅匹配第一个攻击者地址是不够的。高置信度匹配需要一个有文档记录的流程,用于暂停资金、调查匹配情况、处理申诉,以及完成任何必要的法律交接。

交易所之间的快速情报共享,能将入账筛查转化为一种网络效应。一家机构可能先检测到事件,而另一家机构可能先看到相关资金流入。共享的机器可读指标以及最新的联系方式,可以缩短从归因到行动之间的时间间隔。

2.4 紧急暂停与资产转移

其目标是在识别出高置信度安全信号或运营故障后,遏制剩余的风险敞口。

信号可能包括权限访问或指令完整性违规、提款意图或签名不匹配、异常的出账、入账或其他链上活动,以及对账失败。此时,机构应能够暂停受影响的签名、广播、提款或钱包操作。如果资产仍处于风险敞口之中,机构还应能够将其从可疑钱包转移到预先定义的安全目的地。暂停操作可以争取调查时间;而转移操作则能降低剩余的风险敞口。

• **独立的暂停权限:**即使主管理系统遭到入侵,暂停功能也必须保持可用。在架构允许的情况下,其作用范围应足够狭窄,能够针对特定链、钱包、资产或操作进行停止。启用和解除暂停都需要经过验证的授权、防篡改记录、明确的恢复标准,以及在降级条件下的测试。
• **转移路径的连续性:**在配置变更时,不得在新的应急路径尚未部署、授权、签名、存储和测试完成之前,使旧的应急路径失效。
• **可执行交易的就绪状态:**由于nonce变化、原生代币余额不足以支付手续费、源资产余额变化、手续费市场变化导致已签名的手续费限额不可用、有效期到期,或配置更新等原因,预先存储的紧急交易可能会失效。就绪状态检查应持续验证这些依赖关系。完全签名的交易数据在紧急操作被批准并准备立即广播之前,应保持加密状态并受到访问控制。
• **覆盖范围与故障切换:**每一个运营钱包、链、原生资产和受支持的代币,都需要主要和备用的转移路径。广播与验证基础设施同样需要在远程过程调用(RPC)端点、运营系统和人工恢复工具之间具备冗余。
• **完成检查与演练:**应急响应流程应通过已确认的链上执行、按资产逐一验证、剩余余额检查,以及链上状态与内部记录之间的对账,来定义"完成"的标准。它还应能够检测链重组和失败交易。定期演练应测量从检测到最终余额验证的完整恢复时间。

经授权的区块链渗透测试可以通过在约定范围内对实际运行环境进行测试,将跨层级的假设转化为切实证据[15]。对于生产环境测试,应在测试开始前制定书面的交战规则(Rules of Engagement, RoE),明确授权范围、允许使用的技术手段、停止条件、价值限额、沟通方式、证据处理方法以及暂停权限[16]。

结语

Bitget事件既不是私钥泄露,也不是智能合约漏洞利用。Bitget表示,攻击者利用第三方安全产品中的一个漏洞获取了内网访问凭证,随后伪造了提款指令,而钱包系统将这些指令处理成了经过有效签名的链上转账[1, 2]。资产离开受影响机构后,追回工作就变成了整个生态系统共同承担的任务。Bitget、Binance、Bybit、THORChain和NEAR Intents的应对方式表明,参与者可以采取不同的应对方式[8-12]。当重大安全事件或威胁出现时,社区如何能够快速且负责任地协调这些能力,仍是加密行业面临的一个更广泛的挑战。

已知的下游路径为本文所提出的系统化框架提供了依据,该框架将预防与检测同响应与恢复衔接起来。机构可以通过限制权限访问并验证指令来源、在签名环节独立重建已批准的提款意图、监控出账序列和入账资金,以及维持可独立操作的暂停与转移路径,来降低对任何单一保障措施的依赖。托管仍然至关重要,而这些实践则在整个资金处理链条中对其进行补充[13, 15]。

参考文献

[1] Bitget. Bitget Security Incident: Official Progress Update. https://www.bitget.com/campaigns/bitget-security-incident-2026

[2] Gracy Chen. Security Incident Root-Cause Boundary. https://x.com/GracyBitget/status/2104515761691939026

[3] The Block. Bitget Attacker Tested Risk Controls with Small Transfers Before $388 Million Theft, CEO Says. https://www.theblock.co/news/regulation/2026-09-28-bitget-attacker-tested-risk-controls-small-transfers-388-million-theft-ceo-says-417045

[4] Gracy Chen. Preliminary Attribution Assessment. https://x.com/GracyBitget/status/2103359775723626736

[5] Bitget. Live Tracing Dashboard and Fund-Flow Graph. https://trace.bgblockchain.xyz/v2#track

[6] Bitget. Live Tracing Information and Recovery Portal. https://x.com/bitget/status/2103485491220033607

[7] Gracy Chen. ETH Withdrawal Resumption Update. https://x.com/GracyBitget/status/2104886024979816508

[8] Binance. Richard Teng Puts Binance's Security Muscle Behind an Industry-Wide Response. https://www.binance.com/en/square/post/09-25-2026-binance-news-richard-teng-puts-binance-s-security-muscle-behind-an-industry-wide-response-370442242243629

[9] Ben Zhou. Bybit Support for Bitget. https://x.com/benbybit/status/2103328213141508335

[10] Gracy Chen. Request to THORChain. https://x.com/GracyBitget/status/2103812967066439817

[11] CoinDesk. THORChain Rejects Bitget Request to Block Hacker as $6 Million Moves to Bitcoin. https://www.coindesk.com/tech/2026/09/28/thorchain-rejects-bitget-request-to-block-hacker-as-usd6-million-moves-to-bitcoin

[12] Gracy Chen. NEAR Intents and SHIELD Response. https://x.com/GracyBitget/status/2104602301503816040

[13] BlockSec. From Incidents to Regulation: Why Crypto Institutions Need Blockchain Penetration Testing. https://blocksec.com/blog/why-crypto-institutions-need-blockchain-penetration-testing

[14] BlockSec. Web3 Attack Surfaces: A Penetration Testing Overview. https://blocksec.com/blog/web3-attack-surfaces-penetration-testing

[15] BlockSec. What Is Blockchain Penetration Testing? Definitions and Boundaries. https://blocksec.com/blog/what-is-blockchain-penetration-testing

[16] BlockSec. Rules of Engagement and Production Safety for Institutional Blockchain Penetration Testing. https://blocksec.com/blog/blockchain-penetration-testing-rules-of-engagement