EIP-7702 攻撃チェーンの解剖：18 時間の準備、1 本の署名、1 体のボット

更新（10/30 02:23 UTC）：Binance は《Security Incident Update》で影響を受けたアドレスの認可を失効させたと述べ、根本原因を侵害された DevOps のノート PC とサービスコンテナに向けている —— 第七節の根本原因マトリクスの「署名インフラの侵害」の行と同じ方向である。ただし失効トランザクションのハッシュは未公表で、オンチェーンでの独立確認はできないため、第七節の判断は公告前の状態のまま残している。公告の分解はBinance が根本原因を示したで。

公開オンチェーンデータと第三者分析に基づく。Binance は post-mortem を公表しておらず、根本原因は未確認。データは 2026年10月30日 00:30 UTC 時点。

TL;DR

署名は配備であり、配備は恒久であり、実行は同一性である。だが本件の本当の巧妙さはコントラクトではなく、その段取りにあった。

• 場当たりではない。 約 18 時間の準備：02:28 にテストコントラクト、13:51 と 16:20 に攻撃者自身の 3 つのウォレットで委任とスイープをリハーサル、15:59 に最終コントラクト、20:20 に攻撃。その間に 3 時間半の待機がある。
• 1 本のトランザクションではない。 認可（Type-4、20:20:59）と資産の持ち出し（通常のトランザクション、20:24:23）は 17 ブロック / 3 分 24 秒離れており、Type-4 トランザクションは mempool で公開されて見える。つまり本来は検知できた窓があった。
• 50 件の認可は nonce の降順で、有効になったのはちょうど 1 件。 降順は意図的である：昇順なら命中後に高い nonce がすべて発火し、アカウントの nonce を 15 回進めてしまう。
• 「63 種のトークン」ではない。 calldata をデコードすると配列要素は 65 個：address(0) 1 個（ETH のプレースホルダ）と 64 個の ERC-20 である。
• 持続性には直接証拠がある：その後オペレーターは sweep をさらに 12 回呼び出し、うち 4 回はトークン転送ゼロの 23,100 gas の空ポーリング —— 新しい入金がないかを確認するボットである。
• コストが不条理：約 25 億ドルを動かしたメインのスイープにかかったのは 0.000414 ETH ≈ 0.91 ドル。比率にして約 1 : 27 億。

一、準備期：18 時間、3 つのテストウォレット、1 回のリハーサル

オペレーターアドレスのトランザクションを時刻順に並べると、リズムは紛れもない：

これは攻撃者像の読みを変える。 「鍵を手に入れて送金した」ではない。標的に触れる前に、自分が支配するアカウントで経路全体を端から端まで走らせている。

悪性コントラクトの配置は 15:59、リハーサル完了は 16:47 だが、攻撃は 20:20 —— 3 時間半後である。適切な瞬間を待っていた：ホットウォレット残高のピークかもしれないし、特定の署名ウィンドウかもしれない。

二、オンチェーン：認可と実行は別のトランザクションだった

2 つの細部に注目すべきである。

第一に、認可トランザクションの input は空である。 実体は Type-4 トランザクション固有のフィールド authorization_list にあり、従来の「calldata を検査する」監視ではまったく見えない。

第二に、持ち出しはごく普通の EOA 呼び出しである。 どのアドレスからでも送れた。成功したのは、対象のコードがすでに攻撃者の実装に置き換わっており、その実装が「オペレーターのみ呼び出し可」をハードコードしていたからにすぎない。

両者の間隔は 3 分 24 秒で、Type-4 トランザクションは mempool で公開されて見える。 「取引所のアドレスが SetCode トランザクションを送っている」というアラートがあれば、そのウォレットの署名権限を停止する時間は十分にあった。

それが捕まらなかったという事実は、業界が今なおコードの書き換えではなく残高の流出を監視していることを示している。

三、nonce の降順：50 件のうちなぜちょうど 1 件が有効になったのか

このチェーンで最も洗練された部分であり、オンチェーンデータがきれいに裏づけている：

• 50 件の認可は nonce 18,914,824 から 18,914,775 まで、すべて authority は Binance 14、同一コントラクトを指し、chain_id = 1
• 有効になったのは 18,914,809 のみで、残り 49 件は invalid_nonce を返した
• 命中によりアカウント nonce は 18,914,810 へ進み、それより下の 34 件が無効になった

