攻撃チェーン自動生成、細かい表現は不要か｜研究解説

2026.08.06

【更新 2026-08-07】本記事を見直し、修正しました。主な修正点：論文が「解の成否とコストが両方式で一致するのは9分類版が5分類版の再ラベリングであるためで、設計上保証された結果であり粒度の効果の証拠にはならない」と明記している点を追記／LLM翻訳に一部GPT-4oが使われている点を反映／9分類から5分類への畳み込みでData→Informationの記載を補足／ATT&CK v19で「防御回避」戦術が分割された旨を注記。

攻撃者の一連の動き（攻撃チェーン）を自動で組み立てるAIの研究で、「攻撃手法をどれだけ細かく記号化するか」は生成される攻撃チェーンの妥当性をほとんど左右しないという結果が報告されました。2026年7月31日にarXivで公開された査読前の論文です。攻撃シミュレーションや侵入経路の自動診断ツールを検討している情シスにとって、ベンダーの「モデルが精緻です」という説明をどう受け止めるかの判断材料になります。

この記事でわかること

  • 攻撃チェーンの自動生成が、いま何をどこまでやろうとしているのか
  • 「表現の粒度」を9分類から5分類に減らしても結果が変わらなかった実験の中身
  • この結果を情シスが自社の判断にどう使えるのか、使えないのか

どんな研究か

論文のタイトルは「Symbolic Attack Chain Generation from Atomic Red Team Techniques: An Empirical Study of Predicate Representation Granularity」、著者はRamya Varunsegar氏、arXiv番号は2608.00143です。分野はcs.CR（情報セキュリティ）とcs.AI（人工知能）で、ライセンスはCC BY 4.0です。arXivの多くがそうであるように査読前のプレプリントであり、結果は今後変わりうる点に注意してください。

研究テーマを一文でまとめると、攻撃手法を「記号（述語）」に翻訳するときの細かさが、自動生成される攻撃チェーンの質にどれだけ効くのかを実測した研究です。

そもそも攻撃チェーンの自動生成とは何か

攻撃チェーンの自動生成とは、個々の攻撃手法を「前提条件」と「実行後の状態」で表現し、それらを機械的につなげて多段階の攻撃シナリオを組み立てる技術です。たとえば「LSASSからの認証情報窃取」には管理者権限が必要で、実行すると認証情報が手に入る——この因果関係を形式的に書いておけば、コンピュータが「権限昇格→認証情報窃取→横展開」という筋の通った順序を自力で導けます。

手作業でこれを書き続けるのは限界があります。MITRE ATT&CKの手法は増え続けており、その組み合わせは人手で網羅できる数ではありません。だからこそ自動化が研究されています。

実験のしくみ

研究では、翻訳と推論を分ける構成が採られました。

  • 翻訳担当：大規模言語モデル（GPT-4.1、temperature 0）が、Atomic Red TeamのYAML定義と実行時の証跡を読み、述語への翻訳案を出す
  • 検証：LLMの出力はルールベースで独立に検証してから正式なモデルへ取り込む
  • 推論担当：AI計画の標準記述言語PDDLに落とし、古典プランナ「Fast Downward」が決定論的に解を求める
  • 実行環境：隔離したWindows 11の仮想マシン。Windows Defenderを有効のままにして、現実に近いエンドポイント防御の条件を保つ

ここで登場するAtomic Red Teamは、Red Canaryが公開しているオープンソースのテスト集で、各テストがMITRE ATT&CKの手法に対応づけられ、1件5分以内で終わるよう設計されています。自社の検知が効いているかを確かめる用途で使われるもので、実行証跡が取れるため「机上の定義」ではなく「実際に何が起きたか」を根拠にできる点がこの研究の肝です。

なぜ「粒度」が問題になるのか

先行研究のAURORAというシステムは、攻撃アクションを結びつけるために9分類の述語体系（Attack Action Linking Model、AALM）を採用しています。ただし論文が指摘するのは、「なぜ9分類でなければならないのか」が検証されないまま使われてきたという点です。分類が多いほど記述は精緻になりますが、その分だけ作成・保守のコストは上がります。効果に見合っているのかは、実は誰も測っていませんでした。

そこで研究では、Atomic Red Teamの実行証跡から経験的に導いた5分類の簡約版（Mini-AALM）を用意し、9分類と突き合わせました。5分類は Executor（実行手段）／Process（プロセス）／Privilege・User（権限・利用者）／Information（情報）／Environment（環境）です。元の9分類のうちPayloadはExecutorへ、File と Technique はEnvironmentへ、DataはInformationへ畳み込まれています。

興味深いのは、Privilege・Userの分類が設計上あらかじめ用意したものではなく、非管理者権限での実行時にアクセス拒否が続発したことから、実測に押される形で必要になったという点です。机上で分類を切るのと、実際に動かして分類が要ると分かるのとでは、根拠の強さが違います。

何が分かったのか

評価対象は16手法です。T1059.001（PowerShellによる実行）、T1547.001（レジストリによる永続化）、T1003.001（LSASSダンプ）、T1021.002（SMBによる横展開）に加え、探索（T1057、T1046、T1082、T1018、T1087.001）、防御回避（T1112、T1070.004、T1055）、収集（T1560.001）、永続化（T1053.005）、持ち出し（T1041）、アカウント作成（T1136.001）と、複数の戦術にまたがっています。なお「防御回避（Defense Evasion）」は2026年4月28日公開のMITRE ATT&CK v19で「Stealth（TA0005）」と「Defense Impairment（TA0112）」に分割されており、論文は注記のうえで当時の呼称をそのまま用いています。

