Binanceが公表した初期報告書からは、同社のセキュリティポリシー、統制、従業員向けの啓発トレーニング、そして社内AIツールの管理体制をめぐる数多くの疑問が浮かび上がります。CISOにとって重要な教訓です。
回避可能だった技術面・人為面のセキュリティ上の不備が連鎖し、史上最大の暗号資産(仮想通貨)窃盗事件、つまりBinanceからの約63億4,000万ドルの盗難を招きました。社内AIツールの監視とアクセス権限の範囲設定が不適切だったことが、攻撃者を大いに助ける結果となりました。企業のCISOは、これを警告と受け止め、AIガバナンスに真剣に取り組む必要があります。
11月3日に公表されたBinanceの初期調査報告書によると、同社のウォレット基盤を担当するエンジニアを標的に、数カ月にわたる多段階の攻撃が展開されました。開発者のマシンにマルウェアが仕込まれた事案は2件あり、検知できたのはそのうち1件だけでした。攻撃者はその後、社内AIツールを足がかりに別の開発者のシステムへ移動し、アクセストークンを入手しました。さらにBinanceのインフラ上にコンテナをデプロイし、不正な出金を実行しました。
Binanceはこの攻撃を極めて高度なものだと説明しています。しかし実際には、脆弱または存在しないアクセス制御、過剰な権限、認証情報管理の不備、従業員のセキュリティ意識の欠如やポリシー違反など、回避できたはずの不備が複数ありました。
セキュリティ企業CobaltのオフェンシブセキュリティリサーチおよびコミュニティディレクターであるJoe Brinkley氏は、次のように警告します。「開発者のワークステーションは、いつの間にか企業内で最も強い権限を持つ資産の一つになっています。デプロイ用トークンや署名権限に加え、今では従業員に代わって社内システム全体を操作できるAIツールまで抱えています。攻撃者がそのマシンを掌握すれば、広範な社内アクセス権を持つAIツールも、攻撃者が使える信頼された経路の一つになってしまいます」
同氏はさらにこう続けます。「セキュリティチームは、本番環境や署名へのアクセス権を持つエンジニアを価値の高い攻撃対象領域として扱うべきです。ワークステーションから本番環境までの経路を攻撃者の視点でテストし、AIツールの権限もサービスアカウントと同じ厳しさで絞り込む必要があります」
数カ月を隔てた2度の侵害
FBIはBinanceへの侵害を北朝鮮の犯行と断定し、ハッキング部隊をTraderTraitorと特定しました。他の研究者は、このグループを、過去10年間で暗号資産プラットフォームから数十億ドルを盗み出してきたより大きなLazarusの作戦の一部とみています。Binance自身の報告書もFBIの結論を引用しており、2026年を通じて、同社のセキュリティチームが北朝鮮関連とみられるサイバー脅威57件を検知し、阻止したことにも触れています。
このことは、BinanceがLazarus APTを脅威モデルに組み込み、そのツール、手法、手順(TTP)を十分に把握していたことを示唆します。それは当然の備えです。TTPには、ソフトウェアサプライチェーンの侵害、正規の人気ツールを装うマルウェアの利用、偽の採用面接で開発者をだます手口、長期にわたるソーシャルエンジニアリング工作などが含まれます。それにもかかわらず、Binanceのエンジニア2人がまさにこうした手口に引っかかりました。同社のセキュリティ意識向上トレーニングと技術的な統制の双方に疑問が生じます。
6月、ウォレット基盤を担当するエンジニアの1人が、人気のAIコーディングツールをウェブで検索し、信頼できる入手元からではなく、改ざんされたHomebrewのインストーラーをダウンロードしました。Homebrewは、macOS向けオープンソースアプリケーションのパッケージマネージャー兼配布チャネルです。Binanceのセキュリティチームは異常を検知し、端末を交換して関連する認証情報をすべてローテーションしました。しかしその時点で、攻撃者はこのエンジニアが誰であるか、ウォレット基盤チームに他にどんな人物がいるかを突き止めていました。
Binanceが侵害を素早く検知できたのは評価できます。ただ、そもそもなぜエンジニアが検索結果から入手したソフトウェアをインストールできたのか、という疑問が残ります。Binanceには、従業員は承認された入手元からのみソフトウェアをインストールするというポリシーがあるのでしょうか。あるとして、アプリケーションのホワイトリスト化のような技術的統制で強制していたのでしょうか。
3カ月後、攻撃者は求人プラットフォームを通じて2人目のエンジニアに接触しました。実在しない企業の採用担当のプロジェクトディレクターを装っていました。続いて2段階の面接が行われました。1回目は人事担当を名乗る人物との面接で、信頼を得るために、個人の写真や動画であふれたソーシャルメディアのアカウントが共有されました。2回目は同社のCEOを名乗る人物との面接でした。
2回目の面接の終わりに、エンジニアはリポジトリからコーディング課題を業務用PCにダウンロードするよう指示されました。この課題には悪意のあるコードが含まれていましたが、今回はBinanceのエンドポイント保護ツールが検知できませんでした。同社はこれをゼロデイマルウェアと説明しています。しかし、エンドポイント保護ツールが既知のマルウェアしか検知できないのだとすれば、業界全体の問題です。
いずれにせよ、この開発者の行動は、Binanceのセキュリティポリシー、手順、意識に関する数々の疑問を投げかけます。最大の疑問は、なぜこのエンジニアが業務用PCで採用面接や課題に取り組んでいたのか、という点です。仮想マシンを使わず、なぜシステム上に直接リポジトリをクローンしたのでしょうか。これが日常的な行為であれば、セキュリティトレーニングの不備か、意図的なポリシー違反を示しています。企業は、従業員が常にポリシーを守ることだけに頼るわけにはいきません。検知と強制の仕組みが必要です。
ヒューマンリスク管理企業Fable Securityのサイバーセキュリティ担当AVP、Tim Chase氏は「このエンジニアは複数の誤りを犯しました。現代的なリスク管理プログラムであれば、攻撃者が今日使っているソーシャルエンジニアリングの最新の[攻撃]領域を、彼に理解させておくべきでした」と指摘します。
CSOは、業務用PCでの開発者の行動を明確に禁じるポリシーがあったか、また従業員トレーニングが北朝鮮のハッカーがよく使う偽の採用を装ったソーシャルエンジニアリングの手口を扱っていたかを、Binanceに質問しました。しかし回答は得られませんでした。
攻撃者は、エンジニアのPC上でマルウェアを動かせるようになると、そのPCに入っていた社内AIツールを使って、ウォレット基盤チームの他の2人のエンジニアのマシンへ移動しました。
Binanceは、このツールの用途を報告書でもCSOへの回答でも明らかにしていません。ただ、侵害された1人のユーザーが、このツールを使って別のコンピューターにアクセスできたという事実は、権限が広すぎたか、適切なアクセス制御が欠けていたことを示唆しています。同社が公表した是正措置の一覧にも、その兆候があります。そこには「影響を受けた社内AIツールとアクセス制御を再構築した」とあります。
攻撃者は、追加で侵害したエンジニアのPCの1台で、同社インフラに新しいコンテナをデプロイする権限を持つトークンを発見しました。9日後、攻撃者は別の侵害済みエンジニアPCでこのトークンを使い、悪意のあるスクリプトを含むコンテナをデプロイしました。このスクリプトがウォレットの署名サービスとやり取りし、出金を開始しました。
Binanceの報告書には追加のチェックに関する記述がないため、この一連の経緯は認証情報管理とアクセス制御についてさらなる疑問を生みます。なぜトークンは単一の操作に限定された一時的なものではなく、長期間有効だったのでしょうか。本番環境へのコンテナのデプロイには、追加の検証や承認の手順があったのでしょうか。デプロイされたコンテナと署名サービスの間に認証はあったのでしょうか。それとも、同じ信頼されたネットワーク上にあるだけで十分だったのでしょうか。これらの点についても、BinanceはCSOの質問に回答しませんでした。
Strike GraphのCEO、Justin Beals氏は「エンジニアのシステムにアクセスできる社内AIツールは、特権を持つ従業員と同種のアクセス権を持っています。それなのに、ほとんどの組織はそのように管理していません」と語ります。「署名鍵、デプロイ用トークン、本番環境へのアクセス権を持つ人物を狙って、この手口を真似するグループが今後増えるでしょう。セキュリティリーダーは、本番環境にアクセスできるエンジニアと、そのエンジニアが使うAIツールを特権IDとして扱うべきです。具体的には、業務用マシンにインストールできるものを制限し、デプロイ用トークンの有効期限を短くし、社内AIツールが実際に何をしているかを記録して確認することです」
AIエージェントのセキュリティに特化したスタートアップNeoの共同創業者、Shlomi Salem氏は、Binanceが調査結果を公表する数日前に、このAIを使った攻撃経路を予測していました。侵害の公表を受けた10月30日に、同氏は「調査の結果、この連鎖の出発点に汚染されたパッケージか、悪用されたエージェント、あるいはその両方が見つかっても驚きません」と述べています。
Cloud Rangeのプロダクトマネジメントディレクター、Bri Frost氏はCSOに対し、組織にとっての教訓は、社内AIツールがすでに攻撃対象領域の一部になっており、それに見合ったテストが必要だという点だと語っています。
同氏は「AIツールが従業員に代わって他のシステムにアクセスできる場合、その従業員のマシンを支配した攻撃者は、ツールにできることをすべて引き継ぐ可能性があります」と述べ、こう続けます。「そのため、セキュリティチームが答えるべき問いも変わります。モデルが適切な回答を返すかどうかだけでなく、侵害されたセッションから要求が来たときに、そのツールが何をするのか、誰のために動くのかが問われます」
