AIエージェントを使ったサイバー攻撃、10時間未満にroot権限まで到達　Unit 42が実インシデントを分析

Palo Alto Networksの脅威インテリジェンスチームUnit 42は2026年9月、攻撃者がフロンティアAIモデルと攻撃用のAIエージェントを組み合わせ、企業ネットワークへの侵入を10時間未満で進めたインシデントを公表しました。

Unit 42によると、攻撃者は公開Webサービスへの侵入後、AIエージェントを使って内部ネットワークの探索、コードリポジトリからの認証情報収集、シークレット管理システムへの侵入、root権限の取得、CI/CDパイプラインの悪用、クラウドAI基盤の乗っ取りまで進めました。

攻撃では新規のゼロデイ脆弱性や高度な独自エクスプロイトが中心だったわけではありません。Unit 42が注目しているのは、従来は人間の攻撃者が順番に実施していた偵察・認証情報窃取・権限昇格・横展開などを、AIエージェントが並列かつ継続的に実行したことで、侵入速度が大幅に短縮された点です。

一方、この事案を「AIが単独で企業を攻撃した」と捉えるのは正確ではありません。Unit 42の分析では、人間の攻撃者が目的設定と重要な意思決定を行い、複数のAIエージェントが具体的な作業を分担していました。

AIエージェントを悪用した侵入事案のサマリー

• Unit 42は、人間の攻撃者がフロンティアAIモデルと攻撃特化型のAIエージェントを利用した実インシデントを調査しました。
• 攻撃開始からrootレベルの認証情報取得などに至るまでの主要な侵入活動は10時間未満でした。
• Unit 42は、攻撃全体で50を超えるMITRE ATT&CK技術が使われたとしています。
• 攻撃者は公開Webサービスから初期侵入し、その後AIエージェントを内部偵察へ投入しました。
• サブエージェントが企業のコードリポジトリを探索し、ハードコードされたトークンやサービス用パスワードを取得しました。
• 取得したトークンを使ってシークレット管理システムへアクセスし、root権限につながる管理認証情報を取得しました。
• CI/CD環境を悪用してクラウドアクセスキーを取得し、Terraform構成へのバックドア追加も試みました。
• Terraformへの変更は、ブランチ保護機能によって阻止されました。
• 盗んだクラウドキーを使い、被害組織のAIエンドポイントと計算資源も攻撃後のインフラとして利用しました。
• Unit 42は、複数LLMへの並列呼び出し、Markdownによるエージェント間の情報受け渡し、AI生成と高い確度で評価したスクリプトなど、AI利用を示す痕跡を確認しています。
• 新規ゼロデイ脆弱性への依存は確認されていません。
• 被害企業名、具体的な初期侵入脆弱性、利用されたAIモデル名は公表されていません。
• Unit 42は2026年9月3日の更新で、本件を「ransomware attack」ではなく「intrusion」と明確化しています。

項目	Unit 42が公表した内容
調査主体	Palo Alto Networks Unit 42
攻撃主体	人間の攻撃者がAIエージェントを指揮
所要時間	主要な侵入活動を10時間未満で実施
ATT&CK技術	50超
初期侵入	公開Webサービス
ゼロデイ	新規ゼロデイへの依存なし
内部偵察	AIエージェントがマイクロサービスやネットワーク構成を探索
認証情報窃取	コードリポジトリ内のトークン・サービスパスワードを取得
権限拡大	シークレット管理システムから管理認証情報を取得
CI/CD	不正なワークフロー実行、クラウドキー窃取
IaC改変	Terraformへのバックドア追加を試行、ブランチ保護で阻止
AI基盤	被害企業のAIエンドポイントを攻撃後のインフラとして利用
被害企業	非公表
利用AIモデル	非公表

人間が目的を設定し、AIエージェントが攻撃作業を並列実行

Unit 42の分析で確認したいのは、AIが人間から独立して攻撃対象を選び、完全自律的に企業を侵害した事案ではない点です。

同社が公開した攻撃フローでは、人間の攻撃者が目的を設定し、結果を踏まえて重要な判断を行っています。その下で複数の専門エージェントが作業を実行し、結果を共有しながら次の処理へ進んでいました。

Unit 42は、攻撃者自身も交渉の中で、フロンティアAIモデルと攻撃特化型のagentic AI frameworkを利用したと説明したとしています。

加えて、Unit 42は調査中に次のような技術的痕跡を確認しました。

• 複数のフロンティアAIモデルへの並列LLM呼び出し
• エージェントやセッション間で情報を引き継ぐ構造化Markdownファイル
• 動的な攻撃処理を管理するカスタムスクリプト
• AI生成コードと高い確度で評価されたUI要素を持つスクリプト

したがって、AI利用の根拠は攻撃者の自己申告だけではありません。

初期侵入後、AIエージェントが内部ネットワークを自動探索

Unit 42によると、攻撃者は最初にインターネットからアクセス可能なWebサービスへ侵入しました。

具体的な製品名、CVE番号、脆弱性の内容は公表されていません。

