約63億ドルの流出の足場は、採用面接の「課題」でした。
Binanceが11月3日に公表した初期報告によると、ソフトウェア技術者は偽の面接で課題のリポジトリを落とすよう指示され、その設定の最中にマルウェアが実行されました。10月30日の時点で同社が挙げたのは、運用担当のノートPCが侵害された可能性まででした。経路がここまで語られたのは、これが初めてです。
暗号資産を扱わない会社にも、同じ入口はあります。社員の転職活動を会社は止められませんし、開発者のPCには本番に届くトークンが残っています。
4か月かけて3人の端末を渡った
報告によると、影響額は約63.4億ドルで、約28.5億ドルを凍結または差し止めました。Binanceは、単発の侵入でも単純なフィッシングでもない、段階を踏んだ攻撃だったと説明しています。
Binanceの報告の経路と、一般の会社で止める所作成: 編集部 / 出典: 情シスの相棒編集部（Binanceの初期報告をもとに作成）
いちばん考えさせられるのは6月です。ウォレットの運用担当Aが、人気のAIコーディングツールを入れようと検索し、改ざんされたHomebrewのインストールを落としました。Binanceは異常を検知して端末を交換し、関連の認証情報も入れ替えています。手順としてよくできた対応でしょう。
それでも、Aの担当と周りの同僚の情報は攻撃者に渡りました。端末は替えられても、相手が知ったことは戻りません。
9月の面接も手が込んでいます。正規の求職サービスで、プロジェクトディレクターを名乗る人物が接触してきました。狙われた技術者Bのプロフィールには、Binanceでの経験が載っていたそうです。
1次は人事役との動画面接で、相手は私的な写真や動画を載せたSNSのアカウントを見せ、信用させました。2次はチャットアプリで、架空の会社のCEO役が相手です。その終わり際に、課題のリポジトリを業務PCへ落とすよう指示されました。
Binanceの報告の9月の節。課題を業務PCへ落とすよう指示されたと書かれている出典: Binance「29 October 2026 Binance Security Incident: Initial Findings and Response Update」(引用)
動いたのはセットアップの途中です。課題を解き始める前に、もう動いていたことになります。悪意のあるコードはpyenvを偽物に置き換え、外の指令サーバーとつながりました。端末の保護製品は検知しなかったと、Binanceは説明します。
10月20日には、Bの端末と社内のAIツールを踏み台に、AとCの2人の環境を押さえました。Aの端末には、コンテナを配備できるトークンがありました。AIツールがどう使われたかは、報告にありません。一部の細部は公開しない方針で、外部の調査もこれからです。
「転職活動は禁止」では止まらない
採用の課題を装う手口は、新しくありません。2024年のDMM Bitcoinの件でも、LinkedInで採用担当になりすまし、採用前の試験を装ったPythonのスクリプトを送っていたと警察庁が公表しています（3件の比べ）。
Binance自身も、偽の面接や偽のツールなど、北朝鮮につながるとみられる57件を今年検知して防いだとしています。57回止めても、1回通れば足場ができるわけです。
報告もFBIの発表を引き、北朝鮮の関与としています。Apple製品の管理を手がけるJamfは、この勢力の誘いはほぼ採用の話だと整理しています。
では、社内の決まりをどう書くか。「業務PCで転職活動をしない」と書きたくなりますが、編集部はこの書き方を勧めません。面接は私的なことなので、本人は動かしてしまっても言い出せないからです。いちばん困るのは、この沈黙でしょう。Binanceの技術者が気づいていたかは書かれていませんが、9月の侵入から10月20日の次の段までに、少なくとも20日ありました。
決まりは目的を問わない形にします。採用の課題に限らず、取引先のサンプル、勉強会のリポジトリも同じ扱いです。2024年の警察庁などの注意喚起も、コードを業務用のPCで動かさないか、仮想マシンで動かすことを挙げていました。社内へ流す文面の案です。
件名：社外から受け取ったコードを動かす前に
採用の課題、取引先のサンプル、勉強会のリポジトリなど、
社外から受け取ったコードは、業務PCで実行しないでください。
インストールの途中で動くものもあります。
試すときは、○○の検証環境を使ってください。
もし業務PCで動かしてしまったら、電源は切らずにネットワークから外し、
すぐ情シスへ連絡してください。なぜ受け取ったかは聞きません。
どこから来たコードかと、動かした時刻だけ教えてください。
最後の3行が、この文面の本題です。電源を切らないのも、同じ注意喚起が挙げている対応です。
持ち主と違う端末からの配備が、最後の機会だった
流出の当日、攻撃者はCの端末にログインし、Aの認証情報でコンテナを配備しました。報告の時刻は29日の17時15分から19時56分です。最初の送金は20時5分（UTC）なので、基準が同じなら、操作の終わりから9分後に資金が動き始めました。
ここに、一般の会社でも使える手がかりがあります。Aの認証情報がCの端末から使われるのは、ふだんと違う動きのはずです。トークンが短命で、決まった端末からしか使えなければ、この段で止まった可能性もあります。報告は、端末の管理を厳しくしたことと、振る舞いの異常の検知を広げたことを挙げるだけで、なぜ見逃したかは書いていません。
関係するのは、担当者の端末から本番に届く会社
暗号資産を扱わない会社に、この件の直接の影響はありません。点検が要るのは、自社で開発や運用をしている会社と、委託先の担当者が本番に入れる会社です。開発者がいない会社も、情シスのPCにクラウドの管理者の権限があれば同じです。
次の開発の定例で進める手順
- 社外のコードを動かす場所を決めます。使い捨ての仮想マシンか検証環境を用意し、上の文面を流します。
- AIコーディングツールなど、よく入れられるツールの公式の入手先を社内のページに載せます。6月の入口は、検索して落としたインストーラーでした。
- 本番や配備に届くトークンを、端末から洗い出します。
~/.kube/config、~/.docker/config.json、クラウドのCLIの資格情報が最初の候補です。残すものは有効期間を短くします。社内のAIツールがだれの端末や権限に届くかも見ます。ローカル管理者や緩めたEDRの設定など、開発者だけの例外も今も要るかを見直します。
- 持ち主と違う端末からの利用に、アラートを設定します。材料はIdPのサインインのログ、CI/CDとクラウドの監査ログです。Macの開発者がいれば、
/opt/homebrewの下の実行ファイルがHomebrew以外に書き換えられた記録をEDRで引けるかも試します。
- 止めても残る権限を洗い出します。報告では、出金を止めてもチェーン上の承認が残りました。一般の会社なら、アカウントを止めても残るOAuthの同意、サービスアカウントのキー、CIのトークンが当たります。
- 端末の交換で閉じる事故の手順に、1行足します。その人と同じチームの人に知らせ、監視を強める期間を決めます。
強い操作ができる人とPCの一覧の作り方は、前の記事の確認の手順をご覧ください。社内のAIツールが踏み台になる話は、攻撃者のAI利用を公表したWorkOSとChainalysisの件とは別の問題なので、分けて考えたいところです。
文面の最後の3行を、自社の決まりに書けるでしょうか。定例で最初に聞いてみてください。
