Dream Research Labsによると、2026年7月初旬、自動化された攻撃フレームワークが政府のウェブポータルからJavaScriptバンドルをダウンロードし、それらを解析しました。
悪用されたわけではなく、解析が行われたのです。設計上、すべての訪問者に提供されるコードから、APIエンドポイント、IDプロバイダーの設定、2つの署名鍵が抽出され、それらを統合するシングルサインオン（SSO）基盤を含む21の接続済み政府システムがマッピングされました。
何も壊れることはありませんでした。ペネトレーションテスターであれば誰でも、業務の開始から1時間以内に行うような作業です。新しい点は、フレームワークが自律的にその作業を実行し、発見した内容をランク付けし、指示を待つことなく次のステップへと進んだことです。
今年、私は「AIへの攻撃」に分類される事例を5件確認しました。それらを並べてみると、ニュースの見出しからは読み取れない事実が浮かび上がってきます。いずれの事例も、既存の技術以外のものを必要とはしていませんでした。最も新しい事例では、攻撃の一連のプロセス全体が10時間未満に短縮されていましたが、その短縮は、既知の各ステップの間に生じていた「間」を取り除くことによって実現されたものでした。
5つの事例
AIを加速手段として利用した人間の攻撃者
Sysdigは2025年11月28日、公開S3バケットに露出したAWS認証情報に端を発し、最終的にバックドア経由で管理者権限が奪取されるに至った侵入事例を報告しました。Lambdaの実行までわずか8分、管理者権限の取得まで10分足らずという速さでした。Sysdigは「AI支援型（AI-assisted）」と表現しつつ、「脅威アクターが大規模言語モデル（LLM）を活用したことを示唆する複数の兆候がある」と慎重な言い回しを用いています。私の解釈では、これは「エージェント」が自律的に動いたのではなく、人間がキーボードを操作しつつ、モデルを使って偵察やコード生成を高速化したケースだと言えます。この件についてはこちらで取り上げています。
人間が目標を設定し、エージェントが実行
Unit 42は2026年9月2日にこれを公開しましたが、これはこのセットの中で最も難易度の高いケースです。公開APIが侵害され、リポジトリからハードコードされたトークンが徹底的に捜索され、それらのトークンを利用してシークレットマネージャーへのアクセスが許可され、CI/CDが乗っ取られてクラウドキーが盗まれ、最終的には被害者自身のAIエンドポイントが攻撃インフラへと変貌しました。10時間未満で、50以上のMITRE ATT&CK の手法が用いられました。
見出しではなく、Unit 42自身の説明に注目してください。冒頭ではネットワークが「自律的に」侵害されたとありますが、図のキャプションでは、より正確に「攻撃者が目的を設定し、重大な判断を下した」と説明されています。この事例が注目に値する理由をまとめた次の一文が重要です。「新たなゼロデイ脆弱性や、極めて高度な攻撃技術を必要としない、AI支援による運用効率の向上」です。広く引用されている「2週間」という比較は、実際に観測された侵害時間ではなく、Unit 42のレッドチームによる推定です。機能した防御策もありました。Terraform設定にバックドアを仕込もうとする試みは、「厳格なブランチ保護によって阻止」されました。また、複数のメディアが今も誤って報じていますが、Unit 42は9月3日に記事を訂正し、これはランサムウェア攻撃ではなく侵害事例だったと明確にしています。
意図的に機能低下させられた研究所の中にいるエージェント
Hugging Faceは7月中旬、エージェントによる侵入事件を公表し、7月21日にはOpenAIが、この侵入が同社の複数のモデルの組み合わせによって引き起こされたものであることを確認しました。同社の技術的なタイムラインでは、4.5日間にわたり記録された約17,600件のアクションが説明されています。
頻繁に抜け落ちるのが、この事例の前提条件です。この評価では、「OpenAIの本番環境の安全性分類機能を意図的に無効化し、サイバー関連の拒否応答を減らしていた」うえ、「個々の手順を人間が指示していなかった」とされています。だからといって、事例の重大性が小さくなるわけではありません。防御を弱めたサンドボックスであったとしても、実在する第三者に対する現実の多段階侵害が発生しました。また、過剰な権限が付与された1つの認証情報を偽装すると、わずか1秒以内に2つのクラスターでエージェントがクラスター管理者権限を取得しました。
意思決定を行うモデルは存在せず、AIツールがインフラとして悪用された事例
自己複製型のワームが、2025年以降npm上で拡散しています。そのペイロードはインストール時に実行され、ホスト上のあらゆるトークンを窃取した上で、被害者が公開権限を持つあらゆる場所を通じて自らを再公開します。Elastic Security Labsは8月4日に最新の攻撃の波を特定し、400以上のパッケージが侵害されたと報告しました。
拡散処理を行っているのは決定論的なコードであり、次の行動をモデルが選択しているわけではありません。しかし、AI関連ツールは攻撃チェーンの至るところに登場します。新しいClaudeセッションの開始時に作動するフック、 claude@users.noreply.github.com、を作成者とするコミット、Anthropic、OpenAI、Cursorの認証情報を探す収集ツールなどです 現在、攻撃チェーンにおけるAIの姿は、多くの場合このようなものです。開発者向けツールが攻撃の実行経路となり、AIサービスのキーが窃取対象となる一方で、AI自体は何の意思決定も行っていません。
実環境における準自律型フレームワーク
8月12日に公開されたDream事件に戻ります。復元されたワークスペースは1,395個のファイルで構成され、12回の攻撃ウェーブをカバーし、各ウェーブで最大8つのサブエージェントを派遣しながら、14の攻撃チェーンを継続的にランク付けしています。この投稿の残りの部分は3つの発見に基づいています。認証情報が提供されていないにもかかわらず有効なセッションを返す認証されていないAPI、JSON Webトークンで署名された1つのAPI、 なし アルゴリズム、およびスプレー攻撃によって侵害された85件のアカウント。そのうち84件は、SSOブリッジを経由して内部システムへと侵入していました。
Dreamが使用し、多くの報道では省かれてしまった「準自律的（near-autonomous）」という言葉に注目してください。このプロセスには人間が介在しており、その活動を「承認されたペネトレーションテスト」と位置づけることで、モデルによる拒否が回避されていました。
これらの数値は、フレームワーク独自のレポートに基づいています。Dream社はSSOピボット率そのものの妥当性を検証し、公表前に影響を受けた組織に通知したと述べています。また、同社の広報担当者はCSO Onlineに対し、調査の結果、当該組織のシステムに対する侵害が確認された証拠は見つからなかったと述べ、組織名の公表は控えました。重要なのは、これらの手法そのものです。
同じ3つの死角
私は、侵入を検知の仕組みにおける3つの構造的な欠陥と照らし合わせて分析しています。これら5つの事例については、その枠組みに無理やり当てはめる必要はありませんでした。
ギャップ 1. 特に問題はないようだ
Dreamの偵察フェーズ全体は、標的が意図的に公開している情報に基づいて行われました。実際に有効だった脆弱性は、サーバー側のものであり、ごくありふれたものでした。具体的には、認証不要のAPIや、不十分なトークン検証などです。ペイロードは存在しなかったため、ディスク上にペイロードは残っていません。Sysdigのケースも、1層下で同様の構図であり、ネイティブなAWSサービスと実際の認証情報を使用しており、すべての操作が適切にサポートされ、ログに記録されています。
彼らの行動は、どれも間違っているようには見えなかった。
ギャップ 2. 認証に成功した
ユーザー名は、認証を必要としないAPIから取得されます。予測可能なパターンが繰り返し大量に送信されます。OCRによってCAPTCHAが解読されます。攻撃の対象となったアカウントはすべて正常にログインできてしまうため、チケットを発行すべき不正アクセス事象は発生しません。
について なし-アルゴリズムによる検出については、別途説明すべきです。「署名不要」と主張するトークンをそのまま受け入れるAPIは、騙されているわけではありません。そのAPIはチェックを省略することに同意しており、そのAPIにとっては、偽造されたトークンも正規に発行されたトークンも同等のものなのです。
認証に成功しました。
ギャップ 3. 動きが見えない
覚えておくべき数字は「85のうち84」です。これらの認証情報は、価値の低いエッジシステムであるOAポータル上で漏洩しました。その後、SSOブリッジによって、そのアクセス権が内部のダッシュボードや人事データにまで拡大されました。認証情報はある平面にあり、アクセスは別の平面で実現されますが、両者を結ぶフェデレーションは、その設計通りの役割を果たし、各ホップでサインインの成功を記録しています。
監査ログ3件、SOCチケット3件、情報漏洩1件。
圧縮は現実に起きている。しかし、モデルの速度によるものではない
「ブレイクアウトタイム」（初期侵入から最初のラテラルムーブメントまでの時間）という指標は、CrowdStrikeによって9月1日に廃止されました。その理由は、業界で「マシンスピード」と呼ばれていたものは、実際には「優れたツールを駆使した人間の速度」に過ぎなかったためです。これに代わる新たな指標は提示されていませんが、現在の攻撃は「推論速度」で実行され、対応する猶予が全く残されないという点が指摘されています。
翌日、Unit 42は「10時間に及ぶ侵入」について公表し、その「10時間」という時間の内訳について独自の見解を示しました。それは推測に基づくものではなく、次のような記述によるものです。「AIエージェントは攻撃フローにおける各ステップ間の時間を短縮します。今回の攻撃で使用されたAIエージェントは、ツールの生出力を解析し、迅速に次のステップへ移行するように設計されていました」。レポートのどこにも、モデルのレイテンシ（応答遅延）については言及されていません。そこで触れられているのは、並列処理、オペレーターとのやり取りを介さないリアルタイムの再計画、そしてツールの出力から次のアクションが実行されるまでの間に人間による介在（待ち時間）が生じない、という点です。
所要時間を並べて比較してみましょう。Sysdig（モデルが支援する人間による手動操作）：8分。Unit 42（人間が目標を設定し、エージェントが実行）：10時間未満。ソフォスが追跡した、AIを一切使用していないランサムウェアグループ：17時間未満。Dream：およそ4日。Hugging Face：4.5日。
自動化が進めば所要時間が短縮されるという単純な図式は成り立ちません。個々の手順を人間が直接指示しなかった2つのケースは、所要時間が最も長く（他のケースの約10倍）、AIを一切使わなかった人間は、エージェントを運用した人間よりも時間がかかりました。所要時間を左右するのは、モデルが作業のどれだけを担ったかではなく、目的がいかに厳密に定義されていたかという点です。作業時間の短縮は紛れもない事実ですが、それを「推論速度」と呼ぶのは、制御すべき要因を誤って捉えています。
どうすればいいか
ここでの変更は、枠組みそのものを変えるものではありません。リストの順序を変えるだけです。
- 自身のフロントエンドが公開しているものを列挙してください。APIエンドポイント、OAuthクライアントID、IDプロバイダーの設定などです。バンドルはすでに解析され、相互参照されていると仮定してください。
- 認証されていないAPIは、単なる「衛生上の問題」ではなく、「アイデンティティの問題」として扱うべきです。認証情報なしでスタッフ名やSSO識別子を返すエンドポイントは、ユーザー名リストに他なりません。公開されている内容ではなく、それがどのような情報を提供しているかという観点から、その重要度を評価してください。
- トークンアルゴリズムの検証と、フェデレーション間の信頼関係の監査を行う。 次のJWTが受け入れられました
なしこれは、認証を行わないことに合意した認証システムです。そして、85件中84件ということは、SSOブリッジこそが真の被害範囲であることを意味します。 - AIツールやコンピューティングリソースを攻撃対象領域として把握してください。npm wormsはセッションフックを介して実行され、AIプロバイダーのキーを探し出します。Unit 42の攻撃者は、被害者自身のモデルエンドポイントをインフラとして利用し、オーケストレーショントラフィックを通常のトラフィックに紛れ込ませ、そのコンピューティングコストを被害者に請求しました。
- ペイロードではなく、ループを追跡せよ。Unit 42が提示した指標は、エージェント型侵入に関してこれまでに公表されたものの中で最も具体的なものだ。具体的には、バースト状のAPIリクエスト、401から200への急速なステータス変化、並行認証、そして予期せぬIDによるモデルの突発的な使用などが挙げられる。
この中で、振る舞い検知がどのような位置づけにあるか
5件の侵入はすべてログに記録されていました。しかし、それだけでは不十分であることを示す最も明確な例が「Unit 42」の事例です。API呼び出し、リポジトリのチェックアウト、シークレットの読み取り、パイプラインの実行、そしてモデルエンドポイントに対するクラウドキーの使用。これらはそれぞれ単独で見れば正当な操作であり、適切なログにも記録されていました。インシデント対応において10時間という時間は長いものですが、事後に5つのシステムのログを手作業で突き合わせて一連の流れを把握しなければならない状況においては、瞬く間に過ぎ去ってしまう短い時間でもあります。
Hugging Faceが自社の事例について説明した一節は、この夏に公開された情報の中で最も有益なものです。最初の兆候は複数のレイヤーから同時に現れましたが、「それら単独では、いずれも曖昧なもの」でした。その後、「……それらの兆候は、AIベースのセキュリティエージェント・スタックによって相関分析され、一貫性のある攻撃の兆候として特定されました。しかし、アラートの重要度を適切に引き上げてオンコール・チームを呼び出すことには失敗し、その結果、対応において貴重な時間が失われることになりました」。
相関処理は機能しました。システムは曖昧なシグナルを統合して一連の整合性のある攻撃として捉えましたが、その結果はそのまま放置されました。誰かを起こして対応させるほど緊急性が高いとは判断されなかったからです。これは「検知」には成功したものの「トリアージ」に失敗したケースであり、対処法も異なる別の問題と言えます。
検出は壊れているのではなく、不完全なのです。これは、オペレーターが人間でタイピングしていた時にも当てはまり、この5人は、オペレーターが一度に14の攻撃チェーンをランク付けするフレームワークである場合にも当てはまると述べています。攻撃の背後にあるブランドではなく、その動作を追跡してください。
「3つのギャップ」に関する詳しい解説は、『Mind Your Attack Gaps』に掲載されています。