返回

2026/11/03

一个签名为何能持续掏空 Binance 热钱包：攻击背后的 EIP-7702 委托

50 份预签名的 EIP-7702 授权、一份命中，委托在钱包清空后依然有效。本文解析其原理，以及热钱包运营方应监控哪些内容。

在我们关于 Binance 入侵事件的第一篇文章中，我们分析了攻击据报道是如何开始的：一台被入侵的 DevOps 笔记本电脑，以及攻击者随后进入了负责批准敏感操作的系统。此后，安全公司 Blockaid 的链上分析揭示了攻击在 Ethereum 上最后阶段的运作方式。它利用了 EIP-7702——2025 年 5 月加入 Ethereum 的一项功能——并暴露出许多热钱包运营方尚未纳入规划的风险。

简而言之：一份签名授权就把 Binance 最大的 Ethereum 热钱包变成了攻击者可以控制的账户。这种控制并没有在钱包被清空时结束，即使轮换密钥也不会结束。

要点

  • 攻击者把覆盖 50 个连续 nonce 的 50 份预签名 EIP-7702 授权打包进一笔交易；其中恰好一份匹配，钱包的执行权由此交给了攻击者的合约。
  • EIP-7702 委托会一直有效，直到账户替换或清除它。首次转移之后到账的存款（某一时刻超过 2 亿美元）在没有任何新签名的情况下被转走。
  • 轮换私钥并不能解除委托，因为委托属于地址本身。只有明确的撤销操作才能清除它。
  • 攻击者如何获得 50 个有效签名仍是未解之谜。Binance 表示尚未发现私钥泄露的证据。
  • 热钱包运营方应监控委托状态，拒绝签署非预期的授权，并把明确的撤销步骤写入事件响应手册。

EIP-7702 快速入门

EIP-7702 允许普通的 Ethereum 账户（外部拥有账户，即 EOA）将其执行委托给一个智能合约。账户所有者签署一份授权，其中指定合约地址、链以及账户当前的 nonce。携带该授权的交易被处理后，对该账户的调用就会运行该合约的代码，就像这个账户是一个智能合约钱包一样。这项功能有其正当用途，例如批量处理交易以及代用户支付手续费。

规范中的三个细节与本次事件密切相关：

  • 授权通过一种新的交易类型——类型 4（0x04）——传递，一笔交易可以携带一个授权列表。任何人都可以提交这笔交易；授权只需要带有该账户的有效签名。
  • 每份授权只有在其 nonce 等于账户当前 nonce 时才有效。不匹配时，只会跳过这一份授权，交易会继续处理下一份。
  • 委托是持久的。它会一直保持，直到账户签署一份指向其他地址的新授权，或一份指向零地址的授权（后者会清除委托）。

Binance 14 钱包是如何被接管的

繁忙的交易所热钱包会不断发送交易，因此它的 nonce 一直在变化。提前准备签名授权的攻击者无法知道交易上链时哪个 nonce 才是当前值。根据 Blockaid 的分析，攻击者的解决办法是签署一个范围，而不是单个值。

时间（UTC，10 月 29 日）事件经过
15:59攻击者部署了一个“清扫”（sweeper）合约。该合约未经验证，只有攻击者的操作地址可以调用。
20:20:59一笔类型 4 交易携带了 50 份 EIP-7702 授权，全部使用 Binance 14 热钱包的密钥签名，对应 50 个连续的 nonce。其中恰好一份与钱包的实时 nonce 匹配，钱包随即被委托给清扫合约。
20:24:23对清扫合约的一次调用就从钱包中转走了约 167,464 ETH、16.15 亿 USDT 以及数十种其他代币，只留下 1 ETH 用于支付手续费。
20:41在仍处于委托状态的情况下，该钱包被用来从 Binance 14 控制的另一个智能账户中转走约 8.23 亿 USDC。
21:04 至 23:56随着新资金到账，钱包又被清扫了四次。仅 21:44 这一次，就有超过 2 亿美元的新存款在没有任何新签名的情况下被转走。
00:10（10 月 30 日）根据 Hypernative 的时间线，委托被撤销。

USDC 这一步还揭示了第二个影响。被委托的账户会保留它在其他合约中拥有的所有角色：所有者、执行者、获批准的支出方。谁控制了它的执行，谁就能使用所有这些角色。