初期侵入後、攻撃者はネットワーク内へトンネルを構築し、自動偵察エージェントを投入しました。エージェントは内部マイクロサービス、ホスト構成、利用可能なサービスなどを調査し、次に狙う対象を特定しています。

Unit 42はこの段階をMITRE ATT&CKの「Exploit Public-Facing Application（T1190）」と「Network Service Discovery（T1046）」へ対応付けています。

従来の攻撃でも見られる手法ですが、今回の違いは、ツール出力の解析から次の探索処理までをAIエージェントが継続的に行った点です。

コードリポジトリから認証情報を収集、シークレット管理システムへ侵入

内部探索後、AIのサブエージェントは企業のコードリポジトリを検索しました。

Unit 42によると、ここからハードコードされたトークンやサービスパスワードが取得されています。

攻撃者は取得したトークンを利用してシークレット管理システムへ侵入し、さらに上位の管理認証情報を取得しました。その結果、システム全体のrootアクセスを掌握できる状態まで権限を拡大しました。

攻撃をAIで高速化しても、突破されたポイント自体は新しいものではありません。

コードや設定ファイルへ長期間残されていた認証情報と、取得した認証情報からより強い権限へ到達できる権限設計が攻撃を進める経路になっています。

Unit 42はこの処理をMITRE ATT&CKの「Credentials In Files（T1552.001）」や「Credentials from Password Stores（T1555）」に対応付けています。

CI/CDからクラウドキーを取得、Terraformへのバックドア追加も試行

攻撃者は開発・デプロイ環境にも侵入しました。

Unit 42によると、AIエージェントは企業のコードアプリケーションを不正なワークフローから操作し、CI/CD処理を実行してクラウドアクセスキーを取得しました。

さらに、Infrastructure as Code（IaC）として利用されていたTerraformの構成ファイルにバックドアを追加しようとしました。

この変更は成功していません。

Unit 42は、強制されていたブランチ保護機能によって不正なTerraform変更が阻止されたとしています。

今回の事案では、AIエージェントによって攻撃速度が向上しても、リポジトリ側で強制される変更承認やブランチ保護は有効に機能しました。

AIによる攻撃だから従来のセキュリティ制御が無効になるのではなく、攻撃速度に追従できる形で既存制御を強制できているかが確認点になります。

被害企業のAI基盤そのものを攻撃インフラへ転用

Unit 42が挙げたもう一つの特徴は、侵害後に被害企業自身のAI環境が攻撃へ利用されたことです。

攻撃者は盗んだクラウドキーを利用して被害企業のAIエンドポイントへアクセスし、その計算資源を後続の攻撃活動へ利用しました。

これにより、攻撃者は自前のAIインフラだけで処理を続ける必要がなくなります。

Unit 42は、企業のAIサービスを攻撃後のインフラとして悪用すると、攻撃者が処理コストを被害側へ転嫁できるほか、AIへのアクセスが企業内で通常発生する通信に紛れ込む可能性があると分析しています。

企業のAIセキュリティでは、従業員が何を生成AIへ入力しているかだけではなく、AI APIキーやモデルエンドポイント自体をクラウド・ID基盤と同じ管理対象として扱う必要があります。

関連記事：AIセキュリティとは？生成AI・AIシステムのリスクと企業のセキュリティ対策を解説

AIエージェントは「高度な新手法」より攻撃速度を変えた

今回の事案でUnit 42が強調しているのは、AIが未知の脆弱性を発見して従来不可能だった攻撃を実現したことではありません。

Unit 42は、新規ゼロデイや「super elite tradecraft」を必要とせず、AIによる運用効率が攻撃速度と規模を押し上げたと評価しています。

攻撃で使われた主な要素は、公開Webサービスへの侵入、内部サービス探索、コード内の認証情報取得、シークレットストアへのアクセス、クラウド認証情報窃取、CI/CD悪用といった既知の攻撃経路です。

違いは、人間のオペレーターがツールの出力を一つずつ読み、次のコマンドを考える工程の一部をAIが引き受けた点にあります。

Unit 42は、通常なら複数のレッドチームが約2週間かける規模の活動が、10時間未満に圧縮されたと説明しています。

この「2週間」は一般的な侵害時間の統計ではなく、Unit 42が今回と同規模のレッドチーム作業を比較した評価です。「AIを使えばすべての企業が10時間以内に侵害される」という意味ではありません。

50超のMITRE ATT&CK技術を一つの自動ループへ統合

Unit 42は今回の攻撃で50を超えるMITRE ATT&CK技術が使われたとしています。

公開レポートでは主要な攻撃段階として次のマッピングを示しています。

攻撃段階	主な処理	MITRE ATT&CK
初期侵入・偵察	公開サービスへの侵入、内部サービス探索	T1190、T1046
認証情報取得	コードリポジトリからシークレットを収集	T1552.001
権限拡大	シークレット管理システムから管理認証情報を取得	T1555
パイプライン悪用	CI/CDやクラウド基盤を操作	T1578
AI基盤悪用	盗んだAPIキーでAIモデルを利用	T1078

