Bitget 被盗：钱包为什么会执行伪造提现

1 被控制的是交易所的钱包后台

先分清两个同名产品。本次受影响的是 Bitget 交易所使用的部分热钱包和温钱包，承担日常资金调度与提现；Bitget 称存放主要资产的冷钱包未受影响。独立的非托管产品 Bitget Wallet 使用另一套基础设施，官方表示它未卷入本次事件。用哪个 App、由谁持有和支配资产，在这里会改变用户面对的问题。

取证报告披露到的控制点，是第三方安全设备、生产钱包作业服务器，以及后者运行的提现程序。设备品牌、漏洞编号、内部接口和风控字段名都未公开，外部读者无法据此写出一份通用补丁清单。Bitget 在9 月 30 日更新的说明中称，已隔离相关系统、撤销并重发内部凭据、调整敏感权限，并在等待厂商完成修复期间禁用受影响功能；这些是交易所报告的处置动作，两份阶段性取证报告尚未提供完整的修复验收结果。

对普通用户，眼下最直接的变化是能否把自己的资产提走。Bitget 承诺账户余额不受损失影响，由保护基金承担本次财务损失，同时分批恢复提现。各币种和网络的实际恢复情况见文末；账户上仍有余额、某条网络已经开放、被盗资产已经追回，分别回答三个问题，不能互相替代。

2 安全设备上的权限，怎样到达钱包服务器

攻击发生前，异常已经留下过痕迹。慢雾报告第 2–3 页把现有日志中最早的活动追到 8 月 31 日：攻击者利用安全产品 A 节点服务的零日漏洞，在服务进程中运行隐藏脚本，读取环境变量里的数据库密码，再连接数据库。9 月 23 日和 25 日，另外两个节点也出现了相似脚本活动。这个起点说明，对外转币之前，基础设施中的秘密已经暴露；它还不能说明攻击者从 8 月底起就一直控制着整套钱包。

环境变量常被程序用于取得连接数据库所需的配置。只要某个进程能够读取这些值，掌握该进程执行能力的人就有机会取得同样的密码。密码本身未必属于最高权限账户，报告也没有公开其全部授权范围；但一旦它能让攻击者进入另一个系统，入侵就从一台设备扩大到一组信任它的服务。这里需要追的是密码实际能访问什么，不能仅凭“安全设备”这个用途名称判断风险大小。

之后，报告里出现了安全产品 B。慢雾记录，9 月 25 日凌晨，攻击者以内部员工身份访问 B 的管理平台，并向任务参数中注入系统命令，尝试写入恶意文件。其后提交的代码还尝试修改配置、建立通信中继，并上传和组装程序分块。报告没有公开从 A 到 B 的完整凭据流转过程，因此这一步仍有缺口。

Mandiant 的 9 月 28 日状态报告补上了 B 之后的重要一段：攻击者在 B 上放置 web shell，也就是能通过网页请求执行命令的后门，并建立远程控制连接；随后利用这里的持续访问权限，横向进入生产钱包作业服务器，部署恶意软件包。钱包作业服务器负责执行钱包相关任务，攻击者到了这里，就能接触真正推动提现流程的程序。

这段路径暴露出的管理问题很具体：一台安全设备拥有的访问能力，可以延伸到生产钱包任务。采购安全产品通常会增加检测和管理能力，也会增加运行代码、保存凭据、连接其他机器的主体。哪些机器允许它访问、它取得的凭据能否继续登录钱包服务器，必须作为产品接入的一部分检查。给设备补上入口漏洞，只解决了攻击者最初怎样进去；已经发出的凭据和已经建立的访问，仍要分别撤销。

3 一台后台机器，开始替攻击者提交提现

进入服务器之后，攻击者还需要把机器权限变成资金转移。慢雾从已删除文件中恢复出一款高度定制的提现工具。报告描述了它连续做的三件事：伪造风控参数、构造提现请求、调用提现流程。主机日志显示，相关恶意程序在北京时间 9 月 25 日 01:49 开始运行并实施盗币。这里的风险已经落到了业务动作上：攻击者能够制造一份让后续程序继续处理的提现要求。

风控参数的具体名称没有公开，我们无法判断它改的是某个审核状态、某种验证结果，还是其他业务字段。恢复出的工具专门适配了钱包逻辑；它能调用已有提现流程，因而需要追查请求由谁提出、付款内容经过了谁的核对。

以一般提现系统为例，一笔请求至少要把用户、币种、网络、收款地址和数量关联起来，审核结果也必须对应这份具体内容。如果发送请求的一端能同时改收款地址和“审核通过”的信息，接收端便需要从一个独立可信的地方重新核对；否则两个看似不同的字段，实际由同一个被控制的程序说了算。这是本次事件值得检查的授权设计，Bitget 公开材料尚不足以确定其内部究竟采用了哪种字段或校验方案。