为什么空钱包依然危险

资产被盗后，人们自然会认为：空钱包已经没有什么可失去的，而更换密钥就能终止攻击者的访问。在 EIP-7702 下，这两种想法都是错误的。委托附着在地址上，而不是余额或某一份密钥上。只要委托还在，任何转入该地址的资金都可以被委托合约转走，攻击者无需任何额外签名。

这正是本次事件中发生的情况。首次清扫后，资金仍不断转入 Binance 14，并再次被转走。轮换密钥也无济于事：正如 Blockaid 指出的，清除委托需要同一账户签署一份指向零地址的新授权。在该撤销操作被处理之前，应将该地址视为由攻击者控制。

提示： 发生事件时，先撤销委托，再轮换密钥并补充资金。在确认委托已被清除之前，停止所有向受影响地址转账的自动化流程。

尚未解决的问题

所有 50 份授权都带有 Binance 14 密钥的有效签名。大致有两种解释，而公开证据目前还无法确定是哪一种：

  • 密钥已泄露，攻击者直接签署了这些授权。
  • 签名基础设施被滥用：攻击者在从未提取密钥的情况下，让 Binance 自己的签名系统签署了由攻击者选择的数据。

Binance 表示尚未发现钱包私钥泄露的证据，调查仍在进行中。Blockaid 的 CEO 对 Cointelegraph 表示，这些活动看起来更像是签名基础设施遭到入侵，而不是密钥泄露，但这只是外部的初步评估。在 Binance 发布事后分析报告之前，我们将这个问题视为悬而未决。

如果您运营热钱包，应该怎么做

1. 监控委托状态

被委托的账户拥有代码。在 EIP-7702 下，它的代码是委托标识 0xef0100，后面跟着被委托合约的 20 字节地址。普通 EOA 则完全没有代码。您可以通过标准的 JSON-RPC 调用检查任意地址：

curl -s -X POST -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","id":1,"method":"eth_getCode","params":["0xYOUR_HOT_WALLET","latest"]}' \
  https://YOUR_RPC_ENDPOINT

结果为 0x 表示没有委托。结果以 0xef0100 开头则表示该地址已被委托。请在每个区块或以较短间隔对每个热钱包进行检查，一旦出现任何计划外的变化，立即发出告警。

2. 监视涉及您地址的类型 4 交易

委托您钱包的交易不一定来自您的钱包。只要携带由您的密钥签署的有效授权，任何人都可以提交它。请监控授权列表中包含您任一地址签名的类型 4 交易，而不仅仅是从这些地址发出的交易。

3. 维护委托清单

对于您运营的每个地址，记录它是否应该被委托；如果应该，委托给哪个经过审计的合约。清单之外的任何委托都应视为安全事件。如果您不使用 EIP-7702，那么每个热钱包的预期状态很简单：没有代码。

4. 在签名端拒绝非预期的授权

EIP-7702 授权有其专用的签名格式：字节 0x05 后接编码后的链 ID、合约地址和 nonce，再取其哈希。签名服务和 HSM 策略可以识别这种格式。如果您不使用委托，请完全阻止此类数据；如果使用，只允许已知的合约地址。另请注意，链 ID 为 0 的授权在所有链上都有效。

5. 把明确的撤销步骤写入事件响应手册

为每个钱包写明如何撤销委托：由谁签署零地址授权、从哪个系统签署，以及如何确认撤销已生效（地址的代码重新变为 0x）。其中还应包括停止向受影响地址的入账转账，并在真正需要之前演练这一流程。

提示： 同样的思路也适用于加密货币以外的领域。任何比创建它的凭据存续更久的授权，例如 OAuth 刷新令牌、委托的云角色或长期有效的 CI/CD 令牌，都需要在事件响应中有独立的、明确的撤销步骤。

LOGIQ 能提供哪些帮助

LOGIQ 帮助企业梳理在其 Linux 服务器、云账户和流水线中，哪些人和哪些系统能够以何种权限执行操作，并建立覆盖委托访问（而不仅仅是密码和密钥）的监控和事件响应流程。如果您希望请人再审视一下自己的控制措施，请阅读上文提到的我们关于此次入侵的第一篇文章，或通过我们的网站与我们联系。

参考来源