Unit 42はこれらをMITRE ATLASにも対応付け、AIを使った偵察、認証情報収集、自動ピボット、ML/DevOpsパイプライン悪用、盗んだAPIキーによるLLM利用などとして整理しています。

50超の技術が完全にAIだけで自律実行されたとまでは公表されていません。人間のオペレーターと複数AIエージェントを含む攻撃全体で確認された技術数として扱う必要があります。

攻撃者は80ページのセキュリティ監査レポートまで自動生成

Unit 42によると、攻撃者は侵入後、AIエージェントに被害企業のセキュリティ上の問題をまとめさせました。

作成された文書は約80ページに及び、侵入中に悪用した多数の問題点を技術監査レポートのような形式で整理していました。

Unit 42は、攻撃者がこのレポートを交渉材料として利用したとしています。

なお、Unit 42は2026年9月3日に記事を更新し、本件の表現を「ransomware attack」ではなく「intrusion」に修正しています。

そのため、本件でランサムウェアによるファイル暗号化が行われたと断定することはできません。交渉が行われたことと、典型的なランサムウェア攻撃が発生したことは分けて扱う必要があります。

AIエージェントによる攻撃で確認できる検知ポイント

Unit 42は、AIエージェントを利用した攻撃にも特有の痕跡が残るとしています。

同社が挙げている主な兆候は次のとおりです。

• 短時間に集中する大量のAPIリクエスト
• HTTP 401と200が短い間隔で繰り返される挙動
• 複数の認証処理が並列に発生する状態
• 通常利用していないIDからの突然のAIモデル利用
• エージェント間の情報伝達に使われる構造化Markdown
• Pythonのキャッシュファイル
• 対になったアセットフォルダー
• 複数LLMへの並列アクセス

ただし、これらは単独で攻撃を示すIOCではありません。

たとえばMarkdownやPythonキャッシュは通常の開発環境でも存在します。端末、ID、クラウド、CI/CD、AI APIのログを横断し、短時間に連続する不審な操作として検知する必要があります。

情報システム・CSIRTが確認したいポイント

今回の事案は、「AI攻撃専用」の新しいセキュリティ製品がなければ防げないことを示したものではありません。

むしろ、AIが既存のAttack Pathを高速でたどることを前提に、認証情報・CI/CD・クラウド・AI基盤を一続きの攻撃面として管理できるかが確認ポイントになります。

Unit 42の提言と今回の侵入経路から、企業側では次の項目を確認できます。

• ソースコードや設定ファイルへAPIキー、パスワード、トークンが残っていないか
• シークレット管理システムへアクセスできるIDの権限を最小化しているか
• 認証情報が漏えいした際、資格情報、OAuthセッション、クラウドアカウントを同時に失効できるか
• CI/CDパイプラインから取得可能なクラウド権限を必要最小限にしているか
• TerraformなどIaCの変更にブランチ保護と複数人レビューを強制しているか
• AIモデルのエンドポイント、APIキー、MCPゲートウェイ、AIツール連携を台帳化しているか
• AI APIキーにも利用主体、権限、有効期限、利用量制限を設定しているか
• AIモデル利用ログをSIEMやSOCで監視できるか
• 短時間に複数のクラウド・DevOps・ID基盤へ攻撃が波及した場合の自動封じ込め手順があるか

特にインシデント対応では、端末隔離だけでは不十分になる可能性があります。

今回の攻撃では、SSHキー、クラウドID、CI/CD、サーバーレス環境、AIエンドポイントなど複数の場所へ並行してアクセスが広がりました。Unit 42は、認証情報の失効、OAuthセッション終了、CI/CD停止、クラウドアカウント隔離などを同期して実行できる封じ込めプレイブックを推奨しています。

AIエージェント自体の権限設計については、AIエージェントのセキュリティとは―公的資料から見る6つのリスクと対策でも整理しています。

「AIを使った攻撃」の評価で確認したいこと

AIを使ったサイバー攻撃に関する公表では、「AIが利用された」という事実と、「AIだから初めて可能になった攻撃」を分けて評価する必要があります。

Unit 42は2026年8月に公開した別の調査で、AIと何らかの関連を持つマルウェア405件を分析し、実運用環境で確認した12件について既存のEDRがすべてアラートを生成したと報告しています。

関連記事：Unit 42、AI関連マルウェア405件を分析　実運用環境で確認は12件、既存防御で全件検知

今回のインシデントはそれとは性質が異なります。

AI生成マルウェアの検知回避ではなく、人間の攻撃者がAIエージェントを「攻撃オペレーションの自動化レイヤー」として利用し、既存の攻撃手法を短時間で連鎖させた事例です。

企業側では、AI特有の未知の攻撃手法だけを警戒するのではなく、既知のAttack Pathが従来より短時間で突破されることを前提に、検知から封じ込めまでの時間を見直す必要があります。

出典

• An AI-Assisted Cyber Attack: Inside a Unit 42 Investigation – Palo Alto Networks Unit 42
• MITRE ATT&CK – MITRE
• MITRE ATLAS – MITRE