企业官网建设流程全解析

核心要点

Bitget 的私钥没有泄露，事件也不涉及智能合约漏洞，但带有有效签名的交易仍把约 $387.5M 转入攻击者控制的地址。结合我们在交易所钱包安全、签名流程和应急响应设计方面的经验，本文把建议归纳为四项相互补充的安全实践：特权访问与提现指令、提现意图与签名、资产流出与流入、应急暂停与资产转移。

预计阅读时长 13 分钟

引言

2026 年 9 月 24 日，约 $387.5M 从 Bitget 的部分钱包转出，涉及 Ethereum 及其他 EVM 网络、XRP Ledger、Zcash 和 TRON。Bitget 将这些受影响钱包称为热钱包和温钱包。

链上交易带有有效的钱包签名。Bitget 将攻击入口归因于第三方安全产品中的漏洞，并表示私钥和冷钱包均未失陷。

基于截至 2026 年 9 月 29 日 11:49 UTC 可获得的公开披露与链上证据，本文第一部分总结已披露的攻击序列、后续资金流动、服务恢复和生态参与方的不同响应。第二部分结合这些观察与我们的安全实践经验，提出一套面向加密资产机构的纵深防御框架，并给出相应的安全建议。

1. 从链下访问到链上资产损失与追回

Bitget 将攻击入口归因于第三方安全产品中的漏洞，但尚未披露具体产品、受影响组件或技术利用机制。官方公开的下游路径包括内部访问、伪造提现指令、绕过风险校验、生成有效签名和完成链上转账。

1.1 攻击时间线与初步归因

根据Gracy Chen 向媒体披露的攻击时间线，事件经过如下：

• 9 月 24 日 18:31 UTC：首批转账包括 0.84 枚 ETH 和 93 枚 TRX，两笔均低于交易所风控阈值；

• 18:58 至 20:09 UTC： Gracy Chen 称，攻击者在 Ethereum、XRP Ledger、Zcash、BNB Chain、Base、Arbitrum、Optimism 和 Avalanche 发起 17 笔大额转账，合计约 $361M。链上记录还显示，19:16 UTC 有一笔约 20.59M 枚 TRX 的大额转账发生在 TRON 上；

• 第一笔大额转账发生 7 分钟后：Bitget 对账系统发现差异，并停止用户发起的提现。Bitget 公布的时间线将这一措施与随后关闭钱包提现及签名服务区分开来；后者发生在 21:44 UTC。

这仍属于初步归因，并非最终结论；Bitget 官方事件页面尚未点名具体攻击组织，相关调查仍在进行。

1.2 资金流向与运营恢复

Bitget 官方追踪系统收录的链上记录显示，部分被盗稳定币在数分钟内被换成 ETH。与 USDT 或 USDC 不同，ETH 等原生资产没有由发行方控制的冻结功能。这些行为与降低发行方冻结风险的尝试一致，但不足以确认攻击者身份或经验水平。

随着 Bitget 完成更全面的核算并纳入 Zcash 和 TRON 转账，官方影响金额上调至约$387.5M。

Bitget 公开了攻击者地址、追回信息提交入口和地址 API，以及实时追踪站点。站点的持仓页面（https://trace.bgblockchain.xyz/v2#track）持续更新资产分布，资金关系图（https://trace.bgblockchain.xyz/v2#graph）则展示下游地址、服务、跨链桥和跨链路径。

截至 9 月 29 日 16:35:28 UTC，官方追踪页面记录的攻击者当前持仓为 $322.67M，8 笔已冻结资金合计约 $632,700，8 笔仍可由发行方冻结的稳定币合计 $312,500，另有 $55.87M 处于跨链途中或仍在分析。

已冻结资金包括 NEAR Intents 处的 $293,507（NEAR Intents 自报约 $503,000 在执行过程中被冻结），Tether 冻结的 $239,242 和 Circle 冻结的 $99,990；公开来源尚未解释 NEAR Intents 两个数值之间的差异。

同一时间，地址浏览器显示，已归因地址的余额主要集中在 BTC（$288.51M）、ZEC（$28.91M）和 ETH（$7.17M）。地址浏览器与概览页采用不同的分类口径，因此其 $327.69M 地址余额合计不能直接与 $322.67M 攻击者当前持仓比较。

运营恢复也在推进。Bitget 于 9 月 29 日 08:00 UTC 恢复 ETH 提现。截至 09:00 UTC，平台记录的流入约为 9,674 枚 ETH，流出约为 9,023 枚 ETH，流入比流出多约 651 枚 ETH。

1.3 资产转出之后：生态响应

资产一旦离开受影响机构的钱包，追回工作就依赖原安全边界之外的机构。Bitget 开放追踪数据，并为符合条件的冻结或追回协助提供悬赏。Binance 表示，其安全团队共享情报、追踪资金并协助追回。

