ドリーム・リサーチ・ラボズによると、2026年7月の初旬、ある自動化された攻撃フレームワークが政府のウェブポータルからJavaScriptバンドルをダウンロードし、それらを解析した。
悪用されたわけではない。解析されたのだ。ポータルが設計上、すべての訪問者に提供するコードから、APIエンドポイント、IDプロバイダーの設定、および2つの署名鍵を抽出し、それらを結びつけるシングルサインオンインフラを含む、21の連携した政府システムを特定した。
何も破られてはいなかった。ペネトレーションテスターなら誰でも、作業開始から最初の1時間以内にこれを行うものだ。新しい点は、フレームワークがこれを実行し、発見したものをランク付けし、指示を待たずに次の段階に進んだということだ。
今年、「AI攻撃」として提訴された5件の事例を読みました。これらを並べてみると、見出しからは読み取れない事実が浮かび上がります。どの事例も、既存の技術以外を必要とする手法は一切使われていませんでした。最新の事例では、一連のプロセスを10時間未満に短縮しましたが、その短縮は、既知の手順間の休止時間を削除したことによるものでした。
5つの事例
可燃性物質を持った人間の操作員。
Sysdigは、2025年11月28日に発生した侵入事件について報告しました。この事件は、パブリックS3バケットに公開されていたAWSの認証情報から始まり、バックドアを介した管理者権限の取得に至りました。 Lambdaの実行まで8分、管理者権限の取得まで10分未満。Sysdigのタイトルには「AI支援」とあり、その調査結果は慎重な表現となっている。「脅威アクターが大規模言語モデルを活用したことを示唆する複数の指標」とされている。私の解釈では、これはモデルが偵察やコード生成を加速させているものの、実際にキーボードを操作しているのは人間であり、エージェントとは異なる。この件については、こちらで取り上げている。
人間が目標を設定し、エージェントがそれを実行する。
Unit 42は2026年9月2日にこれを公開しましたが、これはこのセットの中で最も難易度の高いケースです。公開APIが侵害され、リポジトリからハードコードされたトークンが徹底的に捜索され、それらのトークンを利用してシークレットマネージャーへのアクセスが許可され、CI/CDが乗っ取られてクラウドキーが盗まれ、最終的には被害者自身のAIエンドポイントが攻撃インフラへと変貌しました。10時間未満で、50以上のMITRE ATT&CK の手法が用いられました。
見出しではなく、記事の論調に注目すべきだ。冒頭では、ネットワークが「自律的に」侵害されたと述べられているが、図のキャプションは「攻撃者は目標を設定し、重要な決定を下す」と正確に記されている。この件が注目に値する理由についての要約にある「AIを活用した業務効率化は、新たなzero-day や超エリート級の技術力を必要としない」という一文こそが重要だ。至る所で引用されている「2週間の比較」は、彼ら自身のレッドチームによる推定であり、実際に観測された侵入ではない。1つの防御策は機能していた。Terraformの設定にバックドアを仕込もうとする試みは、「厳格なブランチ保護対策によって阻止された」ため失敗したのだ。また、彼らは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キーが「戦利品」として扱われ、何も決定権を持つものが存在しないという状態です。
実環境における準自律型フレームワーク。
8月12日に公開された「Back to the Dream」事件について。復元されたワークスペースには、12回の攻撃波にわたる1,395個のファイルが含まれており、各波ごとに最大8つのサブエージェントを起動させながら、14の攻撃チェーンを継続的にランク付けしていた。本記事の残りの部分は、以下の3つの発見点に焦点を当てる。認証されていないAPIが、認証情報を指定せずに有効なセッションを返すこと、あるAPIが、 なし アルゴリズムにより、スプレー攻撃によって85のアカウントが侵害され、そのうち84件はSSOブリッジを経由して内部システムへと侵入した。
「Dream」が使用し、ほとんどの報道で省略された言葉に注目してほしい。「準自律型」だ。このプロセスには人が関与しており、その活動を「承認された侵入テスト」と位置づけることで、モデルの拒否を迂回していた。
これらの数値は、フレームワーク独自のレポートに基づいています。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件。
この圧縮は実測値です。モデル上の速度ではありません。
「ブレイクアウト時間」（初回アクセスから最初の横方向の移動までの時間）は、業界で「マシンの速度」と呼ばれてきたものは、実際にはより優れたツールを用いた「人間の速度」に過ぎないという理由から、9月1日にCrowdStrikeによって指標として廃止されました。代替となる指標は明示されず、攻撃は現在「推論速度」で実行され、時間を全く残さないという主張にとどまっています。
翌日、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ワームはセッションフックを介して実行され、AIプロバイダーのキーを探し出します。Unit 42の攻撃者は、被害者自身のモデルエンドポイントをインフラとして利用し、オーケストレーショントラフィックを通常のトラフィックに紛れ込ませ、そのコンピューティングコストを被害者に請求しました。
- ペイロードではなく、ループを追跡せよ。Unit 42が提示した指標は、エージェント型侵入に関してこれまでに公表されたものの中で最も具体的なものだ。具体的には、バースト状のAPIリクエスト、401から200への急速なステータス変化、並行認証、そして予期せぬIDによるモデルの突発的な使用などが挙げられる。
この中で、行動検知がどのような位置づけにあるか
5件の侵入すべてがログに記録されていました。Unit 42の事例は、それだけでは不十分である理由を最も明確に示しています。API呼び出し、リポジトリのチェックアウト、シークレットの読み取り、パイプラインの実行、モデルエンドポイントに対するクラウドキーの使用。いずれも個別に承認されており、適切なログにも記録されていました。インシデント対応において10時間は長い時間ですが、事後的に5つのシステムを手作業で組み立てて初めて一連の経緯を把握しなければならないのであれば、それは全くの無駄な時間です。
Hugging Faceが自社の攻撃がどのように発覚したかを説明した記述は、この夏に公開された記事の中で最も参考になる一節だ。最初の兆候は複数のレイヤーから同時に検出されたが、「それ単体では、それぞれが曖昧なものだった」。その後、「[...] それらは当社のAIベースのセキュリティエージェントスタックによって相関付けられ、一貫性のある攻撃の兆候として特定された。しかし、アラートの重要度を正しく引き上げ、当直チームを起動させることに失敗したため、対応に貴重な時間を費やすことになった」と述べられている。
相関分析は機能した。スタックは曖昧なシグナルを1つの首尾一貫した攻撃として統合したが、その後、その発見はそのまま放置されてしまった。というのも、誰かを呼び起こすほど緊急性が高いと判断する者が誰もいなかったからだ。これは、検知の成功の末に生じたトリアージの失敗であり、別の問題であり、別の解決策が必要となる。
検知機能は故障しているわけではない。不完全なだけだ。これは、オペレーターが人であり、手動で入力していた時代にも当てはまることであり、これら5人は、オペレーターが14の攻撃チェーンを同時にランク付けするフレームワークであっても、このことが当てはまると述べている。攻撃の背後にいる組織ではなく、その挙動を追跡すべきだ。
「3つのギャップ」に関する詳しい解説は、『Mind Your Attack Gaps』に掲載されています。