Bitget 最新说明称，调查已排除私钥泄露。Mandiant 较早的报告则把“未观察到私钥受损证据”归于 Bitget 的调查。两者说到的都是密钥状态。区块链接受一笔符合规则的签名交易时，无法替交易所检查“账户主人有没有真的要求这次提现”。后台必须先确认用户意图，再把经过核对的内容交给资金操作环节。攻击者若控制了前面的授权信息，密钥仍被妥善保存也不足以挡住这条路径。

这款工具的能力也有具体界限。慢雾记录了后续直接修改钱包数据库提现记录、调用本机任务的尝试；其中两笔伪造的 BTC 订单进入处理后返回错误，攻击者继续查日志和订单状态。这说明某些请求仍会失败，公开报告没有确认这两笔 BTC 订单完成转账。

4 发现异常之后，转账还持续了多久

慢雾核对到的最早一笔，是北京时间 9 月 25 日 02:31:00 转入攻击者地址的 93 TRX；11 秒后，以太坊上的接收地址收到 0.84 ETH。汇总记录持续到 05:23:11，跨度约 2 小时 52 分钟。小额开始、多链转出，是已经公开的交易顺序；它们是否承担试探风控的特定目的，还需要结合程序和操作日志判断。

Bitget 的初始公告和 Mandiant 报告都把异常检测放在 02:31。交易所后来发布的处置时间线又记录：03:05，对账系统发现明显差异，风控系统自动阻断全平台提现请求；03:40 开始遏制；04:40 在尚未排除密钥泄露时，将资金转往冷钱包；05:44 关闭包括签名服务在内的钱包提现服务，并隔离相关访问。这里统一换成北京时间，以免把 UTC 与 UTC+8 拼出错误的先后关系。

对账告警、请求阻断、停止签名，发生在不同位置。用户端的提现入口已经关闭时，后台是否还留着可执行任务，已经排队的任务怎样作废，受控服务器能否直接调用下游，都要单独核实。上述时间足以让这些问题变得紧迫；公开材料没有逐笔解释 03:05 之后每项转移通过了哪条内部路径，不能简单把全部延迟归给某一个开关。

我们更关心的一项恢复检查，因此是让隔离后的旧身份、旧任务和伪造请求都失去继续付款的能力。正常用户的提现应能完成，同样内容换成过期批准、被改动的收款地址或已撤销的调用身份后应被拒绝，而且要在实际出款处核对结果。这样的检查能够回答本案暴露的问题；“告警发出来了”只能回答是否看见了异常。

5 钱还在哪里，哪些服务已经恢复

最初公告给出约 3.516 亿美元，9 月 25 日的后续公告改为约 3.875 亿美元。Bitget 解释，差额来自补入首次统计遗漏的 Zcash 和 TRON 资产。9 月 30 日更新的说明将金额列为约 3.88 亿美元，并继续归于原事件的对账与交易分类。这里引用的是交易所发布时的美元等值统计；它包含多种资产，不能拿今天的币价或一个地址的现有余额直接与其相减来计算追回金额。

交易所公布了主要接收地址和资金追踪页面。例如，公告列出的 EVM 接收地址为 0x770b10b273fc44fe9197d6bf20f145c2e98463ee。追踪地址能帮助相关平台识别流入资金；冻结表示资产在某个环节被限制转移，返还还需要进一步的处置与确认。官方目前称已有部分资产冻结，所读公告没有给出可核对的完整返还总额。公开地址接口提供的是按链分组的地址集合，也不能直接充当追回账本。

截至北京时间 10 月 1 日 00:25，提现已有以下专项恢复公告。下面只合并同一公告明确列出的范围，其他网络仍以平台实际可用状态为准：

• BTC：Bitcoin 网络在 9 月 28 日公告恢复；BSC 网络有 9 月 30 日的单独恢复公告。
• ETH：9 月 29 日公告开放 Ethereum、BSC、Arbitrum One、Base、Optimism。
• USDT：9 月 30 日公告开放 Ethereum、BSC、Solana、Tron。

其他币种、法币提现与 P2P 服务，仍按官方安排计划在 10 月 2 日 08:00 UTC，也就是北京时间 16:00 恢复。用户需要确认的是自己持有的币种和准备使用的网络；不存在凭借“恢复专员”提前开通的特殊通道。任何要求先转币、提供密码、验证码或助记词来协助恢复的消息，都应回到官方渠道核实。

这起事件接下来最有分量的进展，会是可以核对的资金返还，以及修复后提现授权确实不能再被受控后台伪造的验证结果。交易所已经把服务逐步重新打开；那份允许钱包付款的请求，今后由谁独立核准，仍值得继续追问。