攻撃者がAIエージェント化、6時間未満で数千認証情報

Google Threat Intelligence Group（GTIG）は2026年9月8日、侵害済みのクラウド環境に展開された自律型マルチエージェント基盤が、6時間未満で数千件の第三者認証情報を侵害した2026年第2四半期の事例を公表した。GTIGの公式報告 は、基盤が脆弱性スキャンの管理、リアルタイムの障害対応、IPローテーションを手作業なしで実行したとしている。

同じ事例を9月8日に扱った The Hacker Newsの報道 によれば、攻撃者はAIコーディング用チャットボット、プロンプト、エージェント指示、事前設定したMarkdown形式の手順を組み合わせた。確認されたのは、AIが侵入から目的達成までを独力で完結した攻撃ではなく、侵害後のスキャン、再試行、認証情報収集を高速で連結した運用である。

クラウド侵害後、6時間未満で攻撃基盤を構築

起点は、名称が公表されていない組織のクラウド基盤への侵入だった。その足場で攻撃者がマルチエージェント基盤を計画、構築、実行し、大規模な認証情報収集キャンペーンを6時間未満で進めた。侵入経路、悪用された脆弱性、クラウド事業者、正確な開始時刻は明らかになっていない。

したがって「6時間未満」は、あらゆるクラウド侵害に共通する所要時間でも、AIモデル単体の性能値でもない。侵害した環境を確保した攻撃者が、AIコーディング用チャットボットと運用手順を使って攻撃基盤を組み上げ、スキャンと収集を実行した一事例の時間幅だ。

Markdownファイルは、複数のエージェントが従う運用プレイブックとして使われた。収集対象は被害組織内の従業員アカウントに限らず、「第三者の認証情報」と説明されている。ただし、APIキー、パスワード、セッショントークンなどの内訳や、実際に悪用された件数は公表されていない。

自律化したのは失敗を処理する運用ループ

今回の変化は、生成AIが攻撃コードを一度出力したことではない。スキャンを管理し、実行中の問題に対応し、送信元IPを切り替えながら処理を継続する運用ループが自律化された点にある。人間が失敗のたびに状況を確認して次の命令を入力する待ち時間が短くなった。

SiliconANGLEの同日報道 も、障害対応とIPローテーションがオペレーターなしで進み、攻撃通信が被害者のクラウド環境に属する正規IPアドレスから送られたと伝えている。固定された悪性IPだけを遮断する防御では、送信元が切り替わる一連の活動を分断して捉えるおそれがある。

一方、現実の標的に対し、偵察、初期侵入、侵害後活動をすべて自律的に完結する攻撃パイプラインまで確認されたわけではない。人間は標的や目的を決め、最初のクラウド侵害にも関与した可能性がある。見出しの「AIエージェント化」が示す範囲は、観測された侵害後の複数工程と、その間の動的な判断である。

最初の6時間で結ぶべき四つの記録

防御側が探すべきなのは、「AI攻撃」という単独のシグネチャーではない。公表された工程に対応させると、クラウド監査、ワークロード、外向き通信、認証という四つの記録を同じ時間軸と実行主体で結ぶ必要がある。

1. クラウド監査ログ：新しいインスタンスやコンテナ、サービスアカウント、アクセスキー、ネットワーク設定、IP割り当ての変更を確認する。通常の変更時間、実行したID、承認済みの自動化基盤との違いが、攻撃用の足場を見分ける手掛かりになる。
2. ワークロードとプロセスの記録：短時間に繰り返されるスキャン処理、未知の実行環境、指示ファイルの配置、失敗直後に引数や対象を変えた再実行を関連付ける。単独のプロセス名より、親子関係、実行頻度、作成したクラウド主体を追う。
3. 外向き通信：一つのワークロードから多数の宛先やポートへの接続が急増していないか、フローログ、DNS、プロキシ、ファイアウォールで照合する。接続失敗後の即時再試行や送信元IPの切り替えも、同じ処理の継続として束ねる。
4. 認証イベント：APIキーやトークンが、通常と異なるサービス、地域、ユーザーエージェント、送信元から短時間に並行利用されていないかを確認する。無効化する際は、元のキーだけでなく、それを使って作られたセッションや派生資格情報も調査対象になる。

遮断点は各工程に置ける。不審な計算資源を停止する、ワークロードの外向き通信を制限する、侵害が疑われるIDを凍結する、資格情報と派生セッションを失効させる、といった操作だ。重要なのは、四種類のアラートを別々の案件として処理せず、同じクラウド主体やワークロードを起点に一つのインシデントへ集約することである。

固定しきい値だけでは連続性を見失う

単一IPからの接続回数や、一つの宛先に対する失敗数だけを見るしきい値監視は、IPローテーションや対象の分散に弱い。今回のような運用では、個々の通信量が基準を下回っていても、同じクラウド資源が短時間に多数の宛先を探索し、失敗後に条件を変えているという連続性が残る。

受信側だけでなく、自社クラウドからの送信も監視対象になる。侵害された環境が第三者を探索する拠点になれば、社内データの持ち出しが見つかる前に、未知の外部宛先への接続増加や新しいIPの割り当てが現れる可能性がある。正規クラウド事業者のアドレスであることは、通信の正当性を保証しない。

認証情報についても、保存場所の監視だけでは収集後の利用を捉えにくい。資格情報の所有者、用途、有効期限、通常の送信元を把握し、利用ログとクラウド変更を同じ時間軸で検索できることが、短い対応時間に直結する。

被害範囲と侵入手段はなお不明

公表されていないのは、被害組織、利用されたAIモデルやチャットボットの名称、初期侵入の方法、認証情報の種類と悪用状況である。攻撃主体も固有のグループ名には結び付けられず、金銭目的とみられるとの評価にとどまる。

同じGTIG報告に登場する「Recon」という別の認証情報管理基盤や、UNC6780によるソフトウェア供給網攻撃を、6時間未満の事例と同じ主体・基盤だとみなす根拠も示されていない。現時点で確認できる到達点は、侵害済みクラウドを足場に、スキャン、障害対応、IPローテーション、認証情報収集を結んだマルチエージェント運用が実地で観測され、数千件の第三者認証情報を侵害するキャンペーンが6時間未満で計画・構築・実行されたことだ。