調査基準日：2026年9月20日
本稿は、Palo Alto Networks Unit 42が公開した資料を中心に、公開情報をOSIIXが独立に整理・考察したものです。Palo Alto NetworksまたはUnit 42による承認、監修、提携を示すものではありません。
はじめに
2026年9月、Palo Alto Networks Unit 42は、AIを利用した攻撃者による企業ネットワークへの侵入事例を公表しました。
記事には「10時間未満」「50を超えるMITRE ATT&CK techniques」「人間のオペレーターなら通常約2週間」といった数字が並びます。しかし、「10時間未満」は報告された活動時間であり、「約2週間」はUnit 42による比較評価です。同じ種類の測定値ではありません。
AI利用についても、攻撃者自身の説明と、Unit 42が観測した技術的な兆候は分けて読む必要があります。
本稿では、何が確認でき、何が評価で、何がまだ分からないのかを区別したうえで、この事例から何を考えられるかを整理します。
1. 何を一次資料として読んだのか
本稿で「Unit 42の公開資料」と呼ぶ場合、特に断らない限り、2026年9月2日付でUnit 42公式サイトに掲載された “An AI-Assisted Cyber Attack: Inside a Unit 42 Investigation” を指します。Unit 42の記事一覧でもSeptember 2, 2026として掲載されています。
今回の調査では、この事件について同記事とは別のUnit 42公式full reportは確認できませんでした。
初期版と現行版
2026年9月2日にWayback Machineへ保存された初期版では、冒頭に次の表現がありました。
“as part of a ransomware attack”
現行版では次の表現が残っています。
“as part of a ransom attack”
一方、現行ページ末尾の更新履歴では、9月3日に本件がintrusionであり、ransomware attackではないことを明確化したと記録されています。9月4日にはminor clarifying copyeditsも記録されています。
本稿では後発の明示的な更新履歴を基準とし、現在の事件分類をintrusionとして扱います。
初期アクセス経路についても本文変更が確認できます。
初期版：
“public API endpoint”
現行版：
“publicly accessible web service”
§2で侵入経路を「公開Webサービス」と記述するのは、現行版の記述に従ったものです。
この変更は、現行ページの更新履歴では個別には説明されていません。9月4日のminor clarifying copyeditsに含まれる可能性はありますが、今回の資料だけでは、どの更新時点で変更されたかまでは特定できません。
したがって、確認できるのは本文表現が変化したことまでであり、その理由や編集意図は推測しません。
なお、Wayback Machineには中間時点のcaptureも存在しますが、本稿では9月2日の初期版と9月20日に確認した現行版の二点を比較しています。中間版すべてについて網羅的な差分解析を行ったものではありません。
2. Unit 42が報告している侵入の流れ
現行記事によれば、攻撃者は公開Webサービスから企業ネットワークへ入り、内部環境の探索、code repositoriesからのcredential取得、secrets management systemへのアクセス、CI/CDやcloud環境への展開を進めたとされています。
Terraform configurationsへのbackdoor変更も試みられましたが、その変更はbranch-protection controlsによって阻止されたとUnit 42は報告しています。
ここから直接言えるのは、この特定の変更がbranch protectionによって止まったということです。
一方、Unit 42自身は一般的な対策として、Infrastructure-as-Code repositoryへのmulti-party code reviewとimmutable branch protectionも推奨しています。
この二つは分けて読みます。
- この事件で特定の変更が阻止されたという観測
- Unit 42が同種の仕組みを一般的対策として推奨しているという事実
後者が存在しても、この一件だけでbranch protectionの一般的な効果量まで実証されたことにはなりません。
4. AIを使っていたことは、どこまで確認できるのか
Unit 42によれば、攻撃者はUnit 42との交渉でfrontier AI modelsとattack-specific agentic AI frameworksを利用したと述べています。これはまず、攻撃者がそう説明したという報告です。
それとは別に、Unit 42はparallel LLM calls、structured Markdown、custom scriptsなどをAI利用と整合するtechnical indicatorsとして挙げています。
この二つは異なる証拠経路です。
- 攻撃者自身の説明
- Unit 42が観測した技術的な兆候
両方が存在することは重要ですが、それでも「すべての攻撃工程をAIが自律的に実行した」とは言えません。
Unit 42のFigure 1も、人間のactorがobjectivesと重要判断を担い、specialized agentsが実行・結果共有・適応を行う構造を示しています。
公開資料から見えるのは、完全なhuman-free attackというより、human-directed / agent-executedに近い運用像です。
5. それでも分からないこと
公開資料からは、少なくとも次の点を確定できません。
- 使用された具体的なAI modelとagentic framework
- 「約2週間」という比較値の詳細な算出方法
- AI・従来型automation・人間がそれぞれどの程度結果に寄与したか
- 50+ ATT&CK techniquesの完全な一覧
- 各重要判断をAIと人間のどちらが担ったか
- 事件全体の滞在期間、最終的な被害範囲、復旧状況
これらは推測で埋めず、UNKNOWNとして残します。
6. この事例から考えたいのは「速度」より「並行化」ではないか
ここからはUnit 42の事実認定ではなく、OSIIX側の考察です。
公開資料だけでは、「AIによって個々の作業が何倍速くなったか」は測れません。
一方、この事例では複数のagents、parallel LLM calls、session間の情報受け渡し、複数の活動を維持する運用像が示されています。
そこで、別の仮説を置くことができます。
AI-assisted intrusionの効果は、単一作業の高速化だけでなく、複数の作業streamを並行して維持するときのcoordination costやhandoff latencyの低下にも現れるのではないか。
この仮説を検証するなら、見るべきなのは単純な総所要時間だけではありません。
- 同時に活動するagent / session数
- 独立したtaskが時間上どの程度重なるか
- agent間で状態や結果が受け渡された回数
- 観測結果から次のactionまでの時間
- human approval待ちが全体時間に占める割合
- 失敗から再計画までの時間
- 一人の人間が同時に監督できるtask数
- human-only、従来型automation、AI-assistedの差
などが候補になります。
この仮説には反証条件もあります。
詳細なtimelineを得た結果、
- 行動の大半が逐次的だった
- 同時に動くagentがほとんどなかった
- 各段階に長いhuman approval待ちがあった
- agent間handoffが実質的な時間短縮を生んでいなかった
- 同等の並行性を従来型automationでも実現できた
のであれば、この仮説は弱くなります。
つまり、「AIだから何倍速かったか」だけではなく、何が並行化され、どの待ち時間や引き継ぎコストが変化したのかを測る必要があります。
campaign tempo、coordination cost、human supervision、AI固有寄与、従来型automationとの差については、別の研究へ引き継ぎます。
7. まとめ
この事例では、短時間に多数の攻撃行動が行われ、AI利用と整合する技術的な兆候も報告されています。
一方、「10時間未満」と「約2週間」は同じ種類の数字ではありません。前者は報告された活動時間、後者は比較評価です。
また、AIが使われたことを示す材料と、AIが結果をどれだけ変えたのかを示す測定値も同じではありません。
この事例から考えるうえで重要なのは、単純な速度倍率だけではなく、人間とagentsの間で仕事がどう分割され、どの程度並行化され、どの待ち時間が変化したのかを見ることだと考えます。
それを確かめるには、より詳細なtimelineと比較データが必要です。
8. 参照資料と方法
MITRE ATT&CK
ATT&CKにおけるTechniqueの意味を確認するため参照しました。
整理方法
公開資料を、
- 公開資料で確認できる事実
- 公表組織による評価
- 第三者から伝えられた内容
- 公開情報から確認できない事項
- OSIIXによる考察
に分けて読みました。
原文から短く直接引用する場合は引用として統一し、識別子やcodeだけをインラインコードとして扱います。
一般語は可能な限り日本語を使用し、intrusion、ATT&CK Technique、technical indicators、structured Markdownなど、原典との対応関係を保つ必要がある術語のみ英語表記を残します。
参照元は今後更新される可能性があります。本稿は2026年9月20日時点で確認した公開情報を基準としています。