MITRE ATT&CK v20のAI攻撃技術｜プロンプトインジェクションとAI経由の持ち出しを自社AI機能に当てはめる

MITRE ATT&CK v20 が2026年10月13日に公開され、ATT&CK v20 の Enterprise に企業が組み込んだLLMやAIエージェントそのものを悪用する技術が入りました。これまでのAI関連の技術は「攻撃者がAIを使う」側だけでした。

連載「事故から逆算するWebセキュリティ」の第5回は、v20で新しく載った事例（メキシコ政府機関への侵入）を入口に、追加された技術をWebアプリのAI機能に当てはめます。

インシデントの読み方の全体像は サプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説 に、攻撃の手口そのものは プロンプトインジェクションの解説 にまとめています。

ATT&CK v20 で何が追加されたか：タイムラインと新技術9件

MITREのリリースノート（attack-website リポジトリの原稿）は、v20の最大の変更を最近の攻撃の取り込みとし、米国の水道事業への攻撃と、AIを使ったメキシコ政府機関への侵入の2つの新しいキャンペーンを挙げています。後者（C0064）は、攻撃者が Claude Code と GPT-4.1 を使って偵察から持ち出しまでを進めた事例です。MITREはこのキャンペーンに T1699（直接プロンプトインジェクション）を結び、攻撃者がプロンプトの中のファイル書き込みで、侵入用スクリプトを含む1,084行の claude.md を作らせたと書いています。

Enterpriseの新技術は次の9件です。当サイトが v19.2 と v20.0 のSTIXデータを突き合わせた結果と、リリースノートの「New Techniques」の一覧は一致しました。

「AI」の列は当サイトの分類です。リリースノートは件数を示していません。T1696もCAPTCHAを解くAIツールに触れますが、主題は自動化チェックの回避なので数えていません。

v19.2の時点でも、AIを扱う技術はありました。T1588.007（生成AIの入手）、T1682（公開AIサービスへの問い合わせ）、T1683（偽の文面・音声の生成）です。どれも攻撃者が自分の作業にAIを使う技術で、守る側が運用しているAIが狙われる技術はv20が初めてです（v19.2の全技術の説明文に「prompt injection」を含むのは T1027.018 Invisible Unicode の1件だけでした）。

ATT&CK v20 のAI技術5件をWebアプリのAI機能に当てはめる

5件は別々の技術ですが、Webアプリの中では1本の流れになります。T1700の説明は、注入した指示がエージェントの「承認済みのツール」を使わせて持ち出す流れを書いています。

T1698の説明は、注入の置き場所として「Webページ、文書、メール、チケット、コード」を挙げています。社内向けのAI機能で利用者を信頼していても、読み込む内容を外部の人が書ける限り間接注入の経路は残ります。当サイトで扱った GitHub Agentic Workflows の「GitLost」 は、公開Issueの文面がエージェントを動かした例です。

T1685.007は、マルウェアの中にLLMのプロンプトの体裁をまねた偽のシステムメッセージを入れ、解析するAIに「エラーが起きた」と思わせて解析を止める手口を書いています。SOCやセキュリティ診断にLLMを使っているチームが対象です。

ATT&CK v20 の検知戦略：持ち出しには付き、注入には付かない

v20で Enterprise に追加された検知戦略は6件で、AIに関わるのは2件です。

DET0927のSaaS向けの分析（AN2078）は、「AIエージェントが保護対象のデータに触れ、その内容を使ってツールやAPIを呼び、送信先が許可された流れの外への転送の成功を記録する」という並びを見ます。ログの例として、SaaSの監査ログの送信・共有・アップロード・書き込みの操作と、Amazon Bedrock の AgentTrace.actionGroupInvocationInput と AgentTrace.knowledgeBaseLookupInput を挙げています。調整する値は次の5つで、どれも自分のAI機能の設計から決める値です。

・ProtectedDataScope：保護する情報の範囲
・AuthorizedAgentActions：業務に要るツール・関数
・AuthorizedAIDataFlows：許可する「取得元→ツール→送信先」の組
・AuthorizedAIOutputDestinations：許可する宛先・ドメイン・テナント・リポジトリ
・AIExfiltrationWindow：取得から転送までの普段の間隔

Windows・Linux向けの分析は、AIのプロセスが許可範囲の外のデータを読み、同じプロセス系統から転送できるコマンドの実行と外向きの通信が続く並びを見ます（Linuxは auditd の open/read・EXECVE・connect）。

一方、T1698・T1699・T1685.007には検知戦略が結ばれていません。v20は注入の文面を見分ける方法を示しておらず、示しているのは注入の後に起きる送信を捕まえる方法です。AIの入出力を全文残すだけでは足りず、ツール呼び出しと送信先を構造化して残すことが前提になります。

対策：MITREの緩和策をAI機能の設計に落とす

v20はT1698・T1699に合わせて6つの緩和策を結び、それぞれにAI向けの説明を書いています。共通しているのは、モデルに「これは許可された操作か」を判断させないことです。

