MITRE ATT&CKとは?Tactics・Techniquesの見方とSOC・CSIRTでの活用方法

セキュリティ用語

投稿日時: 更新日時:

MITRE ATT&CKとは?Tactics・Techniquesの見方とSOC・CSIRTでの活用方法

MITRE ATT&CK(マイター・アタック)は、実際に観測されたサイバー攻撃者の行動を、Tactics(戦術)とTechniques(技術・手法)を中心に体系化したナレッジベースです。攻撃者が「何を目的に」「どのような方法で」行動したかを共通言語で整理できます。

2026年9月30日時点の最新版はATT&CK v19.2です。Enterprise ATT&CKは15のTacticsで構成され、222のTechniques、475のSub-techniquesが掲載されています。2026年4月のv19では、従来の「Defense Evasion」が「Stealth」と「Defense Impairment」に分割されました。そのため、現在も「ATT&CKは14フェーズ」と説明している資料は旧版を前提としている場合があります。

ATT&CKは攻撃を左から右へ順番に並べるチェックリストではありません。また、全Techniqueを100%カバーすることも目的ではありません。SOCやCSIRTでは、自社を狙う攻撃者やインシデントで実際に使われているTTPを選び、必要なログ、検知ルール、対策、演習へ接続するために使います。

従業員600人以上の企業では、EDR、SIEM、クラウド、ID基盤、ネットワーク機器など複数の監視対象が存在し、部門ごとに異なる用語でインシデントを扱うことがあります。ATT&CKを共通の分類軸にすると、脅威インテリジェンス、SOCの検知、CSIRTの調査、レッドチーム演習を同じTTPでつなげやすくなります。

MITRE ATT&CKとは

MITRE ATT&CKは、米国の非営利組織MITREが公開している、攻撃者の行動に関するナレッジベースです。

ATT&CKは「Adversarial Tactics, Techniques, and Common Knowledge」の略称です。MITREは、現実の攻撃で確認された攻撃者の行動を整理し、民間企業、政府機関、セキュリティ製品・サービス事業者が共通して利用できる形で公開しています。

ATT&CKには、主に次の情報が含まれています。

要素 内容
Tactics 攻撃者が何を達成しようとしているか
Techniques その目的をどのような方法で達成するか
Sub-techniques Techniqueをより具体的な方法へ分解したもの
Procedure Examples 実際の攻撃者・マルウェア・キャンペーンで確認された具体的な利用例
Groups 公開情報で追跡されている攻撃活動・脅威グループ
Software 攻撃で利用されたマルウェアや正規ツール
Campaigns 特定期間・標的に対する攻撃活動
Mitigations Techniqueに対する緩和策
Detection Strategies Techniqueを検知するための高レベルな検知方針
Data Components 検知に利用するログ・データの具体的な要素

ATT&CKは、単に「攻撃手法の辞書」として読むより、インシデント情報を検知・対策へ変換するための共通フォーマットとして使う方が実務につながります。

2026年9月時点の最新版はATT&CK v19.2

2026年9月30日時点の最新版はATT&CK v19.2です。

MITREは2026年4月28日にv19を公開し、8月6日にv19.2を公開しました。v19.2は、Groups、Software、Campaignsなどを必要に応じて更新する最初の「Agile release」と位置付けられています。

v19で大きく変わったのが、Enterprise ATT&CKのDefense Evasionです。

従来は、検知を避ける行動と、防御機能そのものを妨害する行動が「Defense Evasion」にまとめられていました。v19ではこれを次の2つへ分割しました。

  • Stealth:攻撃活動を隠し、正常な動作に見せる
  • Defense Impairment:ログ、EDR、ファイアウォールなど防御機能を無効化・弱体化する

たとえば、ファイルを隠す、難読化する、正規ツールに見せかける行動はStealthへ、Windowsイベントログを無効化する、EDRを停止する、ファイアウォールを変更する行動はDefense Impairmentへ整理されています。

2026年8月のv19.2では、ShinyHunters、TeamPCPなどのGroupや、CI/CD・ソフトウェアサプライチェーン攻撃に関連するSoftwareが追加されました。

