戻る

2026/11/03

1つの署名が Binance のホットウォレットを繰り返し空にした仕組み：侵害の背後にあった EIP-7702 の委任

事前署名された50件の EIP-7702 認可のうち1件が一致し、委任はウォレットが空になった後も残りました。その仕組みと、ホットウォレット運用者が監視すべき点を解説します。

Binance の侵害に関する最初の記事では、攻撃がどのように始まったとされているかを取り上げました。侵害された DevOps 担当者のノート PC と、重要な操作を承認するシステムにまで到達した攻撃者です。その後、セキュリティ企業 Blockaid のオンチェーン分析により、Ethereum 上での最終段階の仕組みが明らかになりました。この攻撃には、2025年5月に Ethereum に追加された機能である EIP-7702 が使われており、多くのホットウォレット運用者がまだ想定していないリスクを示しています。

要点をまとめると、1つの署名済み認可によって、Binance 最大の Ethereum ホットウォレットが攻撃者の制御できるアカウントに変わりました。その制御はウォレットが空になっても終わらず、鍵をローテーションしても終わらなかったはずです。

重要なポイント

  • 攻撃者は、連続する50個のノンスに対応する事前署名済みの EIP-7702 認可50件を1つのトランザクションにまとめました。そのうちちょうど1件が一致し、ウォレットの実行権限が攻撃者のコントラクトに渡りました。
  • EIP-7702 の委任は、アカウント自身が置き換えるか解除するまで有効なままです。最初の引き出しの後に入金された資金（ある時点では2億ドル超）も、新たな署名なしに奪われました。
  • 委任はアドレスに紐づくため、秘密鍵をローテーションしても委任は解除されません。解除できるのは明示的な取り消しだけです。
  • 攻撃者が有効な署名を50件どのように入手したのかは、まだ明らかになっていません。Binance は、秘密鍵が漏洩した証拠は見つかっていないとしています。
  • ホットウォレット運用者は、委任の状態を監視し、意図しない認可には署名せず、明示的な取り消しをインシデント対応のランブックに組み込むべきです。

EIP-7702 の基礎

EIP-7702 は、通常の Ethereum アカウント（外部所有アカウント、EOA）が自らの実行をスマートコントラクトに委任できるようにする仕組みです。アカウントの所有者は、コントラクトのアドレス、チェーン、アカウントの現在のノンスを指定した認可に署名します。この認可を含むトランザクションが処理されると、そのアカウントへの呼び出しは、アカウントがスマートコントラクトウォレットであるかのようにコントラクトのコードを実行します。この機能は、トランザクションのバッチ処理や、ユーザーに代わって手数料を支払うといった正当な目的のために存在します。

今回のインシデントでは、仕様の次の3点が重要です。

  • 認可は新しいトランザクションタイプであるタイプ4（0x04）で送られ、1つのトランザクションに複数の認可を含めることができます。このトランザクションは誰でも送信でき、認可にはアカウントの有効な署名さえあれば十分です。
  • 各認可は、そのノンスがアカウントの現在のノンスと一致する場合にのみ有効です。一致しない場合はその認可だけがスキップされ、トランザクションは次の認可の処理に進みます。
  • 委任は永続的です。アカウントが別のコントラクトを指す新しい認可、またはゼロアドレスを指して委任を解除する認可に署名するまで、そのまま残ります。

Binance 14 ウォレットはどのように乗っ取られたか

取引所の稼働中のホットウォレットは絶えずトランザクションを送信するため、ノンスは常に変化しています。事前に署名済みの認可を用意する攻撃者は、トランザクションが取り込まれる時点でどのノンスが有効になっているかを知ることができません。Blockaid の分析によると、攻撃者は単一の値ではなく、ある範囲に対して署名することでこの問題を解決しました。

