多签通过与资产失守之间：Bybit 被盗事件留下的应急处置账本

在一次大额提币异常中，值班人员需要同时核对几组变量：交易是谁发起的，审批人看到的页面是否可信，签名设备显示的收款地址和链上实际地址是否一致，钱包余额变化有没有超过日常阈值，异常发生后哪些权限还能继续使用。只要其中一项没有被独立确认，所谓“多签安全”就可能只剩下多人点击确认。

2025年2月，Bybit 一枚以太坊冷钱包遭到攻击，约14.6亿美元资产被转出。公开披露信息显示，攻击者并没有简单破解所有签名者的私钥，而是通过篡改或控制交易签名环节，使签名人员看到的内容与最终执行内容出现偏差，随后完成资产转移。这个案例之所以值得反复复盘，原因在于它同时暴露了两个容易被混淆的事实：签名人数增加了，操作链条却未必更安全；资产进入冷钱包了，提币流程也未必已经脱离线上风险。

对于交易所、托管机构和管理大额链上资金的团队来说，真正需要重做的不是再添一个安全产品，而是把一次攻击拆成可检查的动作，明确每个节点由谁确认、出现异常后能否停止、事件结束后怎样向用户和监管方交代。

准备：先画出一笔转账会经过哪些手

安全应急不能从“发现被盗”才开始。准备阶段最重要的工作，是把资产、人员、系统和外部联络方式列成一张能在夜间执行的清单。

第一步是区分钱包用途。客户热钱包、运营资金钱包、冷钱包、归集钱包和手续费钱包，不能只按余额区分，还要记录各自的提币限额、签名人数、部署位置、日常使用频率以及对应的审批人。对每个钱包，都应设置正常交易画像，例如单笔金额、每日笔数、常见收款地址、常用链和高峰时段。一旦出现新地址、大额跨链或短时间连续拆分转账，系统应当自动提高验证等级。

第二步是核对签名链路。很多团队只记录“几个人签了名”，却没有记录签名前到底看到了什么。应急准备阶段必须明确：交易构造端、审批网页、硬件签名器、广播节点和链上浏览器，是否由不同系统独立提供信息。签名者不能只依赖同一个网页上的收款地址，至少要通过独立设备或只读节点核对目标地址、金额、代币类型、调用数据和手续费。

第三步是准备停机权限。发生异常时，谁有权暂停提币，谁能冻结特定钱包，谁能关闭自动归集，谁能通知托管方，谁负责联系链上分析机构和执法部门，都要写成明确名单。更关键的是，暂停动作不能依赖遭到怀疑的同一套后台。若控制台被入侵，继续用它执行“紧急冻结”，可能只是让攻击者获得更多操作机会。

执行：攻击者往往先改信息，再等人签字

Bybit事件给出的警示，是签名者本身未必是第一突破口。攻击者可能先从前端、开发环境、第三方托管工具、浏览器插件或内部账号入手，改变交易人员看到的内容，再利用正常流程完成授权。

在这类攻击中，常见路径大致分为四段。

第一段是取得操作环境的影响力。攻击者可能窃取员工凭证、入侵办公终端、污染软件更新，或者控制与钱包管理相关的第三方服务。只要能够影响交易创建页面，就有机会把恶意参数伪装成正常提币。

第二段是制造视觉一致、链上不一致的交易。页面显示的地址、资产和金额看起来正常，但真正提交给签名器的数据已经发生变化。若签名设备只显示摘要，或者签名人员习惯通过网页确认而不是核对完整调用内容，异常就容易被放过。

第三段是利用组织信任完成审批。多签机制降低了单人失误的风险，却没有自动解决“多人看到同一份错误信息”的问题。如果所有审批人使用同一个被篡改的页面，多个签名只会把一次错误放大成正式交易。