ATT&CKは固定された分類表ではありません。SOCやCSIRTでTechnique IDを管理する場合は、参照したATT&CKのバージョンも記録しておくと、分類変更や廃止Techniqueの影響を確認しやすくなります。

Tactics・Techniques・Sub-techniques・Proceduresの違い

ATT&CKを利用するときは、4つの粒度を分けて理解します。

レベル 意味 例
Tactic 攻撃者の目的 Credential Access
Technique 目的達成のための方法 OS Credential Dumping [T1003]
Sub-technique より具体的な方法 LSASS Memory [T1003.001]
Procedure 実際の攻撃でどのように使われたか 特定グループが特定ツールでLSASSから認証情報を取得した事例

Tacticは「なぜ」、Techniqueは「どのように」に近い概念です。

たとえば、攻撃者が認証情報を窃取したい場合、その目的はCredential Accessです。その実現方法としてOS Credential Dumpingを使い、さらにWindowsのLSASSメモリから認証情報を取得する場合はSub-techniqueのT1003.001まで具体化できます。

Procedureは、Techniqueを実際の攻撃者がどのように実行したかを示す事例です。

MITREの各Techniqueページには、公開された脅威インテリジェンスを基にProcedure Examplesが掲載されています。SOCで検知ルールを作る場合、Technique名だけを見るより、Procedure Examplesを確認した方が、実際にどのコマンド、プロセス、通信、ログが発生するかを把握しやすくなります。

Enterprise ATT&CKの15 Tactics

現在のEnterprise ATT&CKには15のTacticsがあります。

Tactic 攻撃者の目的
Reconnaissance 標的に関する情報を収集する
Resource Development 攻撃に必要なインフラ、アカウント、ツール等を準備する
Initial Access 対象環境へ最初に侵入する
Execution 悪意あるコードやコマンドを実行する
Persistence アクセスを維持する
Privilege Escalation より高い権限を取得する
Stealth 攻撃活動を隠し、正常な動作に見せる
Defense Impairment 防御・監視機能を妨害する
Credential Access ID、パスワード、トークン等を取得する
Discovery システム、アカウント、ネットワーク等を調査する
Lateral Movement 他の端末・サーバーへ移動する
Collection 攻撃目的に必要なデータを集める
Command and Control 侵害環境と攻撃者側インフラで通信する
Exfiltration データを外部へ持ち出す
Impact 暗号化、破壊、業務妨害等を行う

これは「15段階の攻撃手順」ではありません。

CISAのATT&CK Mapping Guideも、ATT&CKを左から右へ進む直線的なモデルとして解釈しないよう説明しています。攻撃者は必要なTacticだけを使い、前後を行き来する場合があります。

たとえば、一度データをExfiltrationした後に、新しいPersistenceを追加することもあります。Initial AccessからImpactまで全てのTacticを通る必要もありません。

MITRE ATT&CKとCyber Kill Chainの違い

MITRE ATT&CKとCyber Kill Chainは、どちらも攻撃活動を整理するために使われますが、粒度と用途が異なります。

項目 MITRE ATT&CK Cyber Kill Chain
主な目的 攻撃者の具体的な行動をTTPとして整理 攻撃の流れを大きな段階で整理
粒度 Technique・Sub-techniqueまで細かい 7段階の大分類
順序 固定されない 攻撃ライフサイクルとして順序性が強い
SOC検知 Technique単位で検知設計しやすい 全体像の把握向き
脅威インテリジェンス Group、Software、Campaignと接続可能 攻撃工程の説明に向く
レッドチーム Technique単位で攻撃を再現可能 シナリオ設計の上位構造として利用可能

SOCやCSIRTが「PowerShellの悪用」「RDPによる横展開」「LSASSからの認証情報窃取」など具体的な行動を分類する場合はATT&CKが適しています。

経営層や非技術部門へ攻撃全体の流れを説明する場合は、より単純な攻撃ライフサイクルの方が伝わりやすい場合があります。

どちらか一方に統一する必要はありません。

SOCでMITRE ATT&CKを使う方法

SOCでは、ATT&CKを「EDRやSIEMのアラートについているタグ」として見るだけでは十分ではありません。

