Unit 42がAI支援型侵入を報告　10時間未満で進んだ攻撃と防御策

Unit 42は、攻撃者が複数のAIエージェントを使い、企業ネットワークへの侵入を10時間未満で進めた事例を公表しました。

公開Webサービスを起点に、ソースコード内の認証情報、シークレット管理基盤、CI/CD、クラウドAI基盤へ連鎖した点が、この事例の焦点です。

ただし、AIだけが攻撃を決めたわけではありません。

人間の攻撃者が目標と重大な判断を担い、実行と再計画をエージェントへ分担させたと報告されています。

確認された侵入の全体像

Unit 42のインシデント調査報告は、9月2日に公開され、9月3日と4日に更新されました。

同社は当初の表現を訂正し、確認された事象はランサムウェア攻撃ではなく「侵入」だったと明記しています。

したがって、暗号化やランサムウェアの展開まで確認されたと受け取るのは正確ではありません。

AIの利用については、交渉時の攻撃者の説明に加え、複数モデルへの並列呼び出し、セッション間で情報を渡す構造化Markdown、専用スクリプトなど、調査側が観測した兆候があります。

一方、モデル名やエージェント基盤は示されておらず、攻撃全体のどこまでを人間が直接操作したかも公表資料だけでは確定できません。

5段階で連鎖した攻撃経路

1. 公開サービスへの侵入：攻撃者は外部公開されたWebサービスから内部へ入り、自動偵察でマイクロサービスを調べました。MITRE ATT&CKでは公開アプリケーションの悪用（T1190）に対応します。
2. 認証情報の収集：エージェント群がコードリポジトリを調べ、ハードコードされたトークンとサービス用パスワードを取得しました。これはファイル内の認証情報（T1552.001）として整理できます。
3. 特権の奪取：取得したトークンを足掛かりにシークレット管理基盤へ入り、管理者資格情報とルート権限を奪いました。
4. 開発経路の悪用：コード管理アプリケーションの独自ワークフローから不正なCI/CD処理を動かし、クラウドのアクセスキーを持ち出しました。Terraformへのバックドア追加は、強制されたブランチ保護によって阻止されています。
5. クラウド基盤の転用：盗んだクラウドキーで被害組織のAIエンドポイントを利用し、侵入後の処理基盤として使いました。クラウド資源の変更はMITRE ATT&CKのT1578にも関連します。

攻撃者は最後に、悪用した問題をまとめた80ページの技術監査報告書を残したとされています。

この情報量は印象的ですが、防御側が注目すべきなのは分量ではなく、個々の弱点を短時間で試し、成功した経路から次の権限へ移れる実行速度です。

防御側が最初の24時間で確認すること

同種の侵入が疑われる場合、機器ごとに順番に対応すると、残った認証情報から別の経路へ移られるおそれがあります。

Unit 42が示す同期的な封じ込めを踏まえ、ID、開発基盤、クラウドを一つの対象として扱います。

• 影響するAPIキー、サービスアカウント、SSH鍵を洗い出し、失効と再発行を同時に進める。
• OAuthセッションを終了し、高権限アカウントのサインイン履歴と権限変更を確認する。
• CI/CDを一時停止し、不審なワークフロー実行、成果物、デプロイ、クラウドキーの参照履歴を保存する。
• クラウドアカウントを隔離し、AIエンドポイントの呼び出し元、利用量、費用の急増を確認する。
• コード内のトークンを削除するだけでなく、流出した可能性のある認証情報をすべてローテーションする。

証拠保全と復旧判断は、平時から決めた連絡先と権限に従って進める必要があります。

NIST SP 800-61 Rev.3も、インシデント対応を検知後だけの作業にせず、組織のリスク管理全体へ組み込む考え方を示しています。

30日以内に設計し直す防御線

認証情報をコードから分離する

リポジトリ全体を対象にシークレットスキャンを行い、コミット前とCIの両方で検出します。

サービスアカウントは用途ごとに分け、有効期限、接続元、操作範囲を絞ると、漏えい時の到達範囲を狭められます。

CI/CDに人間の承認点を残す

本番環境やInfrastructure as Codeの変更には、複数人のレビュー、保護ブランチ、署名済み成果物、環境ごとの短命な認証情報を適用します。

今回、Terraformへの変更を止めたのは、侵入済みの経路だけでは解除できないブランチ保護でした。

開発速度を保ちながら承認と権限を設計する考え方は、関連記事「AI駆動開発を企業システムに定着させる方法」でも解説しています。

AI基盤を本番インフラとして管理する

モデルのエンドポイント、APIキー、MCPゲートウェイ、接続ツールを台帳化し、最小権限、利用上限、診断ログを設定します。

開発者向けの便利な接続先であっても、社内データとクラウド操作へ到達できるなら、本番システムと同じ変更管理が必要です。

高速な反復をログで見つける

Unit 42は、短時間に集中するAPI要求、401と200の急な切り替わり、並列の認証、想定外のIDからのモデル利用を探索例に挙げています。

CISAのログ活用ガイドも、サーバー、ファイアウォール、端末、クラウドのログを有効にし、ログイン失敗や権限昇格などへ警告を設定するよう勧めています。

構造化MarkdownやPythonのキャッシュが見つかっただけで侵害と断定することはできません。

普段の利用量とIDの基準を持ち、認証、コード変更、クラウド操作を時系列で突き合わせて判断します。

実務で持ち帰るべき判断

この事例が示したのは、未知のゼロデイだけを警戒しても高速な侵入は止められないことです。

公開サービス、コード内の秘密、過大な権限、弱い承認手順という既知の弱点がつながると、エージェントは試行と横展開を短時間で繰り返せます。

生成AIの利用を一律に止める対応では、盗まれた認証情報や既存の運用不備は残ります。

公開範囲を減らし、権限を分け、変更には独立した承認を置き、IDを横断してログを追える状態を先に作ることが、今回の侵入経路に対応した防御です。

よくある質問

ランサムウェアの展開は確認されていますか

Unit 42は9月3日の更新で、確認されたのは侵入であり、ランサムウェア攻撃ではないと訂正しました。

暗号化や特定のランサムウェア名を公表資料から補うことはできません。

10時間という数字はすべて実測ですか

Unit 42が報告した侵入の時間軸です。

人間なら約2週間かかるという比較は同社の評価であり、あらゆる組織や攻撃で同じ差が生じるわけではありません。

構造化Markdownがあれば攻撃と判断できますか

判断できません。

正規の開発でも使われるため、異常な認証、権限変更、CI/CD実行、クラウド利用と組み合わせて調べます。

参照した一次情報と公的資料

• Unit 42「An AI-Assisted Cyber Attack: Inside a Unit 42 Investigation」
• MITRE ATT&CK「Exploit Public-Facing Application（T1190）」
• MITRE ATT&CK「Credentials In Files（T1552.001）」
• MITRE ATT&CK「Modify Cloud Compute Infrastructure（T1578）」
• NIST「SP 800-61 Rev.3」
• CISA「Use Logging on Business Systems」
• 株式会社greeden公式サイト