第四段是快速拆分和转移。资产转出后，攻击者可能通过多个地址分散资金，换成流动性更强的资产，再经过跨链桥、混币服务或不同交易平台增加追踪难度。此时每分钟都可能影响追回概率，因此系统需要在第一笔异常出现时就触发人工升级，而不是等整笔钱包余额归零后再处理。

执行阶段的原则是先限制损失，再判断全部原因。可以暂时关闭高风险提币、暂停自动归集、切换广播节点，并保留仍然安全的钱包通道。任何“快速修复前端”的操作，都不能覆盖原始文件和访问记录。

检查：把页面记录、签名记录和链上事实放在一起

事件确认不能只看钱包余额。应急团队应当建立一条独立时间线，从最早的异常登录、权限变更、交易创建、签名批准，一直记录到链上广播、资金拆分和外部平台响应。

重点检查四类证据。

其一是身份记录。包括登录地点、设备指纹、令牌使用、管理员操作、API调用和审批人的实际网络环境。若某个账号在不常用的设备上生成交易，或者在非工作时段突然修改地址白名单，应当与链上动作逐一对应。

其二是交易原文。不能只保存网页截图，还要保留待签交易、签名数据、广播内容、合约调用参数和节点返回结果。截图能证明人员看到了什么，却不一定能证明链上执行了什么。

其三是系统完整性。前端发布记录、依赖包变更、云服务日志、终端进程、浏览器扩展和远程控制工具，都要进行取证。此时不应贸然卸载可疑软件或重装服务器，因为那可能直接破坏关键证据。

其四是资产流向。使用多个链上分析工具交叉标记攻击地址，跟踪资金是否进入交易所、场外服务、跨链桥或稳定币发行方。若资金抵达具备冻结能力的平台，应马上提交包含交易哈希、地址关系、资产种类和时间线的正式通知，避免只发一封没有证据附件的“请帮忙冻结”。

合规处置也在这一阶段同步展开。机构需要根据注册地、客户所在地、托管协议和业务牌照要求，判断是否触发重大安全事件报告、客户通知、反洗钱审查或执法协查。对外沟通应区分已确认事实、正在核实内容和暂时无法判断的部分，不能为了稳定情绪提前承诺追回比例或最终损失。

回滚与复盘：暂停权限不等于恢复业务

当攻击范围被控制后，机构通常会面临两个压力：客户要求尽快恢复提币，内部希望尽快恢复原有系统。此时如果只把被盗钱包换成新地址，再把旧权限原样复制过去，风险很可能随业务恢复一起回来。

恢复前至少要完成四项工作。

一是重新生成或轮换高权限凭证，审查签名人设备，撤销不必要的管理员、API和远程访问权限。对于受污染环境中使用过的密钥，不能因为暂时没有发现异常就继续沿用。

二是采用分批恢复。先用小额测试交易验证地址展示、签名器显示、广播节点和链上结果，再逐步提高额度。每一批交易都要由独立人员复核，不能用一次成功测试替代全天候监控。

三是建立双通道核验。交易页面显示的内容与链上只读节点、硬件设备或离线生成的摘要必须能够相互印证。大额提币还应设置人工回拨、延迟执行和异常取消机制，给团队留下真正可以停止交易的时间。

四是形成责任清晰的事件报告。报告不能停留在“黑客入侵、资金被盗、系统已修复”三句话，而要说明攻击从哪里开始、哪一道检查没有生效、哪些权限扩大了影响、哪些合作方参与了拦截、客户损失如何核算、后续整改由谁负责以及何时验收。

对交易所和托管机构而言，今天就能执行的动作很具体：抽查一笔大额提币，从创建页面一路追到链上哈希；让两名审批人分别使用不同信息源核对收款地址；检查是否保存了完整签名原文和管理员操作日志；把暂停提币、通知客户、联系交易所与提交监管报告的联系人重新确认一遍。安全系统最终能否挡住攻击，往往取决于异常出现后的前十五分钟，团队手里有没有一套不依赖猜测、也不依赖单一后台的处置流程。