主な使い方は次の5つです。

1. 検知ルールをTechnique単位で整理する

SIEMやEDRの検知ルールへATT&CK IDを付けることで、どの攻撃行動を監視しているかを横断的に確認できます。

たとえば、

  • PowerShellの不審実行
  • LSASSへのアクセス
  • RDPによる横展開
  • Windowsイベントログの削除
  • 大量ファイルの圧縮
  • 外部ストレージへのアップロード

を製品ごとのアラート名ではなく、ATT&CK Techniqueとして整理できます。

複数製品で同じTechniqueを検知している場合もあれば、重要なTechniqueに対応するログ自体を取得していない場合もあります。

2. 必要なログを逆算する

2026年時点のATT&CKでは、Detection StrategiesとData Componentsを使って、Techniqueを検知するために必要なデータを確認できます。

たとえば認証情報窃取を検知したい場合、Windows端末のプロセス情報だけで足りるのか、Active Directory、IdP、クラウド、EDRの情報も必要なのかを整理します。

「SIEMにログを集める」ことを先に考えるのではなく、「自社が警戒するTechniqueを検知するために何が必要か」からログ設計へ戻る使い方です。

3. Threat Huntingの仮説を作る

英国NCSCは2026年1月、重要インフラ向けガイダンスの中で、IOCよりTTPを基にした防御の方が高度な攻撃に対して持続性があると説明しています。

IPアドレス、ドメイン、ファイルハッシュは攻撃者が比較的簡単に変更できます。

一方、

  • 認証情報をどのように窃取するか
  • 内部環境をどのように列挙するか
  • どの正規管理機能で横展開するか
  • どの方法でログを妨害するか

といったTTPは、攻撃者の能力や運用方法そのものに関係するため、短期間で全てを変更することは容易ではありません。

Threat Huntingでは、既知IOCが存在するかではなく、「このTechniqueが自社環境で実行された形跡はないか」という仮説からログを調べられます。

4. インシデントの攻撃経路を整理する

インシデント対応時には、確認された行動をATT&CKへマッピングします。

たとえば、

  1. VPNアカウントで侵入
  2. ADを調査
  3. 認証情報を取得
  4. RDPで別サーバーへ移動
  5. データを圧縮
  6. クラウドストレージへ送信
  7. ファイルを暗号化

という事象を、製品アラートの羅列ではなくTactic・Technique単位で整理できます。

これにより、「どこで検知できたか」「どこはログがなく確認できないか」「どの段階なら攻撃を止められたか」を振り返りやすくなります。

5. レッドチーム・パープルチームの評価に使う

攻撃側がTechniqueを実行し、防御側が検知できるかを確認します。

たとえば、RDPによるLateral Movementを想定するなら、単にRDP通信が通るかではなく、

  • 認証ログが記録されるか
  • 通常と異なる端末間通信を検知できるか
  • SOCへアラートが届くか
  • アナリストがLateral Movementと判断できるか
  • 対象アカウントや端末を隔離できるか

まで確認します。

ATT&CKは、攻撃側と防御側が同じ行動を同じIDで扱える点に価値があります。

CISAはATT&CKを脅威情報から防御へ変換する共通言語として利用

米国CISAは「Best Practices for MITRE ATT&CK Mapping」で、ATT&CKの主な利用例として、防御上のギャップの特定、セキュリティ製品の能力評価、検知ルールの整理、Threat Hunting、レッドチーム活動、緩和策が機能するかの検証を挙げています。

同ガイドでは、脅威情報をATT&CKへマッピングする際に、記載されていないTechniqueを推測で補わないよう求めています。

たとえば「HTTPでC2通信を行った」という情報があっても、通信ポートが記載されていなければ「80番ポートを使った」と推測して別Techniqueへマッピングしません。

Sub-techniqueまで判断できる根拠がなければ、親Techniqueにとどめます。

このルールは、CSIRTのインシデント報告でも利用できます。

「おそらく横展開した」「認証情報を盗んだはず」といった推測をATT&CKのTechniqueで確定情報のように表示すると、後続の検知設計や経営報告にも誤りが伝播します。

