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

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

本次受影响的是 Bitget 交易所使用的部分热钱包和温钱包，承担日常资金调度与提现。Bitget 称，存放主要资产的冷钱包未受影响。另一个同名产品 Bitget Wallet 是非托管钱包，使用不同的基础设施，官方表示它未卷入本次事件。

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，也就是能通过网页请求执行命令的后门，并建立远程控制连接；随后利用这里的持续访问权限，横向进入生产钱包作业服务器，部署恶意软件包。钱包作业服务器负责执行钱包相关任务，攻击者到了这里，就能接触真正推动提现流程的程序。

B 上的后门已经让攻击者到达钱包服务器，只给安全设备补洞就会留下后半段访问。恢复时还需撤销已经发出的凭据和已经建立的连接，并检查设备获准访问哪些机器、其凭据能否继续用于钱包任务。

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

慢雾从已删除文件中恢复出的提现工具，专门适配了钱包业务逻辑。它先伪造风控参数，再构造请求、调用已有提现流程。主机日志显示，相关恶意程序在北京时间 9 月 25 日 01:49 开始运行并实施盗币。风控字段名没有公开，目前无法判断它改的是审核状态、验证结果，还是其他业务值。

这类请求怎样才算获得批准？以一般提现系统为例，审核需要对应具体的用户、币种、网络、收款地址和数量。如果同一个程序既能改收款地址，又能填写“审核通过”，这份批准也会随程序一起落到攻击者手里。接收请求的环节需要从独立可信的来源核对这些内容。Bitget 内部采用了哪些字段和校验方案，公开材料尚未说明。

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

也有请求没能走通。慢雾记录了后续直接修改钱包数据库提现记录、调用本机任务的尝试：两笔伪造的 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 恢复。用户需要确认的是自己持有的币种和准备使用的网络；不存在凭借“恢复专员”提前开通的特殊通道。任何要求先转币、提供密码、验证码或助记词来协助恢复的消息，都应回到官方渠道核实。