Binanceハッキング2026：出金再開・準備金証明・原因

Binanceから再び出金できるのか

Binanceは11月5日04:00 UTCから、追加の出金を段階的に再開すると発表しました。すべてが同時に利用可能という意味ではなく、各トークンとネットワークの状態を公式の経路で確認する必要があります。

Binanceは11月4日、会社の資源で影響額の約98％を補填したと報告しました。盗難資産の返還率ではありません。

Binanceによると、11月4日00:00 UTCの準備金スナップショットは44種類のトークンを対象とします。完全な暗号学的証明は発表時に生成中でした。スナップショットは完全な財務監査でも攻撃原因の証明でもありません。 [28] [29] [17]

凍結と返還は別です。

以前公表された25億4,000万米ドルは途中経過でした。Binanceは現在、約30億米ドルが凍結されたとしています。凍結は一部トークンの追加移動を制限しますが、Binanceや利用者にすでに返還されたことを意味しません。

影響総額の約63億米ドルという推計も、最終的な純損失ではありません。調査中の数字であり、それぞれ測っている対象が異なります。63億から30億米ドルを引いても、確定した補填不足や最終損失は算出できません。 [11] [14] [15]

一台のPCだけでは説明できない複数の侵害箇所

Binanceの最初の暫定説明は、DevOps担当者のPC侵害とサービスコンテナへのアクセスでした。その後の説明では、追加の侵害箇所が示されています。Richard Tengは一台の機器や一人の担当者の権限だけの問題ではなかったとしています。最初の手がかりは、まだ原因の全体像ではありません。

Tengによると、EIP-7702の委任は通常の承認統制を通っていませんでした。どの経路が、本来確認されるべき承認を可能にしたのでしょうか。声明だけでは、全ログ、関係するID、技術的な迂回経路は明らかになっていません。特定のフィッシング手法やコンテナエスケープが証明されたわけでもありません。

Ethereum上で観測された委任と、運用基盤へのアクセスは異なる層の話です。チェーンは処理された承認や取引を示し、運用調査はそれ以前のアクセスを説明する必要があります。EIP-7702はコード委任の仕組みであり、マルチシグの規則ではありません。インタビューの簡略な表現を、そのまま規格の定義にはできません。 [5] [14] [22] [23]

利用者と企業ができること。

普段利用しているBinanceアプリ、または自分で入力した公式アドレスから最新状況を確認してください。突然届く補償・解除リンクを信用せず、パスワード、ワンタイムコード、復元フレーズを渡さないでください。企業は外部サービスの担当者、承認手順、緊急連絡方法を確認し、公式経路で残高と取引を記録できます。未確認情報を理由に取引を急がないことも大切です。 [6]

PCの侵害が秘密鍵の盗難を自動的に意味しない理由

無許可の取引を起こすために、攻撃者が必ず秘密鍵をファイルとして持ち出す必要があるとは限りません。署名サービスを使う基盤では、どの要求が保護された署名処理に届くかが重要になる場合があります。その経路の悪用によって、業務上承認されていない操作に有効な署名が付く可能性があります。これは一般的な技術分析であり、Binanceで新たに確認された事実ではありません。

Binanceは現在、ウォレット秘密鍵の漏えいを示す証拠はないとしています。そのため、ID、コンテナアクセス、承認ルールの調査が重要です。ただし、最初の会社説明は、全体の再構成や独立検証に代わるものではありません。原因、資産の照合、補填は、それぞれ別の証拠で確認する必要があります。 [5] [14] [16]

EIP-7702：認可によって何が可能になるのか

EIP-7702は、アカウントがコードの実行をスマートコントラクトに委任できるEthereumの機能です。委任には当該アカウントの有効な認可が必要です。第三者がその認可を適切な取引に含めて手数料を支払うことができ、外側の取引を委任元から送る必要はありません。

認可が受理されると、アカウントは選択されたコードを参照します。その後の呼び出しで、コードはそのアカウントのコンテキストで実行され、資産に影響を及ぼし得ます。委任は新たな有効な認可で変更または解除されるまで残ります。EIP-7702は機能であり、この事案の原因となった規格の脆弱性は確認されていません。

コードは同じ取引の実行段階で呼び出される場合もあり、後続の呼び出しは必須ではありません。暗号学的に有効な認可でも、組織がその操作を業務上意図した証拠にはなりません。 後続の実行段階がrevertで失敗しても、すでに設定された委任はその失敗と一緒には巻き戻されません。 [5]

初期のブロックチェーン分析で分かったこと

セキュリティ企業Blockaidは、Binance 14と表示されたアドレスに対する50件のEIP-7702認可を含む取引を報告しています。そのうち1件が受理され、アカウントがコントラクトに委任されたとの分析です。認可のnonceは、その時点のアカウントのカウンターと一致する必要があります。これは外部の暫定分析であり、Binanceの最終調査報告ではありません。

808bitsの独立分析は、委任を10月29日20:20:59 UTC、トークンとイーサの移動を伴う後続の呼び出しを20:24:23 UTCとしています。これは調査対象のEthereum取引の時刻であり、全ネットワークや確定した総損失を示すものではありません。有効な認可から、その署名がどう作られたかは分かりません。鍵の流出、署名手順の悪用、その他のアクセス経路は、この観測だけでは確定できません。