UK NCSCはTTPベースの防御をIOC中心より持続的と評価

英国NCSCは2026年1月に公開した重要インフラ向けガイドで、深刻なサイバー脅威への備えとして、攻撃者のTactics、Techniques、Proceduresを把握することを推奨しています。

NCSCは、IOCとTTPを次のように整理しています。

IOCはIPアドレス、ドメイン、ファイルハッシュなどで、導入しやすい一方、攻撃者が変更しやすい情報です。

TTPは攻撃者の行動、方法、パターンを表し、攻撃キャンペーンが変わっても再利用される可能性があります。

同ガイドでは、MITRE ATT&CKのようなTTPナレッジベースを使い、重要なTechniqueに対するControlsやMitigationsを優先するよう案内しています。

またNCSCは、オンラインサービスの設計時にも、脅威モデリングとMITRE ATT&CKのような既知TTPのナレッジベースを組み合わせる方法を紹介しています。

つまりATT&CKはSOCだけのツールではなく、システム設計やリスク評価にも利用できます。

US・UK・イスラエルの共同注意喚起でもATT&CKを利用

米国CISA、FBI、NSA、EPA、英国NCSC、イスラエル国家サイバー局(INCD)などは、イラン革命防衛隊(IRGC)関連アクターによるPLCを狙った攻撃について共同注意喚起を公開しています。

この注意喚起では、実際に観測された攻撃行動をMITRE ATT&CKのTactics・Techniquesへマッピングしています。

この使い方の利点は、各国の組織が異なる製品を利用していても、攻撃行動を共通のTechnique IDで共有できることです。

「特定のマルウェア名を検知する」という情報だけでは、そのマルウェアが変更された場合に利用価値が低下します。

一方、「Valid Accounts」「Brute Force」「External Remote Services」といったTechniqueで共有すれば、各企業が自社のVPN、IdP、PLC、ログ基盤に合わせて検知方法を検討できます。

イスラエルのCheck Point Researchも、2026年に公開したHandala Hackの調査でATT&CKを利用しています。同調査では、VPNアクセス、Valid Accounts、Brute Force、LSASSからのCredential Dumping、RDPによるLateral Movement、PowerShell、データ破壊などをTechnique単位で整理しています。

サイト内事例:Volt TyphoonをATT&CKで見ると「マルウェア名」以外の検知軸が見える

セキュリティ対策Labでは、JPCERT/CCが注意喚起したVolt Typhoonと共通点を持つOperation Blotlessを取り上げています。

同記事では、次のような特徴を整理しています。

  • インターネットに接続されたアプライアンスを侵入経路として利用
  • NTDSファイルを窃取
  • WebサーバーへWeb shellを設置
  • 正規機能を悪用するLiving off the Land
  • 痕跡が残る箇所を限定する

ATT&CKを使うと、「Volt Typhoonを検知する」という製品名・攻撃者名ベースの発想から、「攻撃者が利用する行動を検知する」という発想へ切り替えられます。

たとえばNTDSファイルから認証情報を取得する行動は、OS Credential Dumping: NTDS [T1003.003]として整理できます。

Web shellによる永続化は、Server Software Component: Web Shell [T1505.003]に該当する場合があります。

一方、「Living off the Land」自体に1つのATT&CK IDが割り当てられているわけではありません。

PowerShell、WMI、RDP、Windows標準コマンドなど、それぞれの正規機能をどの目的でどのように利用したかを個別のTechniqueへ分解します。

この違いはSOCの検知設計に影響します。

「未知マルウェアを検知する」だけではなく、

  • 正規ツールが通常とは異なる親プロセスから起動していないか
  • 管理者が通常利用しない端末間でRDPが発生していないか
  • NTDSへのアクセスが発生していないか
  • Webサーバーのプロセスから不審な子プロセスが起動していないか

といった行動へ監視対象を広げられます。

サイト内事例:Scattered Spider系の攻撃は「フィッシングメール」だけでは分類できない

セキュリティ対策Labでは、Scattered Spiderの主要メンバーによるSMSフィッシング等の手口や、Microsoft 365利用者を狙ったビッシングとパスキー登録の悪用を取り上げています。

