Binanceの盗難は採用面接から始まった――被害の規模を決めたのはアクセス権限

9月、Binanceのソフトウェアエンジニアは、実在しない企業との採用面接を2回受けた。1回目は人事担当者とのライブビデオ通話で、相手は実在する人物だと証明するため、写真や動画を含む個人のソーシャルメディアアカウントを共有した。2回目はチャットアプリ上で行われ、CEOを名乗る人物が応対した。終盤、エンジニアは業務用コンピューターにコーディング課題をダウンロードするよう求められた。

10月29日、攻撃者はBinanceのウォレットから約63億4,000万ドルを移動させ、その大半は約20分以内に移された。FBIは、この盗難をTraderTraitorによるものとし、この北朝鮮のグループは、2025年2月のBybitからの15億ドルの盗難についても非難されている。これは、記録上最大の暗号資産盗難だ。

Binanceは責任を認め、損失を補填すると述べている。11月3日時点で、被害を受けたトークン資産の98％が補充され、約28億5,000万ドルが凍結または差し押さえられたと発表した。

問うべきなのは、侵害されたノートパソコンから何にアクセスできたのか、そして各チームが今日、自らの環境でそれを検証できるのか、ということだ。

2つの侵入口と、6月から10月にわたる攻撃活動

Binanceが11月3日に発表した更新情報には、ディープフェイクやその他のAIを利用した手法を示すものはない。いずれの侵入も人を介したものだった。検索結果を信頼したエンジニアと、採用担当者を信頼した別のエンジニアだ。

この攻撃活動は少なくとも5か月にわたった。6月、AIコーディングツールを探していたウォレット担当のDevOpsエンジニアが、改ざんされたHomebrewインストーラーをダウンロードした。Binanceのセキュリティチームは異常を検知し、端末を交換して認証情報を更新した。しかしその時点で、攻撃者はすでにウォレットインフラチームのメンバーを把握していた。

3か月後、攻撃者は別の経路から再び侵入した。9月に接触を受けたエンジニアは、正規の求人検索プラットフォームにプロフィールを掲載しており、Binanceでの勤務経験を記載していた。コーディング課題には、セットアップ中に実行されるマルウェアが仕込まれていた。正規のpyenvコンポーネントを悪意あるものに置き換え、攻撃者が管理するサーバーに接続し、痕跡を消去するものだった。Binanceによると、エンドポイント保護機能はこれを検知できなかった。

10月20日、攻撃者はそのノートパソコンと社内AIツールを使い、さらに2人のエンジニアの端末を乗っ取った。そのうち1台は、6月に侵害されたDevOpsエンジニアのものだった。その端末から、コンテナのデプロイ権限を持つトークンが見つかった。10月29日、攻撃者はもう1人のエンジニアのコンピューターにログインし、盗んだ認証情報を使ってコンテナをデプロイし、盗難を実行するスクリプトを起動した。

採用担当者を装う手口が今も通用する理由

偽の採用担当者や、悪意あるコードを仕込んだコーディングテストは、昔から使われてきた手口だ。北朝鮮の工作員は何年にもわたり開発者を標的にこの手口を使ってきた。なかでも、「コンテイジャス・インタビュー」として知られるキャンペーンがよく知られている。Binanceによると、2026年だけで北朝鮮と関連があると疑われる攻撃の試みを57件阻止した。

この手口が有効なのは、エンジニアが日常的に行っていることを求めるからだ。技術職の面接で見慣れないリポジトリを実行するのは、ごく一般的なことだ。不審な送信元アドレスも、クリック前に確認できるリンクもない。もっともらしい雇用主、ビデオ通話に映る人物、そして仕事のように見える課題があるだけだ。

採用担当者からのメッセージは、見知らぬ相手からの連絡でも歓迎される数少ないものの一つだ。どれほど啓発を徹底しても、すべてのエンジニアが巧妙な誘いを毎回見抜けるとは限らない。そのため、対策は侵入を許す場合があることを前提にしなければならない。

1台のノートパソコンからウォレットに至った経路

まず気になるのは、そのエンジニアの環境におけるセキュリティ対策だ。社外のコーディング課題に業務用コンピューターを使うことには、検証が必要だ。さらに大きな懸念は、たった1台の端末が侵害されたことで、どうして他のシステムへのアクセスが可能になり、最終的に機密性の高い金融インフラにまで及んだのかという点だ。