出典：808bits、drk.vc。時刻は個別の分析対象取引を示し、確定した総損失を示すものではありません。 [4] [7] [8]

表は左右にスクロールできます。

組織が署名プロセスで確認できること

資産管理やウォレット基盤を運用する組織にとって、重要なのは署名が実際に何を認可するかです。署名・承認システムでは、要求の種類、ネットワークID、委任先コントラクト、nonceを明確に表示し、文書化された方針に照らして確認します。可能な場合、内容不明のハッシュへの盲目的な承認や不要な委任を防ぎます。

許可する委任先の制限、変更や異常な認可の連続に対する通知、重要な変更の独立した確認も検討できます。担当者を決め、停止・復旧を訓練し、署名やシステムのログを保全することも調査に役立ちます。今回のBinance事案をどの対策が防げたかは、まだ確認されていません。

これらの対策はCyberkernの技術的な考察です。方針は署名前に実際の署名対象を確認する必要があり、ハッシュだけを承認すると目的が見えない場合があります。実行後のオンチェーン通知では、その取引を防げません。許可済みの委任先アドレスだけではコードの安全性を保証できません。 [5] [9]

50件の承認とnonceから分かること

50という数字は、まず承認リストの項目数です。被害を受けた顧客数でも、50個の鍵が盗まれた証拠でもありません。Ethereumは各項目の署名、ネットワーク識別子、アカウントのnonceなどを確認します。条件を満たさない項目は飛ばされ、残りの処理が続きます。

nonceはアカウントのカウンターです。取引の多いウォレットでは、処理の進行に伴って素早く変わります。異なる値の承認を用意すると、変動する範囲をカバーできます。外部分析では、調査対象のBinanceトランザクションで一つの承認が受理されたとされています。これは当該事例の分析結果であり、プロトコル上の上限ではありません。複数の有効な項目を含むことは可能で、受理のたびにカウンターが増えます。 [5] [7] [12]

署名を保護していても、どこで問題が起き得るのか

最初のDevOpsの手がかりだけでは全体を説明できません。Richard Tengは追加の侵害箇所を示し、委任が通常の承認統制を通っていなかったとしています。見直しの対象は端末、クラウド、鍵管理、署名です。運用者には機器の保護に加え、重要な承認経路すべてを証拠で確認することが求められます。

運用者には、次の三つの確認事項があります。これはCyberkernの技術分析であり、暫定声明だけから、特定の統制なら確実に事件を防げたとは判断できません。

確かな再構成では、アクセスログ、コンテナの活動、出金要求、承認、実際の署名を対応づけます。チェーン上では、報告された取り消しと過去の状態を区別する必要があります。アカウントやセッションへの対応だけで、以前のオンチェーン委任が消えたと一般に証明できるわけではありません。 [5] [12] [14] [22] [23]

• IDと要求：侵害された端末から、どのIDで重要な要求を送れたのでしょうか。表示された操作と実際の署名内容は独立して比較されていたでしょうか。
• コンテナの権限：どのサービスや出金機能にアクセスできたのでしょうか。権限、サービスアクセス、例外経路は必要な範囲に制限されていたでしょうか。
• 封じ込めと証拠：端末やサービスのアクセス遮断、承認の取り消し、その後のログやチェーン状態の検証は、いつ行われたのでしょうか。

ハードウェアウォレットやコールドウォレットなら防げたのか

鍵をオフラインで保管し、適切なハードウェアを使うことは、鍵の盗難にさらされる範囲を大きく減らせます。重要な防御です。ただし、操作内容の確認とは別の問題です。誤った委任や宛先を承認すれば、十分保護された鍵でも危険な要求に署名する可能性があります。

取引所には運用資金と頻繁な出金処理も必要です。そのため、ホットウォレット残高の制限、職務の分離、重要な署名に対する明確で強制力のあるルールも欠かせません。今回確認した資料では、対象システムでBinanceが用いたハードウェア、鍵の分散、オフライン保管の全体像は判明していません。この事件から、ハードウェアウォレットが無意味だとも、特定製品なら確実に防げたとも結論づけられません。 [5] [13]

利用者の三つの疑問と、調査報告に必要な証拠

自分のウォレットも侵害されたのでしょうか。Binanceの事件は、独立して管理する個人ウォレットへのアクセスを証明しません。取引所の残高と自己管理する鍵は別の状況です。使い慣れた公式アプリか、自分で入力した公式アドレスで口座の状態を確認してください。一般的な報道だけで個別残高は判断できません。

補償の受け取りやウォレット修復を承認すべきでしょうか。いいえ。取引所の事件を理由に、未知のコントラクトへの承認、リカバリーフレーズの開示、手助けを申し出た相手への支払いをする必要はありません。そうした勧誘が次の被害につながることがあります。実際に影響を受けたウォレットへの技術的変更は、検証済みの復旧計画に基づくべきです。

完全な調査報告には何が必要でしょうか。侵入、署名、資産移動の技術的・時系列的なつながりと、送金、凍結、返還、残存損失を区別した集計です。損失補填の約束は財務上の責任に関する表明であり、原因の証拠や補填完了の証明を代替するものではありません。準備金証明だけでは、完全な財務監査や、原因と内部のセキュリティ統制の調査に代えることはできません。 [5] [6] [13] [14] [17]