後者では、攻撃者が従業員へ電話をかけ、Microsoft Entra IDの新しいパスキー登録が必要だと信じ込ませ、偽サイトへ誘導する手口が確認されています。

現在のEnterprise ATT&CKには、Phishing [T1566]のSub-techniqueとしてSpearphishing Voiceが含まれています。

ここで注意したいのは、「電話を使ったからSpearphishing Voiceだけ」と分類して終わらないことです。

その後に、認証情報を取得する、正規アカウントへログインする、MFAや認証方法を操作する、新たな認証方法を登録する、クラウド内のデータを探索するといった行動が確認されれば、それぞれ別のTechniqueとしてマッピングします。

1件のインシデントに複数のTactics・Techniquesが存在するのが通常です。

2026年8月のATT&CK v19.2ではShinyHuntersもGroupとして追加されました。MITREは同Groupについて、認証情報や個人情報を窃取し、販売・恐喝する活動に加え、The ComやScattered Lapsus Shiny Huntersなどとの関連が公開情報で報告されていると整理しています。

ATT&CKが継続更新される理由の一つは、こうした攻撃者の活動と技術が変化するためです。

ATT&CK Navigatorで何ができるか

ATT&CK Navigatorは、Tactics・Techniquesを色分けして可視化するためのツールです。

SOCやCSIRTでは、次の用途に使えます。

  • 自社が警戒する攻撃グループのTechniqueを可視化
  • 複数の攻撃グループで共通するTechniqueを比較
  • SIEM・EDRで検知できるTechniqueを表示
  • ログ不足で検知できないTechniqueを整理
  • レッドチームで実施したTechniqueを記録
  • インシデントで確認したTechniqueを時系列とは別軸で整理

ただし、緑色に塗ったTechniqueの数を「セキュリティ成熟度」として扱わない方がよいです。

MITRE自身も「100% coverageを目指さない」と説明しています。

1つのTechniqueには複数の実行方法があります。

たとえば「Scheduled Taskを検知できるルールが1本ある」だけで、Scheduled Task/Jobに含まれる全ての攻撃方法を検知できるとは限りません。

MITREのCenter for Threat-Informed Defenseも2026年9月、単純なヒートマップでは検知Coverageの深さや品質が分からないとして、Techniqueの実装パターンとDetection Qualityを分けて評価する方法を公開しています。

MITRE ATT&CKを使う手順

従業員600人以上の企業でATT&CKを実務へ導入する場合、最初から全Techniqueを棚卸しする必要はありません。

1. 自社が想定する脅威を決める

まず、次のような条件から優先する脅威を決めます。

  • 自社業界を狙う攻撃グループ
  • 過去に自社で発生したインシデント
  • 同業他社の被害事例
  • ランサムウェア
  • クラウドアカウント侵害
  • サプライチェーン攻撃
  • 内部不正
  • 国家支援型攻撃

CISAやNCSC、JPCERT/CC、セキュリティベンダーの脅威レポートから、自社に関係するTTPを選びます。

2. 公開された攻撃情報をATT&CKへマッピングする

最初から生ログをTechniqueへ割り当てるより、攻撃手順が整理されたレポートを使う方が導入しやすくなります。

CISAも、ATT&CKマッピングに慣れるまでは、技術的な背景が整理された完成済みレポートから始める方法を推奨しています。

マッピング時は、

  1. 攻撃者が何を達成しようとしたか
  2. そのために何を実行したか
  3. Techniqueの定義と一致するか
  4. Sub-techniqueまで特定できる根拠があるか

の順で確認します。

3. Techniqueごとに必要なログを確認する

対象TTPが決まったら、実際に検知できるか確認します。

たとえば、Windowsイベントログ、Sysmon、EDR、Active Directory、Entra ID、Microsoft 365、VPN、ファイアウォール、DNS、Proxy、AWS CloudTrail、Azure Activity Log、Google Cloud Audit Logs、SaaS監査ログなどが必要になります。

ログが存在しないTechniqueは、SIEMルールを作っても検知できません。

4. 検知ルールと対応手順を作る

アラートを出すだけでなく、そのTechniqueを確認した際にSOCが何を調査するか決めます。