最初の感染以降の各段階は、Binance内部にすでに存在していた信頼関係に依存していた。社内AIツールは侵害された端末からの指示を受け入れ、それを同僚の端末にまで及ぼした。デプロイ用トークンはエンジニアのノートパソコンに置かれていた。有効な認証情報を使ったコンテナのデプロイによって、数十億ドルが動かされた。これらのどの段階にも、別の誘いを仕掛ける必要はなかった。

社内AIツールには特に注意が必要だ。リポジトリ、エンドポイント、サービスに対して広範な権限で動作することが多く、ツールに指示できる端末を掌握した者は、その権限の及ぶ範囲も手にすることになる。

開発を停滞させずに開発者を守る

開発者には、パッケージのダウンロード、見慣れないコードの実行、ソフトウェアのテストが必要だ。ノートパソコンを金融部門のワークステーション並みに厳しく制限すれば、開発の速度は大幅に落ち、エンジニアは回避策に走るだろう。求人活動を社用端末で行わないという方針は妥当だが、誰もが常に方針に従うとは限らない。現実的な目標は、開発者の端末が侵害された後に何を実行できるかを制限することだ。

いくつかの対策が、最も大きな違いを生む。信頼できないコードは、企業の認証情報にアクセスできない使い捨ての仮想マシン上で実行すべきだ。デプロイ用の認証情報は有効期間を短くし、権限の範囲を限定したうえで、可能な限り、管理されたデプロイのワークフローに対して発行すべきである。ウォレットの署名鍵や鍵の分割片は、開発者のワークステーションとは別に保護し、承認できる取引や認可を制限する署名ポリシーを設けるべきだ。ウォレット、決済、本番システムに関わる操作には、別の端末を使う2人目の担当者による承認を必須とすべきである。社内のAIツールは、最小限の権限で実行し、その動作を記録すべきだ。

認証情報が正規のものである場合にも、検知が機能しなければならない。予期しない端末や時間帯からのデプロイに警告を出す振る舞い監視があれば、すべての認証情報が正しく見える状況でも、チームが介入する機会を得られる。Binanceによると、同社はこの種の検知を事件以降、拡充してきた。

脅威インテリジェンスが果たす役割

盗難の6週間前には、すでに警告が公表されていた。「Contagious Interview」に関する共同勧告では、AI、暗号資産、NFT関連企業の採用担当者を装う攻撃者が、IT専門家を標的にして暗号資産を盗む手口が説明されていた。Binanceの事例も、同じ手口に沿ったものだった。

このような攻撃活動において、脅威インテリジェンスには具体的な役割がある。攻撃者が入れ替わることはあっても、その戦術は知られている。攻撃者を追跡するチームは、既知のインフラを遮断し、現在使われている口実についてエンジニアに警告できる。

インテリジェンスは、誰を重点的に保護すべきかをチームに知らせる役割も果たす。Binanceで6月に起きた侵害のように、ある事件によって機密性の高いアクセス権を持つ人物が明らかになった場合、その人たちは数カ月にわたり標的となる可能性が高いとみなし、使用端末や受ける接触について監視を強化すべきだ。

暗号資産業界以外にも当てはまること

盗まれた資金は素早く移動し、取り戻すのが難しいため、暗号資産取引所が明白な標的となる。しかし、この手口は、銀行の決済処理基盤であれ、ソフトウェアベンダーのビルドおよびリリースプロセスであれ、開発者のワークステーションから数段階で重要システムに到達できる環境なら、どこでも通用する。採用担当者を装う手口は、そうした組織のエンジニアにも及ぶ。

今週、自社の環境を見直すセキュリティ責任者にとって、最も重要な確認事項は2つある。第一に、侵害された開発者用ノートパソコン1台から、現時点で何にアクセスできるかを洗い出すことだ。保存されたトークン、SSH鍵、クラウド認証情報、社内AIツールも対象に含める。第二に、本番環境へのデプロイや高額の取引には、侵害された単一のIDでは得られない、独立した承認が必要であることを確認する。

Binanceは影響を受けたシステムを再構築し、独立した審査担当者を招いたが、こうした判断は損失が発生した後に下された。同じ演習を今実施する組織は、自分たちの都合に合わせて判断を下せる。