北京時間 2026 年 10 月 30 日、04:24。
オンチェーンの記録では、資金は 0x28C6…1d60 から出ている。このアドレスは Binance 14 と呼ばれ、バイナンス最大のイーサリアムホットウォレットの一つで、1 日に数千件の出金を送っている。この取引では 167,464 ETH、16.15 億 USDT、さらに 60 種類以上のトークンが送金され、当時の価格で約 25 億ドルに相当する。ウォレットには最後に 1 ETH だけが残った。
手数料は 0.0004 ETH、1 ドル未満。
3 分前の 04:21、誰かがこのアドレスに EIP-7702 タイプのトランザクションを送信し、その中に 50 件の承認が詰め込まれ、nonce は 18,914,775 から 18,914,824 まで並んでいた。49 件は無効、1 件がヒットした。ヒットとはつまり、この秒から Binance 14 へのあらゆる呼び出しが、攻撃者が前夜 23:59 にデプロイしたコントラクト、すなわち未検証で sweep 関数を一つだけ持つスイーパーを実行するということだ。
こうして Binance 14 はもはや一つのウォレットではなくなった。それは他人のプログラムを内側に詰め込んだ外殻になった。
08:06 になってもその委任はまだ残っていた。3 時間 45 分の間、誰もそれを取り消さなかった。
そして「取り消し」という行為は、同じ鍵でもう一度署名するだけで済む。その日の朝 06:55、バイナンスはまだこの鍵を使って、スイープされなかった細々としたトークンを自分のウォレットに戻していた。
EIP-7702 のロジックはこうだ。通常のアドレス(EOA)がスマートコントラクトのコードをレンタルできるようにする。アドレス、残高、秘密鍵はすべて変わらない。レンタルの方法は、このアドレスの code フィールドに 23 バイトを書き込むこと、つまり 0xef0100 にコントラクトアドレスを加えたものだ。この 23 バイトは実行可能なコードではなく、ポインタである。これ以降、誰かがこのアドレスを呼び出すと、EVM はポインタが指すコードをロードし、このアドレス自身のコンテキストで実行する。address(this) は依然としてそれ自身であり、残高もその残高のままである。
そこにバグはない。ZeroDev の創業者で EIP-7702 の関係者である Derek Chiang は、事件当日に率直にこう述べた。EIP-7702 自体に脆弱性はなく、この標準をサポートするウォレットのユーザーは慌てる必要はない。彼はさらに付け加えた。攻撃者が 7702 を使うには、秘密鍵を掌握するか、バイナンスに 7702 の承認に署名させるよう誘導するかのどちらかが必要だと。
これが攻撃ツールとして使われたのは初めてではない。イーサリアムのPectraアップグレード後、Wintermuteは数週間以内にメインネット上の7702委任の97%以上がほぼ同一の「コインスイーパー」コントラクトを指していることを発見した。ある研究では約366万件の承認トランザクションを集計し、そのうち約63%が悪意あるコントラクトに関連し、確認された損失は230万ドルだった。Blockaidは2026年上半期に4件の7702インシデントを検証し、合計約108万ドルに達し、年内に初の7桁規模の案件が発生すると予測していた。
結果として起きたのは10桁規模であり、彼らの見積もりより3桁大きかった。
これにより、多くの人が今回のBinanceの56億ドルという人類史上最大のハッキング事件の原因をEIP-7702に帰すことになる。しかし、本当に7702の問題なのだろうか?
先に進む前に、はっきりさせておくべきことがある。50件の承認があれば50個の署名がある。その50個の署名は一体どのように生成されたのか?
もし攻撃者が完全な秘密鍵を手に入れたのなら、なぜ50個のnonceを盲撃ちする必要があるのか?鍵がずっとBinanceの手元にあったのなら、12分間に11個のウォレットがなぜ同時に陥落したのか?現時点では説明がない。
メインの掃討から24秒後、Binance 16は28,005.6 ETH、5,570万USDT、2,590万RLUSD、84.5 WBTCを送金し、送金先は同一の受取アドレスだった。
12分以内に、さらに10個のBinanceホットウォレットが4つのチェーン上で同じことを行った。Optimism上のBinance 55は4,420万OPを送金し、Arbitrum上の4つのウォレットは7,460万ARBと8,426 ETHを送金し、Avalanche上の4つのウォレットは181万AVAXと841万USDTを送金した。
これらのウォレットにはいずれもコードがなく、すべての取引は通常の送金であり、ウォレット自身の秘密鍵によって署名され、日常的な出金の合間に紛れ込んでいた。
秘密鍵を手にしている者なら、nonceを盲撃ちする必要はない。eth_getTransactionCountを確認すれば、1秒のことだ。
50件を一度に構築し、連続する50個のnonceをカバーする必要があるのは、別の種類の人間だ。署名は取得できるが、このウォレットのリアルタイム状態は取得できない者、あるいは事前に組み立てた承認の束を一度にまとめて提出し、システムに試行させることしかできない者である。
さらに注目すべきは、この50件の承認が同一トランザクション内で一括して審査を通過したことだ。
セキュリティ企業Blockaidの判断は「鍵の悪用」であり、秘密鍵が直接抽出されたわけではないというものだ。Yuga Labsのブロックチェーン担当副社長Quitもこの方向性に傾いている。攻撃者が手にしたのは「承認された署名」であり秘密鍵ではなく、リレーヤーを使って提出したのは署名の出所を隠すためだった可能性がある。
神魚は朝の振り返りで一つの詳細に触れている。06:55になっても、バイナンスは同じ秘密鍵で署名し、スイープされなかった断片トークンを自分のウォレットに戻していた。
これは、この鍵が当日の朝まだバイナンスの管理下にあったことを示している。
つい先ほど10:26、バイナンスは初步的な見解を示した。あるDevOpsエンジニアのノートPCが侵害され、攻撃者がそれを足がかりにサービスコンテナに侵入し、未承認の出金トランザクションを提出した可能性がある。現時点でウォレットの秘密鍵が漏洩した証拠は見つかっていないという。
つまり核心はEIP-7702になく、署名の前の段階にある。
ホットウォレットは1日に数千件の署名を行うため、自動化が必須だ。安全でなければならないため、HSM、MPC、マルチシグ、承認フローが必要になる。こうしてセキュリティモデル全体は一言に集約される。「このフローは、署名の前に『この一件は署名すべきでない』と判断できるか」。
問題は、判断材料の大部分が金額とアドレスの二欄しかないことだ。
7702の承認にはこの二欄すらない。金額がない。それは「いくら送るか」を変えるのではなく、「このアドレスは何か」を変えるものだ。
バイナンスは防いでいなかったわけではない。
事発の3日前、つまり10月27日、記録に値することを自ら開示した。過去1週間、セキュリティチームは北朝鮮関連の攻撃を複数阻止した。手口はContagious Interviewと呼ばれるもので、相手は採用担当者を装い、面接やコードテスト、「まず開発ツールをインストールして」と言って人を騙して悪意あるプログラムを実行させる。プログラムが一度動き出せば、鍵、内部ネットワーク、その後の資金移動の入口がすべて手に入る。
しかし「この一件は、署名すべきか」は防げなかった。
BlockBeats の公式コミュニティに参加しよう:
Telegram 公式チャンネル:https://t.me/theblockbeats
Telegram 交流グループ:https://t.me/BlockBeats_App
Twitter 公式アカウント:https://twitter.com/BlockBeatsAsia