Bybit 首席执行官 Ben Zhou 也提供协助并更新 LazarusBounty 追回平台；他同时提到，Bitget 曾在 Bybit 的 2025 年事件后提供帮助。Bybit 此次协助延续了两家交易所之间的相互支持。

基础设施提供方能够采取的行动因技术设计和治理模式而异。Bitget 要求 THORChain 拒绝向已经公开、持续追踪的攻击者地址提供服务。Gracy Chen 表示：“去中心化是一项设计原则，不应成为协助已知被盗资金流通的挡箭牌”。

THORChain 则解释称，其系统不支持选择性拉黑；现有紧急控制可以暂停更广范围活动或某条链的路线，却不能只冻结一个地址或一笔交易。部分被盗资产随后继续通过该网络从 ETH 换成 BTC。

NEAR Intents 公布了另一种做法。其 SHIELD 风险系统在去除重复尝试后，识别并阻断了超过 50M 与攻击者相关的尝试流量；约 503,000 在执行过程中被冻结，约 166,000 成功通过。

NEAR Intents 还放弃了 Bitget 追回悬赏中的自身份额。其中 50M 指系统拒绝处理的尝试流量，并非冻结或追回金额。

大额跨链资产追回通常需要多个参与方协作。交易所可以暂扣入金或提现，稳定币发行方可能冻结代币，路由服务可在系统设计允许时拒绝已归因资金流，基础协议则可能只能监控并传播风险指标。有效协作的起点，是各参与方清楚说明自己能够采取什么行动，以及采取行动需要什么证据。

表 1：生态参与方的可用控制、适当处置与必要约束

干预措施本身也会带来风险。错误归因可能导致无辜用户的资金或交易被阻断；长期固化的黑名单还可能从事件响应工具演变为常态化的交易限制机制。合理处置应使用经过交叉验证的证据，限制影响范围和有效期，提供申诉流程，公开行动日志，并在事后复盘。

系统不具备选择性控制能力时，透明披露能力边界有助于各方形成合理预期；系统拥有裁量空间时，公开标准和可问责的决策流程有助于保持处置一致性。

2. 阻断与遏制攻击路径：一套系统化纵深防御安全框架

基于第 1 节记录的事件路径和响应，并结合我们的经验与专业判断，本文提出下图所示的两层框架。关于代码审计和监控为何无法覆盖整条资金处理链，可进一步参阅《为什么加密机构需要区块链渗透测试》。

图 1：面向加密资产机构的两层纵深防御框架

• 已公开的攻击路径从第三方安全产品延伸至链上转账；

• 框架的预防与检测层包含前三项安全实践。第 2.1 和 2.2 节分别讨论高权限访问控制与独立意图核验，目标是阻止基础设施立足点一路推进到签名；第 2.3 节讨论资金流监控，负责发现并升级出金异常，同时可暂扣高风险入金；

• 响应与恢复层包含第四项安全实践。预防与检测层中任一位置产生的高置信度信号，或运行故障，都可以触发该层。第 2.4 节讨论独立暂停受影响操作，或把暴露资产转移到经过验证的安全目的地。

后续各小节依次说明安全目标、攻击路径暴露的风险，以及机构可以建立的预防、检测或响应能力。这些安全实践应依赖彼此独立的权限和证据，从而降低机构对单一防护的依赖，并为损失遏制准备多种响应方式。

2.1 特权访问与提现指令

机构需要防止基础设施或特权系统失陷后生成可信的提现指令。第三方产品即使不能直接签名，也可能影响资产转移。只要它能够接触凭据，或影响提现指令的生成，就可能决定另一套系统最终签什么。此类产品属于机构级 Web3 攻击面，其风险取决于可影响的资产规模与可触达的系统路径。

所需控制包括最小权限、网络隔离、受控更新和管理路径、短期凭据、防篡改日志，以及经过测试的撤销流程。取得内部访问权限后，攻击者不应自动获得创建可信提现指令的能力。

每条指令都应带有可验证来源、不可变请求标识，以及经过签名或其他方式认证的配置版本。指令创建、审批、签名和广播应分属不同权限；下游系统则应拒绝来源未知、配置过期或绑定字段不完整的指令。

2.2 提现意图与签名

机构需要防止伪造或篡改的提现指令转化为带有有效签名的交易。有效签名只能证明对应私钥签署了交易数据，不能证明底层提现请求真实存在或经过独立审批。

签名系统在执行签名前，应根据独立可信记录重建预期交易，并逐项比对所有可能影响资产转移的字段。审批至少应绑定链、资产、金额、收款地址、来源钱包、交易序号（nonce）、手续费上限、有效期，以及原始提现或资金管理请求。

负责构造提现的组件不应成为授权提现的唯一数据来源。策略评估应使用独立账户和风险数据，签名系统则验证最终交易数据是否与已批准意图一致。

当前签名者集合、签名阈值、交易序号（nonce）和配置必须与预期生产状态一致。人工审批者看到的规范化交易视图必须根据最终待签字节生成，不能来自发起请求的后端所提供的可变摘要。

