背景介绍

2025年2⽉21⽇晚，我们监测到⼀笔涉及 Bybit交易所的重⼤安全事件。当晚 02:16 UTC ，我们监测到 Bybit Cold Wallet 发起⼀笔⼤额转账， https://etherscan.io/tx/0xb61413c495fdad6114a7aa863a00b2e3c28945979a10885b12b30316ea9f072c，

转出 401,346 ETH 、8,000 mETH、90,375 stETH 和15,000 cmETH 价值约 1.5 BillionUSD 。经过多⽅确认，确定这是⼀起针对 Bybit 的攻击。

背景知识

交易所钱包架构

通常，交易所能直接访问互联⽹的钱包为热钱包（ Hot Wallet ），因为需要频繁转账，通常热钱包的私钥都是在线的，⽽且热钱包资⾦⼀般较少，只需要满⾜交易所的⽇常流⽔即可。⽽交易所的冷钱包（ Cold Wallet ）⼀般存放着交易所的⼤部分资⾦，相当于交易所的企业账户。冷钱包只需要在特殊的条件下才会使⽤，例如：补充热钱包资⾦等。所以，冷钱包⼀般都是离线钱包，不会直接接触互联⽹；⽽且绝⼤多数交易所使⽤的冷钱包都是多签钱包（ multisign wallet ）。此次 Bybit 的冷钱包也不例外，使⽤的是 safe 公司的多签钱包。

代理合约

因为在区块链上部署的智能合约不可修改，但是相同通常会遇到业务变化的问题，所以催⽣出⼀种设计机制，就是代理合约。代理合约是⼀种设计模式，允许将智能合约的业务逻辑和存储数据分离。其核⼼机制是通过⼀个“代理合约”作为中间层，将⽤户的交易请求转发到逻辑合约执行，但最终状态（数据和资产）保存在代理合约内。通常情况下代理合约分为 transparent proxy ，UUPS ， Beacon 等。其中最常⻅的就是 Transparent Proxy 和 UUPS 。所有的 Proxy 合约都需要设置 implementation ，也就是逻辑合约。

攻击及事件分析

经过我们详细分析，攻击者的攻击分为了3个阶段。

阶段1

攻击者在 2025-02-18 03:29:11 UTC 部署了⼀个攻击合约 0x96221423681A6d52E184D440a8eFCEbB105C7242 ，部署合约的交易为https://etherscan.io/tx/0x84cd9d6cb84df9df4be638899f4a56053ed98042febd489ef3d51a3ed3652d40 。后续我们称为攻击合约7242 。

随后，攻击者在 2025-02-18 06:00:35 UTC ⼜部署了⼀个攻击合约 0xbDd077f651EBe7f7b3cE16fe5F2b025BE2969516 ，部署合约的交易为 https://etherscan.io/tx/0xc47ac9038127cef763a1c9a33309a645c5a4fa9df1b4858634ae596ccc2aee5e 。后续我们称为攻击合约9516 。

阶段2

攻击者使 Bybit 的三个多签钱包签名了⼀笔交易，交易哈希为https://etherscan.io/tx/0x46deef0f52e3a983b67abf4714448a41dd7ffd6d32d32da69d62081c68ad7882 。我们详细分析⼀下这笔交易。

通过交易的执⾏流，我们可以看出，这比交易其实很简单。就是拿到了多签钱包针对交易的签名，然后调⽤Safe钱包执⾏这笔交易。执⾏的交易同样也很简单，就是调⽤了攻击合约 7242 的 transfer 函数，然后 transfer 函数的 _to 为攻击合约 9516 ，_value 为 0 。

那么，我们通过反编译看⼀下攻击合约7242的逻辑。

随后，我们看到创建好的 Token 的 owner 同样也是 launchpad 官网的智能合约。

我们可以看到，攻击合约7242的transfer函数很简单，就是将该合约的 slot0 改为 transfer 函数的第⼀个参数 recipient 。接下来，我们继续观察执⾏流程。⾸先，safe 钱包的 proxy 合约通过 delegatecall 调⽤ safe 钱包的 impl 合约，随后， impl 合约⼜通过 delegatecall 调⽤了攻击合约 transfer 函数。因为 delegatecall 的原理是⽤调⽤者的上下⽂，执⾏被调⽤的代码。所以，执⾏攻击合约的上下⽂为 safe 钱包的 proxy 合约，所以修改的slot0也为safe钱包 proxy 合约的 slot0 。我们继续看⼀下 safe 钱包的 proxy 合约的代码。

我们发现， safe 钱包的 proxy 合约的 slot0 为 safe 钱包的逻辑合约地址。⼜因为攻击合约 7242 的 transfer 函数的功能为修改 slot0 。那么，执⾏完上述的流程后，safe 钱包的逻辑合约地址已经被攻击者修改为了攻击合约 9516 。⾄此，Bybit 的这个冷钱包已经完全被攻击者接管。

