Binance、偽の採用面接を起点に約63億ドル相当の暗号資産が流出

暗号資産交換業者の
この事故の概要
- 公表日
- 2026年11月3日
- 組織
- Binance(金融)
- 原因
- 偽の採用面接の課題に仕込まれたマルウェアから社内へ侵入
- 漏れた情報
- 暗号資産(個人情報については報告に記載なし)
- 発覚
- 2026年10月29日
何が起きたのか
暗号資産交換業者のBinanceは2026年11月3日、10月29日に起きた不正な送金の初期報告を公表しました。影響額は約63億4,000万ドル相当です。同社はFBIの情報として北朝鮮が関与したと伝えており、調査と第三者の検証は続いています。初期報告のため、内容は今後変わる可能性があり、悪用を防ぐために伏せた技術情報もあるとしています。
攻撃は次の段階を踏んでいました。
- 6月:ウォレット担当の技術者(Aさん)がAIコーディングツールを探す中で、改ざんされた開発用パッケージ(Homebrew経由)を入れました。同社は異常を検知して端末を交換し、認証情報も替えましたが、Aさんの役割と同僚の権限の存在は攻撃者に知られました。
- 9月:別の技術者(Bさん)が求人サイトで、プロジェクトディレクターを名乗る人物から連絡を受けました。1回目は人事担当を名乗る人物とのビデオ面接で、相手は信頼させるために、個人の写真や動画が載ったSNSのアカウントを見せました。2回目は架空の会社のCEOを名乗る人物との面接で、よく使われるチャットアプリで行われました。終盤に「課題」として、悪意のあるコードを含むリポジトリを業務用パソコンにダウンロードするよう指示されました。
- 10月20日:攻撃者はBさんのパソコンと社内のAIツールを使い、Aさんと、ウォレット担当のもう1人(Cさん)を制御下に置きました。Aさんの端末には、コンテナ(アプリを動かす箱)を展開できる権限のトークンがありました。
- 10月29日:攻撃者はCさんの端末にログインし、Aさんの権限で社内の署名サービスに入りました。署名サービスは送金に電子署名をつける仕組みで、通常の出金手続きの外から送金を始めるために使われました。
「課題」のコードは、実行すると正規のpyenvの部品を悪意あるものに差し替え、外部のサーバーと通信し、痕跡を消そうとしました。端末のセキュリティ製品は、このマルウェアを検知できませんでした。
漏れた情報
流出したのは暗号資産です。送金は10月29日の協定世界時で20時5分から20時9分に、5つのホットウォレット(ネットワークにつながった保管用の財布)からXRP約2億3,346万枚が攻撃者のアドレスへ出ていったところから始まりました。続いてSolanaとOptimismのホットウォレットから約97万500SOLと約4,420万OP、別のホットウォレットから18,270BTCが送られました。最後の2,961.9ETHは、先に送信を試みた後に未確定の状態で残り、23時56分に確定しました。以降の不正な送金は確認されていません。
約28億5,000万ドル相当は凍結または阻止しました。この額は、照合や相場の変動で変わる可能性があるとされています。
利用者の個人情報が漏れたかどうかは、報告に記載がありません。利用者の資産への影響も、報告は「損失は自社が負う」としているだけで、個別の残高への影響までは述べていません。
会社の対応
同社は、盗まれた資金の損失は利用者ではなく自社が負担するとしています。必要な額の100%を超える分を確保済みで、10月31日時点で、影響した資産の98%を補充しました。残りの流動性が低い資産は購入を進めています。
対応として、影響を受けたウォレットの仕組みを新しい環境に作り直し、社内のAIツールとその権限の管理も作り直しました。関係した技術者の端末を交換して認証情報とトークンを廃止し、全社員の端末を検査しました。攻撃に使われた入口は塞いだとしています。今後は第三者の専門家による見直しも受けます。
初動では、送金が起きたあとの止め方にも難しさがありました。同社は、出金の停止やホットウォレットの停止をしても、ブロックチェーン上に出された権限の委任は自動では無効にならなかったと説明しています。攻撃者は、イーサリアムの仕組みであるEIP-7702(口座の持ち主が、別のプログラムに操作の権限の一部を預ける仕組み)を使い、50件の署名取引を送って、攻撃者のプログラムに権限を預けさせました。同社は、秘密鍵を複数に分けて保管するMPC方式のため、1人の鍵ですぐに取り消すことはできず、専用の手順が必要になって封じ込めに時間がかかったと説明しています。10月30日の午前0時10分(協定世界時)に、権限を空にする手続きを送りました。
日本の会社に関係すること
転職活動を装った接触が、業務用パソコンの中まで届きました。開発を担う社員や委託先の技術者なら、業種を問わず同じ接触を受ける可能性があります。この件から、設定や運用の単位で次の点を確かめられます。
- 採用や外部の協力者から渡された課題、コード、ファイルは、業務用パソコンでは動かさない。確かめたいときは、業務のデータや認証情報がない別の環境で動かします
- 開発者の端末に、本番環境を操作できるトークンや鍵を置かない。置く必要があるものは、有効期限と権限の範囲を短く絞ります
- 社内のAIツールが、どのシステムにどの権限でつながっているかを書き出す。人の権限と同じように、必要のない接続は外します
- セキュリティ製品が見つけてくれる前提にしない。この件では、製品が検知できないままマルウェアが動いたと報告されています
開発用のパッケージも、入手先を確かめてから入れます。6月の件は、AIコーディングツールを探す中で、改ざんされたパッケージを入れたところから始まっています。
自社で確かめること
- 業務端末で社外のコードを動かさない社外の人から渡されたコードやファイルを業務用パソコンで実行しないことを、開発担当者と委託先に確認します。
- 端末に残る強い権限本番環境へ展開できるトークンなどが開発者の端末に置かれたままになっていないか、有効期限と権限の範囲も含めて調べます。
- 社内のAIツールの権限社内で使うAIツールがどのシステムにどの権限でつながっているかを書き出し、不要な接続を外します。



コメント 0
まだコメントはありません。