鍵は降順であることだ。

規則は、タプルの nonce がアカウントの現在の nonce と一致したときのみ有効になり、一致しなければリバートではなくスキップされる、というものである。したがって：

1. 824 → 810 を処理する 15 件の時点では、オンチェーンの nonce は 809 しかなく、すべて「高すぎる」のでスキップ
2. 809 で命中し、コードが書き込まれ、nonce は 810 になる
3. 残る 808 → 775 の 34 件はこの時点で「低すぎる」のですべてスキップ

昇順で提出していれば、810 から 824 が命中後にそれぞれ発火し、nonce を 15 回進めていた —— ホットウォレット自身のトランザクションキューが同期を失うことになる。降順は、有効になるのが最大 1 件であることを保証する。

gas の内訳があの 1,258,562 を説明する

gas 使用量は 1,258,562 であり、この数字は正確に一致する：

50 × 25,000  = 1,250,000   PER_EMPTY_ACCOUNT_COST をタプルごとに前払い
− 12,500                   唯一の有効タプルが既存アカウントに命中し、差額が返金
+ 21,000                   トランザクションの内在 gas
+ 62                       calldata など
= 1,258,562

1 単位も違わない。 仕様は認可リストに対して PER_EMPTY_ACCOUNT_COST（25,000）を件数分だけ内在 gas として前払いさせ、authority が空でない有効なタプルにのみ 12,500 を返金する。つまり 49 件のおとりは無料ではなく、1 件ごとにきっちり 25,000 gas を燃やし、送信者は本物も偽物も区別なく支払った。

50 件は「署名から取り込みまで」の時間差を覆っている

ウィンドウの上端は実際の nonce より 15 トランザクション上にある。多忙なホットウォレットなら、数十秒から 1 分程度のずれに相当する。

そしてこれは根本原因の手がかりでもある：秘密鍵を持ち、nonce を読めるノード接続がある攻撃者なら、認可は 1 件で足りる。50 件必要だったということは、通常署名側がライブのチェーン状態を見られないことを意味する —— バッチ事前署名か、読み取らずに署名するインターフェース経由で認可を得たかのいずれかである。

これは、コピーされた秘密鍵よりも、侵害された署名インフラを指している。

署名対象は EIP-712 ではないので、ハードウェアウォレットは描画できない

7702 の認可が署名するのは：

keccak256(0x05 ‖ rlp([chain_id, address, nonce]))

これは EIP-712 の構造化データではない。 したがってハードウェアウォレットと大半の署名インターフェースは「このアカウントのコードを 0x63e8… に委任します」を読める形に描画できない —— 利用者が目にするのは、おそらくハッシュである。

この意味論的な不可視性は 7702 の設計に組み込まれたブラインド署名リスクであり、特定のウォレットベンダーの手落ちではない。

四、実行：1 回の呼び出しで 65 アドレスを掃く

コントラクトのソースは未検証だが、calldata からインターフェースが復元できる：sweep(address recipient, address[] tokens)、セレクタ 0x8a179be4。

• arg0 = メインの受取アドレス（現在イーサリアム上で約 21.7 億ドルを保有）
• arg1 = 65 個のユニークアドレス。最初が 0x0000…0000、残り 64 個が ERC-20 コントラクト

したがって正確な言い方は「ETH のプレースホルダ 1 個 + 64 トークン」であり、「63 種のトークン」ではない。 公開分析にある「63」は、送金が成功した件数である可能性が高い —— 差は残高ゼロ、拒否された送金、重複から生じる。

設計上の細部が 3 つある：

1. 呼び出し元チェックのハードコード —— オペレーターのみが起動できる
2. address(0) を ETH のプレースホルダに —— 1 つの配列でネイティブ資産とトークンをまとめて扱う
3. 要素単位のフォールトトレランス —— 1 つのトークンが失敗してもトランザクションはリバートしない。これが 1 回の呼び出しにこれだけの資産を詰め込める理由である