2.3 资产流出与流入

加密资产机构既可能是数字资产流的来源，也可能是目的地，因此需要及时发现实际资产流动与独立重建的业务意图之间的偏差。出金监控应把实际链上活动与独立重建的已批准提现集合进行比较。为保持独立性，监控系统不应只依赖提现系统生成的同一份指令。

监控系统应从独立业务记录中得到预期链、资产、金额、收款地址、时间和钱包，并聚合单笔阈值无法发现的行为：

• 小额测试转账后迅速提高金额；

• 新收款地址在多个账户、资产或链之间复用；

• 提现速度或总体风险敞口突然上升；

• 多个钱包层同时流出资产；

• 资产迅速换成更难冻结的原生资产；

• 已批准请求、签名交易数据和广播交易之间存在差异。

控制系统还应在时间窗口内评估累计金额、速度、收款地址是否首次出现、钱包层级、资产转换便利程度和跨链行为。Bitget 最初的 ETH 和 TRX 转账说明了按序列评估交易、而非只孤立检查每笔交易的价值。

高置信度不一致应触发第 2.4 节所述的应急响应路径；置信度较低的异常则可触发二次审批、收款地址冷静期、降低限额或临时暂扣。

入金监控应在记账前筛查资金，并在允许提现前再次筛查。它还应沿跨链桥、去中心化交易所（DEX）、意图路由服务和中间地址继续追踪，因为只匹配最初攻击者地址并不足够。高置信度匹配需要一套有记录的资金暂扣、调查、申诉和法律交接流程。

交易所快速共享情报后，入金筛查会形成网络效应。一家机构发现事件，另一家机构可能接收赃款。机器可读指标和最新联系人能够缩短从完成归因到采取行动的时间。

2.4 应急暂停与资产转移

预防与检测层中任一位置产生的高置信度信号，或运行故障，都应触发响应与恢复层，以及时遏制剩余风险敞口。这些信号包括特权访问或指令完整性异常、提现意图或签名不一致、异常出金、入金或其他链上行为，以及对账失败。

机构随后应能暂停受影响的签名、广播、提现或钱包操作；如果资产仍有暴露风险，还应能把资产从疑似失陷的钱包转入预定义安全目的地。暂停可以为调查争取时间，转移则直接降低剩余风险敞口。

• **独立暂停权限：**即使主要管理系统失陷，暂停能力仍应可用。在架构允许的情况下，其范围应收敛到特定链、钱包、资产或操作。启用和解除需要经过身份认证，生成防篡改记录，遵循明确的恢复条件，并在系统降级场景下接受测试；

• **转移路径连续性：**配置变更不能在替代路径完成部署、授权、签名、存储和验证之前使旧应急路径失效；

• **交易可执行性：**存储中的应急交易可能因交易序号变化、用于支付手续费的原生资产余额不足、待转资产余额变化、手续费市场变化导致已签名的手续费上限不可用、过期或配置更新而失效。系统应持续检查这些依赖。完整签名的交易数据应保持加密并受到访问控制，只能在应急动作获批、即将广播时解密；

• **覆盖范围与故障切换：**每个钱包、链、原生资产和支持代币都需要主转移路径和备用路径。远程过程调用（RPC）端点、运营系统和人工恢复工具也需要彼此独立的冗余；

• **完成检查与演练：**应急响应流程应通过确认链上最终性、逐项验证资产、检查残留余额，以及核对链上状态与内部记录来定义完成条件。它还应检测链重组和失败交易。定期演练应测量从发现事件到最终余额核验所需的完整时间。

经过授权的区块链渗透测试可以在约定范围内对运行环境进行验证，把跨层假设转化为证据。生产环境测试开始前，还应通过书面的测试规则（Rules of Engagement，RoE）明确授权、允许使用的技术、停止条件、金额上限、沟通机制、证据处理和暂停权限。

结论

Bitget 事件既不是私钥泄露，也不是智能合约漏洞利用。Bitget 表示，攻击者利用第三方安全产品中的漏洞获取内网访问凭据，随后伪造提现指令，使钱包系统生成带有有效签名的链上转账。

资产离开受影响机构后，追回就成为整个生态共同参与的工作。Bitget、Binance、Bybit、THORChain 和 NEAR Intents 的案例说明，不同参与方可能作出不同响应。

当重大安全事件或威胁出现时，社区如何快速、负责任地协调这些能力，仍是整个加密行业需要共同面对的挑战。

已知下游路径为本文提出的系统化框架提供了依据，该框架连接预防与检测、响应与恢复。机构可以通过限制高权限访问并验证指令来源、在签名环节独立重建已批准提现意图、监控出金序列和相关入金，以及维护可独立操作的暂停与转移路径，降低对单一防护的依赖。

托管仍然必不可少，而这些安全实践在完整资金处理链上与托管形成互补。