観点 9分類AALM 5分類Mini-AALM
解が得られた手法 13／16（81.3%） 13／16（81.3%）
プラン単価（平均コスト） 1.0 1.0
4手法の連鎖シナリオ コスト4の同一プラン コスト4の同一プラン
解なしと判定された手法 3（モデル上の意図どおり） 3（同左）

要するに両者の結果はほぼ一致しました。論文の要旨は「81.3%で結果が同一」と表現しています。ただしこの表だけを「粒度は効かない」の証拠として読むことはできません。論文は、9分類版のPDDLドメインが5分類版の述語ラベルを付け替えただけの「バイト単位で同一の再ラベリング」であり、プランナ側は述語の構造だけを見て分類という概念を持たないため、解の成否とコストが一致することは設計上あらかじめ保証されていると明記しています（第4.4節）。粒度の効果を実際に問うているのは次の指標です。述語カテゴリの解像度で見ると、16手法中14手法で粒度による差はゼロでした。実質的な差が出たのはT1560.001（収集データのアーカイブ化）だけで、T1003.001で見えた差は前提条件のプレースホルダに由来する見かけ上のものだったと整理されています。

著者の結論は控えめです。粒度を上げることは「攻撃チェーンが成立するかどうか」ではなく「なぜその順序になるのかという説明の内部解像度」を高める方向に効いている、という位置づけです。

実務へのインパクト：情シスは何を読み取るべきか

攻撃シミュレーションの自動化は、もう実務で使えるのか

限定的には使えますが、任せきりにできる段階ではありません。16手法という小さな範囲での検証であり、生成されたプランの多くは単一アクション（コスト1）でした。多段階の攻撃シナリオを自力で豊かに組み立てられることが示されたわけではない、というのが正確な読み方です。

ツール選定でどこを見るか

この研究から実務に持ち帰れる示唆は、「モデルの精緻さ」と「出力の使い物になり度」は別物だという一点に尽きます。攻撃経路の自動診断やBAS（侵害・攻撃シミュレーション）系の製品を評価するとき、分類体系の細かさや対応手法数のカタログスペックだけで比べても、実際に出てくる攻撃チェーンの妥当性は判断できません。むしろ確認すべきは、その根拠が実行証跡に基づいているか、そして自社の環境（権限設計、EDRの有無、OSバージョン）を反映できるかです。今回の研究でPrivilege・Userの分類が実測から必要になった経緯は、まさにその裏返しといえます。

現場目線の所感

正直なところ、こうした研究を読むたびに「うちの環境でそのまま成り立つ話ではないな」と感じます。実験はWindows 11の仮想マシン1台、単一ユーザーアカウントです。実際の社内は、部署ごとに違う権限設計、退職者の残存アカウント、例外申請で管理者権限が付いたままの端末、部門が勝手に入れた業務アプリが同居しています。「前提条件」がきれいに書ける環境のほうが、社内にはむしろ少ないのが実感です。

それでも、攻撃を単発の手法ではなく連鎖として捉えるという発想自体は現場に効きます。個々のアラートは潰せていても、「この探索の次に権限昇格が来たら止められるか」という問いには答えられていない組織が多いはずです。人員が限られる中で全経路を検証するのは非現実的ですが、自社にとって痛い着地点（基幹サーバ、顧客情報のある共有）から逆算して数本だけ経路を描いてみる、という使い方なら手が届きます。

限界・留意点

論文自身が挙げている限界は率直で、そのまま押さえておく価値があります。

  • 査読前のプレプリントであり、結果は今後変わりうる
  • 4手法の連鎖シナリオには、意図した順序を強制する文書化されていないモデル上の仮定が含まれており、実証的な裏づけがない
  • 証跡は単一の仮想マシン・単一ユーザーアカウントから得たもので、一般化には限界がある
  • LLMの翻訳はGPT-4.1・temperature 0が中心で（1つの手法バッチのみGPT-4o）、再現性の主張はこれらのモデルと設定に限定される。他モデルとの比較検証は行われていない
  • Windows Defenderが有効という条件はこの環境固有のもので、手法そのものの普遍的な性質ではない
  • プランコストという指標は、大半が単一アクションになったため弁別力が乏しかった

著者自身、ホストやドメイン、権限構成をまたいだ一般化に関する主張は暫定的なものとして読まれるべきだと述べています。ベンダー資料でこの種の研究が引用されていたら、この但し書きまで込みで確認したいところです。

情シスはどうすべきか

攻撃チェーンの自動生成は研究段階の話ですが、「連鎖を想定して備える」こと自体は今日からできます。自前で長大なチェックリストを作るより、公的機関の教材を土台にするほうが早く、説明もしやすくなります。

あわせて、当サイトの関連記事もご覧ください。

まとめ

  1. 攻撃チェーンの自動生成において、述語の粒度を9分類から5分類に減らしても、16手法中81.3%で結果は同一でした。粒度はチェーンの成立可否ではなく説明の解像度に効いています。
  2. Atomic Red Teamの実行証跡から必要な分類が導かれた点が重要で、机上の分類体系より実測に基づくモデル化が効くことを示しています。
  3. ただし単一VM・単一アカウント・16手法という査読前の小規模検証です。ツール選定では分類体系の細かさより、自社環境を反映できるかを見るべきです。

出典

タイトルとURLをコピーしました