なぜ approve が不要なのか：委任されたコードは Binance 14 のコンテキストで走るので、各トークンコントラクトからすれば msg.sender はホットウォレットであり、balanceOf(address(this)) はホットウォレットの残高を読む。

他人の資金を呼び出しているのではない。保有者そのものである。 これが、利用者を騙して ERC-20 の approve をさせなければならない従来のドレイナーとの根本的な違いである。

五、持続性の直接証拠：12 回のスイープと空ポーリング

認可の後、オペレーターは 3 時間半のあいだに sweep をさらに 12 回呼び出した：

23,100 gas の呼び出しはトークン転送ゼロであることが確認されている —— トランザクションの基本コスト 21,000 に 2,100 のオーバーヘッドが乗ったものである。

つまりボットが数十秒から数分おきに sweep を呼び、入ってきたものがあれば取り、なければ 2,100 gas を無駄に燃やしていた。

これは、持続的な委任が自動回収ポイントになることを示す最も直接的なオンチェーン証拠であり、「一時的な実行」という誤読に決着をつける。

示唆的な細部が 1 つある：Binance 14 には今も約 4,790 万ドルが残っている。理由としてありそうなのは、攻撃者のトークンリストがライブのチェーンスキャンではなく 65 アドレスの固定されたオフラインの列挙だったことである —— ロングテールのトークンと後から届いた資産はその外側に落ちた。22:39 の 458 万 gas のスイープもこれで説明がつく：リストの範囲内に新しいものが入ってきたのである。

六、見落とされている境界：chain_id = 1

50 件の認可はすべて chain_id 1 を持っていた。

EIP-7702 では、chain_id = 0 のみがこの EIP をサポートするすべてのチェーンでリプレイできる。本件ではそれは使われていない。 したがって：

• この認可が影響を与えられるのはイーサリアムメインネット上の Binance 14 のみ
• ビットコイン、Tron、Solana には EIP-7702 がそもそも存在しない —— それらのチェーンの流出が同じ認可から来ることはありえない
• 「少なくとも 9 チェーン、56〜62 億ドル」という枠組みは必然的に異なる種類の事象を混ぜている：他のホットウォレットの独立した侵害、Binance 自身の集約や防御的送金、利用者のパニック出金、あるいはアナリストの誤ったラベル付け

これは多チェーンの損失が架空だという意味ではない。帰属を分けて行う必要があるという意味である。 イーサリアム上の 25 億ドルには認可から実行までの完全な鎖があるが、他の場所の数字は同等の因果の証拠を伴わない残高の移動にすぎない。

すべてを「1 回の 7702 攻撃」として整理すると、この攻撃の技術的な射程を過大評価し、防御の方向を誤らせる。

七、バックドアは閉じられたか

検証可能な最後の時点において、委任はまだ残っている：

• 10/30 00:10:35 UTC の入金トランザクションでも Binance 14 には proxy_type: eip7702 と実装アドレスが付いている
• Binance 14 からの直近 50 件の送信に Type-4 の失効が存在しない（失効には address(0) を指す認可への署名が必要）
• 攻撃者の最後のスイープは 23:56:47 で、その後オペレーターの保有は約 2,591 ドル

可能性は 2 つある：Binance が他の手段で委任を無効化した —— 署名鍵のローテーション、アドレスの移行 —— が、失効は公には見えていない；あるいは委任はまだ生きており、攻撃者が単に手を止めているだけである。

いずれにせよ結論は同じである：7702 の委任の失効は「停止」や「パスワード変更」ではない。もう 1 本、署名されたオンチェーン認可を必要とする。 そして鍵がすでに漏れているなら、失効は一時的である —— 攻撃者は再び委任できる。

注目に値する逆向きの手がかりが 1 つある：攻撃者が完全な秘密鍵を持っているなら、Binance が失効に署名すれば再委任を招くだけで、目に見える綱引きが生じるはずである。それは観測されていない —— これは、攻撃者が鍵そのものを握っているのではなく、すでに閉じられた経路を通じて署名能力を得ていた、という側に傾く。

根本原因のマトリクスは次のように更新される：

八、コントラクトの脆弱性との本質的な違い

7702 はアカウントのセキュリティを、「各トランザクションの認可境界」の問題から「1 本の署名のコード保管」の問題へと変えた。