・M1038：外部の文面に含まれる指示だけで重要な操作を承認させない。ツールやAPIの要求は、モデルと独立した認可とポリシーで判定する
・M1018：エージェントに専用のIDを与え、最小の権限にする。直接注入では、操作を呼び出した利用者の権限を超えさせない
・M1026：信頼できない内容を処理するエージェントには、特権の操作を自動で行わせない。機密の操作は追加の承認を求める
・M1022：触れるファイル・リポジトリを業務に要る範囲に絞り、書き込みは読み取りと分けて制限する
・M1030：信頼できない内容を処理するエージェントの外向きの通信先を絞る
・M1017：AIが処理した内容は敵対的でありうると扱い、重要な操作は人が別に確かめる

手を付ける順は、自分のAI機能のデータの流れを1枚に書き出すところからです。「どこから読むか（T1698の入口）」「どのツールを呼べるか（T1700の手段）」「どこへ送れるか（T1700の出口）」を並べると、DET0927の5つの値がそのまま埋まります。AIセキュリティ全体の脅威の地図は AIセキュリティの入門ガイド で整理しています。

ATLAS・OWASP LLM Top 10 と ATT&CK v20 の使い分け

ATLASはv20より前からプロンプトインジェクションを AML.T0051 として持ち、AIエージェントのツール呼び出しを使った持ち出し（AML.T0086）やRAGの汚染（AML.T0070）も分けています（ATLASデータ 2026.09 で確認）。ATLASのほうが細かいので、AI機能そのものの脅威の洗い出しはATLASとOWASPで行い、SOCとの共通言語としてATT&CK v20のIDを付けるのが無理のない分担です。

自分の環境で確かめる：v19.2 と v20.0 の差分を取るコマンド

ATT&CKのデータはSTIX形式でGitHubに公開されています。次のコマンドは v19.2 と v20.0 の Enterprise のデータを取得し、増えた技術と検知戦略の有無を出します（取り消し・非推奨の技術は除く）。2つのファイルで約110MBを取得します。

B=https://raw.githubusercontent.com/mitre-attack/attack-stix-data/master/enterprise-attack
curl -sSO "$B/enterprise-attack-19.2.json" -sSO "$B/enterprise-attack-20.0.json"
python3 - <<'EOF'
import json
def load(f):
    objs = json.load(open(f))["objects"]
    tech = {o["id"]: next(r["external_id"] for r in o["external_references"] if r["source_name"] == "mitre-attack") + " " + o["name"]
            for o in objs if o["type"] == "attack-pattern" and not o.get("revoked") and not o.get("x_mitre_deprecated")}
    det = {r["target_ref"] for r in objs if r["type"] == "relationship" and r["relationship_type"] == "detects"}
    return tech, det
old, _ = load("enterprise-attack-19.2.json")
new, det = load("enterprise-attack-20.0.json")
added = sorted(set(new.values()) - set(old.values()))
print(len(old), "->", len(new), "/ added:", len(added))
for k, v in sorted(new.items(), key=lambda x: x[1]):
    if v in added: print(v, "| detection strategy:", "yes" if k in det else "none")
EOF

当サイトで2026年10月17日（JST）に実行した出力です（Python 3、取得から集計まで約6秒）。

697 -> 706 / added: 9
T1608.007 AI Result Poisoning | detection strategy: yes
T1685.007 Impair Autonomous Defenses | detection strategy: none
T1696 Anti-Automation Evasion | detection strategy: yes
T1696.001 Automate CAPTCHA Completion | detection strategy: yes
T1696.002 Avoid CAPTCHA | detection strategy: yes
T1697 Steal Application Specific Passwords | detection strategy: yes
T1698 Indirect Prompt Injection | detection strategy: none
T1699 Direct Prompt Injection | detection strategy: none
T1700 AI-Enabled Exfiltration | detection strategy: yes

有効な技術は697件から706件に増え、増えた9件はリリースノートの一覧と一致しました。影響範囲の確認としては、この9件のうち自分のAI機能に入口・手段・出口があるものを選び、ツール呼び出しと送信先のログが残っているかを見ます。ログが無ければ、DET0927の分析はそもそも組めません。

この出力の yes／none は、ATT&CK のデータに検知戦略が紐づいているかの確認で、自社の環境で検知できるかの判定ではありません。yes の技術でも、対応するログを集めて分析を組んでいなければ検知できるとは限りません。

技術の説明・緩和策・検知戦略はすべてGitHubのSTIXデータとリリースノートの原稿で確認しました。リリースノートが参照するMITREのブログ記事の本文は未確認です。

参照ソース

• MITRE ATT&CK: Updates - October 2026（リリースノートの原稿、mitre-attack/attack-website）
• mitre-attack/attack-stix-data（Enterprise v19.2 / v20.0 のSTIXデータ）
• MITRE ATT&CK: T1698 Indirect Prompt Injection
• MITRE ATT&CK: T1700 AI-Enabled Exfiltration
• mitre-atlas/atlas-data（ATLAS 2026.09）
• OWASP Top 10 for LLM Applications: LLM01:2025 Prompt Injection（GitHubの原稿）