阶段3

攻击者在接管了 Bybit 的这个冷钱包之后，调⽤了 攻击合约9516 的函数 sweepERC20 和 sweepETH 将该冷钱包的所有 ERC20 Token 和 ETH 全部转走。⾄此，攻击完成。我们看⼀下 sweepERC20 的具体实现。

其功能就是将指定的冷钱包中指定的 token 余额转入⽬标钱包，攻击者依次将冷钱包中的 90 USDT ，

8,000 mETH

90,375 stETH

15,000 cmETH

依次转走。接下来，我们看⼀下 sweepETH 的具体实现，

可以看到，该函数的主要功能是转走钱包中的所有 ETH 到攻击者指定的地址。攻击者利⽤这个函数，将冷钱包的所有 ETH 转走，⾄此攻击阶段已经完成。

发现的攻击技巧

我们在分析的过程中发现攻击者的⼿法非常缜密，我们将详细阐述我们在分析过程中的发现：

1. 攻击者⾸先利⽤地址0x5C6120BA4C5B5E18DDcb9589e649e86EE6d540dD

创建了⼀个⽤于测试的 safe 钱包，

接着，⼜将攻击在链上进⾏了⼀遍演练，

我们可以看到该函数交易的执⾏流程，

随后，同样利⽤攻击合约9516 的 sweepERC20 和 sweepETH 测试在⼀个区块中提币。

2. 攻击合约 7242 和攻击合约 9516 均有修改 slot0 的功能，

攻击者并没有直接调⽤复杂的攻击合约，攻击合约 9516 ，⽽是调⽤简单的类似 transparent proxy 的攻击合约 7242 ，修改冷钱包的 impl 。据我们猜测，可能是攻击者担⼼调⽤的合约功能过于复杂可能会导致触发未知的防护，或者引起相关⼈员的警觉。⽽且攻击的函数命名也是极具迷惑性的 transfer 。攻击者在修改完冷钱包的 impl 合约时，并没有直接进⾏⼤额转账，⽽是⾸先转了 90 USDT 。后续才完成⼤额转账。

可以看到，攻击者先转账了⼀笔很⼩的⾦额进⾏测试。为了防⽌意外发⽣，等成功上链后，才进⾏⼤额转账。我们可以看到，所有的⼤额转账均在⼀个区块编号 21895251 中完成。

未解之谜

为什么多签机制被攻击者轻易突破？我们列出了⼏种可能：

1. ⾸先就是 safe 钱包的合约或者前端遭受了供应链攻击，据了解 bybit 不仅仅是 ETH 使⽤了 safe，如果是这种情况使⽤ safe 的所有钱包均会被攻击者掏空。⽽且事后 safe 也发布公告，经过深入调查，其前端、合约不存在供应链攻击。

2. 多签持有者之⼀被攻击者突破，攻击者利⽤其发起了⼀笔 transfer 转账，其他⼈员没有仔细审核变进⾏了签名。我们分析，掌握如此⼤额的钱包的私钥持有⼈，所进⾏的⼀切操作可能都需要进⾏沟通或者进⾏内部流程，所以应该不会出现不知道是什么情况就进⾏签名。

3. 多签的所有持有者均被攻击者突破，攻击者利⽤所有多签持有者进⾏签名最后完成攻击。

4. 多签的UI界⾯被攻击者针对性的修改，误导了多签持有⼈。

5. 攻击者潜伏到内部的系统，发起了⼀套完整的流程。

⽬前，在没有更多信息披露的状态下，很难最终确定攻击者使⽤的⽅法。但是能确定的是，攻击者是通过缜密的前期侦查、链上测试和实验、到针对多签持有⼈或者系统的复杂的攻击，攻击者非常精通链上和链下的攻击⼿段。我们也期待后续 bybit 能够披露更多的信息，我们也愿意向 bybit 提供相关的技术⽀持。

总结

在本次攻击事件中， Bybit 交易所共损失15亿美元，此次攻击事件是历史上损失最多的针对交易所的攻击。其实，类似的攻击还在印度交易所 WarirX 中发⽣过。交易所由于其拥有巨额的资⾦，往往是顶级攻击者关注的⽬标，甚⾄会遭受国家⽀持的 APT 攻击。所以，交易所应该从多⽅⾯来提升安全级别，减少被攻击的⻛险。但不限于，⽤于多签的设备（计算机，移动设备）等离⽹；需要执⾏的交易先在本地进⾏模拟，来看是否符合预期；在整体运营和⽇常的内容流程中多次、多⽅进⾏验证。最后，在Web3安全中，没有任何⼀种措施是 sliver bullet 。需要在和攻击者对抗中持续提升，才能立于不败之地。