そしてホットウォレットは高頻度の出金を支えるためにオンライン署名を維持しなければならない —— これが 7702 の最悪ケースと正面衝突する。

九、防御

取引所とカストディアンにとって、優先順に：

1. ポリシー層で拒否する —— 委任先が許可リストに載っており多重署名で承認されている場合を除き、ホットウォレットのアドレスは Type-4 トランザクションを送ってはならない。経路そのものを消す唯一の手段である。
2. 読める署名 —— ハードウェアウォレットと MPC のフローは「コードを 0x… に委任する」を表示しなければならない。ペイロードが EIP-712 ではないため、これはウォレットベンダーの意図的な実装を要し、自動的には手に入らない。
3. 監視対象を変える —— 「大口の流出」から「0xef0100 のコード変更、mempool の Type-4 トランザクション、異常な nonce の跳躍」へ。読むのは実際に格納された 23 バイトの 0xef0100‖address である —— 仕様上 EXTCODESIZE は 23 を返し、EXTCODEHASH のような外部からの読み取り操作は委任を追わずインジケータ自体に作用するので、委任先アドレスは直接復元できる。
4. 単一障害点の露出を減らす —— ホットウォレットには運用に必要な分だけを置く。EOA が直接資産を保有するより、上限付きの allowance とスイープ用コントラクトの組み合わせを選ぶ。
5. 権限を分離する —— ホットウォレットの EOA をスマートウォレットの所有者として再利用しない。本件は、まさに Binance 14 から自身が所有するスマートウォレットを呼び出すことで、さらに 7.8〜8.23 億ドルの USDC を動かした。
6. インシデント対応 —— address(0) を指すタプルに署名すれば委任は消えるが、漏れた鍵を持つ攻撃者は再び委任できる。鍵のローテーションとアドレスの移行を同時に行うこと。消去は時間を買うだけで、解決ではない。

プロトコル開発者へ：extcodesize と tx.origin == msg.sender で呼び出し元を識別するのをやめること。7702 以後、その前提は成り立たない。

十、結論

この攻撃の実際の構造は、18 時間の準備、1 本の署名、1 体のボットだった：準備がコントラクトと nonce 戦略を検証し、署名がホットウォレットを攻撃者がプログラムできるアカウントに変え、その後ボットが 3 時間半にわたって回収した。

EIP-7702 は脆弱性を作っていない。 1 本の署名の帰結を「いくらか送金される」から「アドレスができることすべてを乗っ取り、それを維持する」へ拡大しただけである。

オンチェーンの証拠は、よくある 2 つの誤読も正す：委任は「一時的」ではなく —— 明示的に消去されるまで持続する；そして掃き出されたのは「63 種のトークン」ではなく、65 要素の配列に入った 64 トークンとネイティブ ETH である。

業界への教訓はコントラクト層ではなく署名の意味論の層にある：署名システムが「送金」と「コードの委任」を区別できず、承認者に 0xef0100 の委任先を示せず、mempool の Type-4 トランザクションに警報を出せない限り、オンラインで署名しているすべてのホットウォレットは潜在的な Binance 14 である。

結論。 プラットフォームがこれを本当に修正したかは、声明の数ではなく 3 点で判断すること：address(0) を指す失効がオンチェーンに現れたか、ホットウォレットのアドレスが変わったか、署名ポリシーが Type-4 を拒否するようになったか。 どれか 1 つでも欠けていれば、バックドアは単に放置されているだけである。

参考資料

• EIP-7702 仕様
• 認可トランザクション（Type-4）
• 資産を空にしたトランザクション
• 悪性コントラクトの配置トランザクション
• Zealynx：EIP-7702 ウォレットセキュリティ
• Halborn：EIP-7702 のセキュリティ考慮事項
• Threat Landscape：Binance ホットウォレットと 7702 委任
• Ondology Labs：EIP-7702 攻撃分析

あわせて読む：Binance ホットウォレット陥落：正当な署名 1 本、8 分、56 億ドル、EIP-7702 の署名フロー。gas コストは ETH ≈ 2,209 ドルで換算。公開オンチェーンデータと第三者分析に基づき、Binance は post-mortem を公表しておらず、根本原因は未確認。投資助言ではない。DYOR。