時刻（UTC、10月29日）出来事
15:59攻撃者が「スイーパー」コントラクトをデプロイします。このコントラクトは検証されておらず、攻撃者のオペレーターアドレスからしか呼び出せません。
20:20:591つのタイプ4トランザクションに、すべて Binance 14 ホットウォレットの鍵で署名された、連続する50個のノンスに対する EIP-7702 認可50件が含まれていました。そのうちちょうど1件がウォレットの現在のノンスと一致し、ウォレットはスイーパーに委任されました。
20:24:23スイーパーへの1回の呼び出しで、約167,464 ETH、16.15億 USDT、その他数十種類のトークンがウォレットから移され、手数料用に1 ETH だけが残されました。
20:41委任されたままのウォレットを使って、Binance 14 が管理していた別のスマートアカウントから約8億2,300万 USDC が移されました。
21:04～23:56新たな資金が入金されるたびに、ウォレットはさらに4回引き出されました。21:44 の1回だけで、2億ドルを超える新規入金が新たな署名なしに奪われました。
00:10（10月30日）Hypernative のタイムラインによると、委任が取り消されました。

USDC の件は、もう1つの影響を示しています。委任されたアカウントは、他のコントラクトで保持しているすべての役割（オーナー、実行者、承認済みの支出者）をそのまま持ち続けます。そのアカウントの実行を制御する者は、それらすべてを使えるのです。

空のウォレットがなぜ依然として危険だったのか

盗難の後には、空のウォレットにはもう失うものがない、新しい鍵にすれば攻撃者のアクセスは終わる、と考えるのが自然です。しかし EIP-7702 では、どちらも誤りです。委任はアドレスに紐づいており、残高や特定の鍵のコピーに紐づくものではありません。委任が有効な限り、そのアドレスに送られたものはすべて委任先のコントラクトによって引き出される可能性があり、攻撃者は追加の署名を必要としません。

今回まさにそれが起きました。最初の引き出しの後も Binance 14 には資金が入り続け、それらも再び引き出されました。鍵をローテーションしても効果はなかったでしょう。Blockaid が指摘するように、委任を解除するには、同じアカウントからゼロアドレスを指す新しい認可が必要です。その取り消しが処理されるまでは、そのアドレスは攻撃者の制御下にあるものとして扱うべきです。

ヒント：インシデント発生時は、まず委任を取り消し、その後に鍵のローテーションと資金の補充を行ってください。委任が解除されたことを確認するまで、影響を受けたアドレスへ資金を送る自動処理はすべて停止してください。

まだ解明されていないこと

50件の認可はすべて、Binance 14 の鍵による有効な署名を持っていました。大きく分けて2つの説明が考えられますが、公開されている証拠からはまだどちらとも判断できません。

  • 鍵が漏洩した：攻撃者が認可に直接署名した。
  • 署名インフラが悪用された：攻撃者は鍵を抜き取ることなく、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、コントラクトアドレス、ノンスを続けたもののハッシュです。署名サービスや HSM のポリシーでは、この形式を識別できます。委任を使っていない場合はこれらのペイロードを完全にブロックし、使っている場合は既知のコントラクトアドレスのみを許可してください。また、チェーン ID が0の認可はすべてのチェーンで有効である点にも注意してください。

5. 明示的な取り消しをインシデント対応ランブックに組み込む

ウォレットごとに委任の取り消し方法を文書化してください。誰がゼロアドレスへの認可に署名するのか、どのシステムから行うのか、そして取り消しが反映されたことをどう確認するのか（アドレスのコードが再び 0x になっていること）です。影響を受けたアドレスへの入金を止める手順も含め、必要になる前に手順を訓練しておいてください。

ヒント：同じ考え方は暗号資産以外にも当てはまります。OAuth のリフレッシュトークン、委任されたクラウドロール、長期間有効な CI/CD トークンなど、それを作成した認証情報よりも長く残る権限付与には、インシデント対応の中で個別に明示的な取り消し手順が必要です。

LOGIQ がお手伝いできること

LOGIQ は、Linux サーバー、クラウドアカウント、パイプライン全体で、誰が、また何が権限を持って操作できるのかを見直し、パスワードや鍵だけでなく委任されたアクセスもカバーする監視とインシデント対応の手順づくりを支援しています。自社の管理策を改めて確認したい場合は、上記の侵害に関する最初の記事をお読みいただくか、当社ウェブサイトからお問い合わせください。

出典