たとえばValid Accountsの異常利用なら、接続元IP、利用端末、MFA履歴、セッション、権限変更、同時刻のメール・クラウド操作、他アカウントへの波及などを確認します。

Technique IDをアラートへ付与すると、調査手順やプレイブックも紐付けやすくなります。

5. レッド・パープルチームで実際に確認する

「ログが存在する」「ルールがある」だけではなく、実際にその行動を実施した際に検知されるか確認します。

確認するのは、ログが生成されたか、SIEMへ届いたか、検知ルールが発火したか、SOCが調査したか、正しいTechniqueとして判断できたか、端末隔離やアカウント停止まで実行できたかです。

この工程で見つかったギャップをログ設計や検知ルールへ戻します。

ATT&CKを使う際の5つの注意点

ATT&CKを100%埋めようとしない

MITREは、組織ごとに関係する脅威が異なるため、全Techniqueの100% Coverageを目標にしないよう案内しています。

自社に関係する脅威アクター、攻撃経路、重要資産から優先順位を付けます。

1つの検知ルールでTechnique全体を「対応済み」にしない

同じTechniqueでも複数の実装方法があります。

1つのPowerShell検知ルールがあるからCommand and Scripting Interpreter全体を検知できる、とは判断しません。

根拠がないTechniqueを推測で付けない

CISAは、技術的根拠がないTechniqueを推測でマッピングしないよう案内しています。

インシデント報告で「認証情報を使って侵入した」と分かっても、パスワードスプレー、Credential Stuffing、フィッシングのどれで認証情報を取得したか不明なら、その部分を確定しません。

ATT&CKだけで攻撃者を特定しない

複数の攻撃グループが同じTechniqueを使います。

PowerShell、RDP、Mimikatz、VPN、Valid Accountsなど一般的なTechniqueだけを根拠に、特定グループへ帰属させることはできません。

帰属判断には、インフラ、マルウェア、標的、時間帯、言語、攻撃目的、過去キャンペーンとの関連など別の情報が必要です。

ATT&CKのバージョンを確認する

2026年のv19ではDefense Evasionが分割されました。

古いSIEMルール、脅威レポート、EDR製品では旧Tactic名が残っている場合があります。

Technique IDを資産管理やSOC指標に利用している場合は、ATT&CKの更新時に廃止、変更、再分類を確認します。

従業員600人以上の企業が確認したいポイント

ATT&CKをSOC、CSIRT、情報システム部門で利用する場合は、次を確認すると運用状況を整理できます。

  • 現在参照しているATT&CKのバージョンを把握しているか
  • 自社を狙う脅威アクターや主要攻撃シナリオを選定しているか
  • 脅威インテリジェンスをTechnique IDで整理しているか
  • SIEM・EDRの検知ルールにATT&CK IDを付与しているか
  • Techniqueごとに必要なログを把握しているか
  • WindowsだけでなくIdP、SaaS、IaaS、ネットワーク機器のログも対象にしているか
  • 重要Techniqueでログが取得できていない箇所を把握しているか
  • 「検知ルールが1つある」だけでCoverage済みとしていないか
  • CISA・NCSC等の最新TTPを自社の検知へ反映する手順があるか
  • インシデント調査結果をATT&CKへマッピングしているか
  • マッピング時に確認済み事実と推測を分けているか
  • レッドチーム・パープルチームでTechnique単位の検証を行っているか
  • ATT&CK NavigatorをSOCのKPIだけに使っていないか
  • ATT&CK更新時に廃止・変更されたTechniqueを確認しているか
  • GroupやTechniqueだけを根拠に攻撃者帰属を判断していないか

ATT&CKの導入目的は、マトリクスを埋めることではありません。

自社に関係する攻撃者の行動を共通言語で整理し、その行動を検知するログがあるか、アラートを判断できるか、封じ込めまで実行できるかを確認するために使います。

SOCでは検知ルール、CSIRTではインシデント分析、レッドチームでは攻撃シナリオ、情報システム部門ではログ・ID・ネットワーク設計というように、部門ごとにATT&CKを使う目的を決めると運用しやすくなります。

出典