# GuardDuty Extended Threat Detection と攻撃シーケンス finding を徹底解説：弱いシグナル相関・24時間窓・Critical な多段攻撃を読み解いて対応する

> GuardDuty Extended Threat Detection（ETD）と攻撃シーケンス（AttackSequence）findingの徹底解説。弱いシグナルの相関モデル、24時間ローリングウィンドウ、IAM/S3/EKS/ECS/EC2の5つの攻撃シーケンス型、なぜ全て Critical(9.0〜10.0)なのか、保護プランで広がる相関範囲、サンプル生成での検証、Suppression Ruleがアーカイブ済みを無視する罠まで——credential侵害→権限昇格→S3持ち出しの実例で線として読み解きます。

- 公開日: 2026-06-27
- 著者: 友田 陽大
- タグ: セキュリティ, AWS, GuardDuty, 脅威検知, アーキテクチャ設計
- URL: https://tomodahinata.com/blog/aws-guardduty-extended-threat-detection-attack-sequence-findings-guide
- カテゴリ: Amazon GuardDuty 本番運用
- 総合ガイド: https://tomodahinata.com/blog/aws-guardduty-threat-detection-multi-account-terraform-eventbridge-guide

## 要点

- ETD は追加費用ゼロ・自動有効。API 操作や既存 finding を『シグナル』、単体では脅威に見えないものを『弱いシグナル』として、1アカウント内・24時間のローリングウィンドウで相関し、多段攻撃を1つの攻撃シーケンス finding に束ねる
- 攻撃シーケンスは5型：IAM/CompromisedCredentials・S3/CompromisedData・EKS/CompromisedCluster・ECS/CompromisedCluster・EC2/CompromisedInstanceGroup。その性質上すべて必ず Critical(9.0〜10.0)
- 相関できる範囲は保護プランで広がる。S3 持ち出しには S3 Protection、EKS には EKS Protection か Runtime Monitoring、ECS には Runtime Monitoring(Fargate/EC2、Managed EC2 は非対応)、EC2 は Runtime Monitoring で強化
- ETD はアーカイブ済み finding（Suppression Rule で自動アーカイブされたものを含む）を相関の材料にしない。広すぎる抑制は攻撃シーケンスを丸ごと不可視化する——抑制ルールの監査が必須
- 本番投入前に create-sample-findings で攻撃シーケンス型のサンプルを発火させ、EventBridge → 対応パイプラインを検証する。サンプルは [SAMPLE] 接頭辞と "sample": true で見分ける

---

「GuardDuty の finding、毎日いくつも上がるんですけど、どれが本当にヤバいやつなんですか？」——AWS のセキュリティ運用を相談される場で、保護プランの有効化が一段落した次に必ず出てくる問いです。

これは正しい問いです。GuardDuty を有効化して保護プランを足すと、`Recon:EC2/Portscan` も `UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS` も `CryptoCurrency:EC2/BitcoinTool.B!DNS` も、それぞれ独立した finding として上がってきます。けれど**本当に怖い攻撃は、たいてい1個の finding には収まりません**。認証情報を盗まれ、権限を昇格され、永続化され、最後に S3 からデータを抜かれる——この一連は、点で見れば「中くらいの不審な操作」の連なりにしか見えず、人間のアナリストが手作業で「これは一つの攻撃だ」と束ねるまで、**攻撃の全体像は誰にも見えません**。

その「束ねる」を GuardDuty 自身がやってくれるのが、**Extended Threat Detection（ETD）** と、その産物である **攻撃シーケンス（attack sequence）finding** です。この記事は、ETD が**何を・どう相関し**、攻撃シーケンス finding を**どう読み解き・どう優先順位づけして・どう対応するか**を、公式ドキュメントに厳密に基づいて深掘りします。GuardDuty 全体の設計（保護プラン選定・組織統制・EventBridge 自動対応）は[GuardDuty 本番設計のピラー記事](/blog/aws-guardduty-threat-detection-multi-account-terraform-eventbridge-guide)で扱っています。本記事はその ETD 部分を、ピラーの簡潔な説明から大きく掘り下げる**スポーク**です。

> **この記事のルール**：finding 型名・重大度・相関の挙動・保護プランとの関係は **AWS 公式ドキュメント（2026年6月時点）** に基づきます。攻撃シーケンスの対応保護プランや型は改定されるため、本番投入前に必ず公式の最新情報を確認してください。**GuardDuty は検知（detection）サービスであり、攻撃シーケンスを検知しても自動的に止めてはくれません**——多層防御の一層です。そしてもう一つの鉄則——**攻撃シーケンスへの自動対応も「冪等・スコープを絞る・取り消せる」を満たすものから始め、Critical だからといって破壊的操作を無条件に自動化しない**ことです。

---

## 0. メンタルモデル：攻撃シーケンスは「点の finding を線に束ねた、必ず Critical の上位 finding」

設計を始める前に、ETD と攻撃シーケンスが何かを一行で固定します。

> **Extended Threat Detection ＝ 個別の finding と API 操作（＝シグナル）を、1アカウント内・24時間のローリングウィンドウで相関し、『多段攻撃の連鎖』を1つの攻撃シーケンス finding（必ず Critical 9.0〜10.0）に束ねる、追加費用ゼロ・自動有効の上位レイヤー。**

ここから3つの帰結が出ます。これが本記事のトリアージ設計すべての土台です。

1. **攻撃シーケンスは『最優先トリガー』として扱える。** 攻撃シーケンス finding は、その性質上**すべて Critical（9.0〜10.0）** に分類されます。つまり「severity が数値で 9.0 以上」かつ「型が `AttackSequence:*`」という条件は、**人間の判断を待たずに最優先エスカレーションへ振り分けてよい、数少ない高信頼シグナル**です。点の finding を一つずつ severity で切るよりも、ETD が「これは一連の攻撃だ」と判定した束に最初に反応するほうが、文脈を取りこぼしません。

2. **ETD は『材料となるシグナル』が見えていなければ束ねられない。** ETD は基盤データソースだけでも動きますが、相関できる範囲は**有効化した保護プランに比例して広がります**。S3 の持ち出しを束ねるには S3 Protection が、EKS の侵害を束ねるには EKS Protection か Runtime Monitoring が要ります。そして決定的なのが——**ETD はアーカイブされた finding を相関の材料にしません**。Suppression Rule で「ノイズだ」と消したシグナルは、本来束ねるはずだった攻撃シーケンスごと不可視化されます（7章で詳述）。

3. **攻撃シーケンスも『普通の finding』として EventBridge に流れる。** 特別な配信チャネルがあるわけではありません。攻撃シーケンス finding も、他の finding と同じように EventBridge に送られ、設定すれば S3 へエクスポートもされます。だから[ピラー記事の EventBridge 自動対応](/blog/aws-guardduty-threat-detection-multi-account-terraform-eventbridge-guide)の配管にそのまま乗せられます——**乗せ方さえ設計すれば**。

この3点を押さえると、ETD の運用は **「①どんな攻撃シーケンスが束ねられるか（型と保護プランの対応）→ ②束ねられた finding をどう読むか（指標・タイムライン・MITRE）→ ③どう検証し・どう対応するか（サンプル発火・トリアージ・封じ込め）」** の3つの設計に分解できます。順に作ります。

---

## 1. 相関モデル：シグナル・弱いシグナル・24時間ローリングウィンドウ

ETD の中核は「相関（correlation）」です。まずその材料と窓を、公式の定義どおりに固定します。

### 1.1 シグナルと「弱いシグナル」

GuardDuty は、相関の材料となるイベントを **シグナル（Signals）** と呼びます。シグナルには2種類あります。

| シグナルの種類 | 中身 | 例 |
| --- | --- | --- |
| **既存の GuardDuty finding** | 個別の検知ロジックが既に発火させた finding | `UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS` |
| **弱いシグナル（weak signals）** | 単体では「明確な脅威」に見えない API 操作などのイベント | S3 の API への IAM 権限探索、バケットポリシーを緩める制御プレーン操作 |

公式の表現を借りれば、GuardDuty は**個別の API アクティビティを「弱いシグナル（weak signals）」として扱います**——それ単体では脅威に見えないからです。ETD の価値は、この**「単体では無害に見える弱いシグナル」と「既に上がっている finding」を、時系列のパターンとして align させる**ところにあります。たとえば次の連鎖は、点で見れば全部「よくある操作」ですが、線で見ると明確な攻撃です。

- `s3:ListBuckets` / `s3:GetBucketPolicy` を異常な主体が連発（権限探索 ＝ 弱いシグナル）
- 続いて `s3:PutBucketPolicy` でバケットポリシーを緩める（制御プレーン変更 ＝ 弱いシグナル）
- その後、緩めたバケットから大量にオブジェクトを取得（データ持ち出し ＝ S3 Protection があれば finding 化）

公式が明示する重要な事実——**基盤データソースだけでも、ETD は「S3 API への IAM 権限探索 → バケットポリシーをより許可的にする制御プレーン変更」という連鎖を検知できます**。S3 Protection を足すと、そこに「実際のデータ持ち出し」まで相関の射程に入ります。

### 1.2 24時間のローリングウィンドウ

ETD は **進行中または直近（24時間のローリングタイムウィンドウ内）の攻撃挙動**を相関します。「ローリング」が肝で、固定の0時起算ではなく、**常に直近24時間を見続ける**窓です。

この24時間という設計には、運用上の含意が2つあります。

1. **攻撃は数分では完結しない、を前提にしている。** 偵察→侵入→昇格→持ち出しは、たいてい分〜時間オーダーで進みます。1時間や6時間の窓では、ゆっくり進む攻撃（low-and-slow）を取りこぼします。24時間はそのバランス点です。
2. **finding の遅延と窓は別物。** finding の「再発の配信頻度」は `finding_publishing_frequency`（デフォルト6時間）に従いますが、ETD が相関に使う窓は24時間です。**自動対応の反応を速くしたいなら、ピラー記事のとおり `finding_publishing_frequency = FIFTEEN_MINUTES` を推奨**します——攻撃シーケンスの「続報」が最大6時間遅れると、封じ込めが後手に回るからです。

### 1.3 なぜ「相関」が点の検知より強いのか

ひとことで言えば、**誤検知の文脈フィルタが効く**からです。個別の finding は、単体だと「正規の運用かもしれない」grey zone を多く含みます。ETD は**「複数の疑わしい挙動が同じ主体・同じリソース群で連鎖した」という事実そのものを確信度（confidence）の根拠**にします。公式も、攻撃シーケンスについて「同じ認証情報で複数の疑わしく異常な攻撃挙動が観測され、**認証情報が悪用されているという確信度が高まった**」結果として finding を出す、と説明しています。だから攻撃シーケンスは Critical なのです——確信度が構造的に高い。

---

## 2. 攻撃シーケンス finding の全型：5種類と、それぞれが束ねる脅威シナリオ

公式ドキュメントが定義する攻撃シーケンス finding は、現在 **5型**です。型名は **`AttackSequence:ResourceType/ThreatName`** の形で、リソース種別とシナリオがエンコードされています。**すべて Default severity が Critical** です。

| finding 型 | 束ねる脅威シナリオ | 検知に使うデータソース（公式） |
| --- | --- | --- |
| **`AttackSequence:IAM/CompromisedCredentials`** | 侵害された AWS 認証情報による一連の API リクエスト（昇格・永続化・横展開） | CloudTrail 管理イベント（基盤のみで成立） |
| **`AttackSequence:S3/CompromisedData`** | 侵害された認証情報による S3 データの持ち出し／破壊の試み（ランサムウェアの一部にもなり得る） | S3 の CloudTrail データイベント ＋ CloudTrail 管理イベント |
| **`AttackSequence:EKS/CompromisedCluster`** | EKS クラスタの侵害（脆弱コンテナの悪用→特権トークン取得→secrets/AWS リソースへのアクセス） | EKS 監査ログ、EKS 向け Runtime Monitoring、EC2 向けマルウェア検知、S3 データイベント、CloudTrail 管理イベント、VPC Flow Logs、DNS クエリログ |
| **`AttackSequence:ECS/CompromisedCluster`** | ECS クラスタの侵害（悪性プロセス・悪性エンドポイント通信・暗号資産マイニング） | Fargate／EC2 向け Runtime Monitoring、EC2 向けマルウェア検知 |
| **`AttackSequence:EC2/CompromisedInstanceGroup`** | 共通属性を持つ EC2 インスタンス群の侵害（悪性プロセス・C&C 通信・マイニング・インスタンス認証情報の異常利用） | EC2 向け Runtime Monitoring、EC2 向けマルウェア検知、VPC Flow Logs、DNS クエリログ |

> **ピラー記事の brief との差分（読者への正直な注記）**：GuardDuty 本番設計のピラー記事では `AttackSequence:S3/...` のように略記していましたが、**公式の正確な型名は `AttackSequence:S3/CompromisedData`** です。また、ピラーで触れていなかった **`AttackSequence:IAM/CompromisedCredentials`（基盤データソースだけで成立する、認証情報悪用の攻撃シーケンス）** が存在します。型名で自動対応をルーティングする際は、この正確な5型を許可リストの根拠にしてください。

### 2.1 EC2 の「インスタンスグループ」とは何か

`AttackSequence:EC2/CompromisedInstanceGroup` だけ「グループ」という概念が入るので補足します。公式によれば、ETD は**個々のインスタンス、または共通の属性を共有するインスタンス群**を攻撃シーケンスの対象にします。共通属性とは：

- **Auto Scaling group**
- **IAM インスタンスプロファイル（ロール）**
- **起動テンプレート（launch template）**
- **CloudFormation スタック**
- **AMI**
- **VPC ID**

なぜグルーピングするのか——**IaC で管理された同一構成のフリートは、1台が侵害されれば他も同様に侵害されている可能性が高い**からです。攻撃シーケンスがこれを「グループ」として1 finding に束ねることで、「100台のうち1台ずつに100個の finding が散らばる」のではなく、「この ASG が侵害された」という1つの意思決定単位を受け取れます。トリアージと封じ込めのスコープが、最初から正しい粒度で切られているわけです。

### 2.2 ECS の重要な制約

`AttackSequence:ECS/CompromisedCluster` には、見落としやすい前提があります。公式が **Important** として明記しているとおり——

- ECS の攻撃シーケンスには **Runtime Monitoring（Fargate または EC2）が必須**。
- **ECS on Managed EC2 instances（マネージド型 EC2 上の ECS）は非対応**。

ECS を Fargate で動かしているなら Fargate 向け Runtime Monitoring、EC2 launch type なら EC2 向け Runtime Monitoring が要ります。「ECS を使っているから自動的に ECS 攻撃シーケンスが効く」わけではない——**ランタイムの可視性を入れて初めて束ねられる**点に注意します。詳細は[Runtime Monitoring のスポーク記事](/blog/aws-guardduty-runtime-monitoring-eks-ecs-fargate-ec2-guide)で扱います。

---

## 3. 保護プランと相関範囲の対応表：何を有効化すると、どの攻撃シーケンスが「束ねられる」ようになるか

ここが ETD の設計上、最も実務的な判断ポイントです。**ETD 自体は無償・自動ですが、束ねられる攻撃シーケンスの種類は、有効化した保護プランで決まります**。公式の記述を、有効化判断に使える形に再構成します。

| 攻撃シーケンス | 最低限必要なもの | 推奨（カバレッジ最大化） | 有効化しないと何が起きるか |
| --- | --- | --- | --- |
| **IAM/CompromisedCredentials** | 基盤データソースのみ（CloudTrail 管理イベント） | — | GuardDuty 有効化＝即動く。追加プラン不要 |
| **S3/CompromisedData** | **S3 Protection** | S3 Protection | S3 Protection 無しでは「バケットが過度に許可的になった」までは検知できるが、その後の**データ持ち出し**を相関できない |
| **EKS/CompromisedCluster** | **EKS Protection** または **Runtime Monitoring（EKS アドオン）** | 両方を有効化 | どちらも無しでは EKS 個別 finding が出ず、EKS の攻撃シーケンスを束ねられない |
| **ECS/CompromisedCluster** | **Runtime Monitoring（Fargate または EC2）** | Runtime Monitoring | Runtime Monitoring 無しでは ECS の攻撃シーケンスは検知不可（Managed EC2 上の ECS は非対応） |
| **EC2/CompromisedInstanceGroup** | 基盤データソース（CloudTrail＋ネットワーク） | **＋ Runtime Monitoring** で強化 | 基盤だけでも一部成立。Runtime Monitoring を足すとプロセス挙動・システムコールまで相関に入る |

この表から導ける設計上の含意は3つです。

1. **IAM/CompromisedCredentials は『タダで最強』。** 基盤データソース（GuardDuty 有効化で即オン）だけで動きます。認証情報の悪用は最も普遍的な攻撃経路なので、**GuardDuty を有効化した瞬間に、最も価値の高い攻撃シーケンス検知が1つ手に入っている**ことになります。
2. **S3 Protection を有効化する理由は『個別検知＋ETD 相関の両方』。** ピラー記事でも触れたとおり、S3 Protection は安価で効果が大きい。**ETD の S3/CompromisedData を解禁する**という観点でも、機密データを扱うアカウントではほぼ常に推奨です。
3. **EKS と ETD は『両方有効化』が公式推奨。** EKS Protection（監査ログ＝制御プレーン）と Runtime Monitoring（コンテナ内＝データプレーン）は**見ている層が違う**ため、片方だけだと攻撃の半分しか見えません。公式は「両方を有効化することで、特権コンテナの異常なデプロイ（EKS Protection で検知）→ その中での永続化・マイニング・リバースシェル（Runtime Monitoring で検知）という連鎖を、1つの Critical finding として表現できる」と説明しています。

> **コスト視点の補足**：Runtime Monitoring は vCPU 課金で最も高くなりやすい保護プランです（料金の詳細はピラー記事の8章）。だからこそ「全部入れる」のではなく、**①基盤で IAM 攻撃シーケンスは無料で確保 → ②S3 Protection で S3 攻撃シーケンスを安価に追加 → ③EKS/ECS/EC2 のランタイム相関は『その資産が本番にある時だけ』Runtime Monitoring で足す**、という段階導入が費用対効果で勝ります。

---

## 4. 攻撃シーケンス finding の「読み方」：個別 finding と何が違うのか

攻撃シーケンス finding は、個別 finding と同じ EventBridge / 同じ Findings ページに流れますが、**finding の中身（details）が決定的に違います**。個別 finding が「1つの疑わしい事象」を記述するのに対し、攻撃シーケンス finding は**攻撃全体を物語る構造化されたレポート**です。トリアージのために、何が入っているかを押さえます。

| 攻撃シーケンス finding に含まれる要素 | 何を伝えるか | トリアージでの使いどころ |
| --- | --- | --- |
| **Signals（シグナルのタイムライン）** | 束ねられた個別シグナル（finding＋弱いシグナル）が、いつ・どの順で起きたか | 攻撃の進行段階を時系列で把握。どこまで進んだか（持ち出しまで到達したか）を判断 |
| **Indicators（指標）** | 攻撃を裏づける具体的な根拠（評判の悪い IP / ドメイン、異常な API シーケンス、ユーザー設定 等） | 「なぜこれが攻撃だと判定されたか」の確信度の根拠。誤検知判断に使う |
| **MITRE ATT&CK マッピング** | 各シグナルが ATT&CK のどの戦術・技術に対応するか | 攻撃の意図（Discovery / PrivilegeEscalation / Exfiltration …）を共通言語で把握 |
| **Actors / Endpoints（主体と通信先）** | 攻撃に関与した主体（IAM 主体・IP）と、通信した外部エンドポイント | 封じ込めの対象を特定（鍵失効すべき主体、遮断すべき IP/ドメイン） |
| **影響を受けたリソース** | 攻撃シーケンスが触れた AWS リソース（S3 バケット、EC2 群、EKS クラスタ 等） | 封じ込め・調査のスコープを決める |

公式は、攻撃シーケンスの相関根拠として「**IP レピュテーション、API シーケンス、ユーザー設定、影響を受けた可能性のあるリソース**」といった複数の factor を使う、と明示しています。つまり攻撃シーケンス finding を読むときは、**「severity が Critical だから」だけで動くのではなく、Signals タイムラインと Indicators を見て『攻撃がどこまで進んだか』を判断する**——これが点の finding にはない、線の finding ならではの読み方です。

---

## 5. ハンズオン：攻撃シーケンスのサンプルを発火させ、対応経路を検証する

「検証経路を先に作る」は本サイトの一貫した原則です。攻撃シーケンスの自動対応を組む前に、**実際の攻撃を待たずに、サンプル finding で EventBridge → 対応パイプラインが想定どおり動くかを確認**します。

公式の `CreateSampleFindings` は、**攻撃シーケンス型を含む各 finding 型のサンプルを生成**できます。コンソールの「Generate sample findings」は**全型を1つずつ**生成し（攻撃シーケンスも含まれる）、CLI/API は**特定の型だけ**を狙って発火できます。

```bash
# 攻撃シーケンス型のサンプルを発火させ、対応パイプラインを検証する。
# detector-id は Settings ページ、または list-detectors で取得。
DETECTOR_ID="$(aws guardduty list-detectors --query 'DetectorIds[0]' --output text)"

# 5型の攻撃シーケンスをまとめて発火（EventBridge ルール / 自動対応の網羅検証用）。
aws guardduty create-sample-findings \
  --detector-id "$DETECTOR_ID" \
  --finding-types \
    "AttackSequence:IAM/CompromisedCredentials" \
    "AttackSequence:S3/CompromisedData" \
    "AttackSequence:EKS/CompromisedCluster" \
    "AttackSequence:ECS/CompromisedCluster" \
    "AttackSequence:EC2/CompromisedInstanceGroup"
```

> **サンプルの見分け方（誤対応を防ぐ重要点）**：サンプル finding は、コンソール上で**タイトルが必ず `[SAMPLE]` で始まり**、finding JSON の `additionalInfo` セクションに **`"sample": true`** を持ちます。自動対応 Lambda では、この `sample` フラグを見て**サンプルに対しては破壊的アクションをスキップ**するのが安全です（検証はしたいが、サンプルで本番 EC2 を隔離したくはない）。サンプルは placeholder 値で近似されたもので、実 finding とは見た目が異なる点も理解しておきます。

EventBridge で攻撃シーケンスだけを拾うパターンは、型の接頭辞でフィルタするのが簡潔です。

```json
{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {
    "type": [{ "prefix": "AttackSequence:" }]
  }
}
```

サンプル受信時に「`sample` フラグを見て分岐する」検証用ハンドラの骨子は次のとおりです。意思決定（純粋ロジック）と副作用（API 呼び出し）を分け、サンプルでも経路全体を安全に流せるようにします。

```python
"""攻撃シーケンス finding を受けて『最優先トリアージ』へ振り分ける検証用ハンドラ。

設計原則:
  - サンプル安全: additionalInfo.sample が真なら破壊的アクションを必ずスキップ。
  - 冪等: EventBridge は at-least-once。finding id でガードし副作用は1回分。
  - 取り消し可能: ここでやるのは『最優先チケット化 + 通知』まで。隔離・鍵失効は人間の承認後。
"""
from __future__ import annotations

from typing import Any, Final

# 公式が定義する攻撃シーケンスの5型（型名でのルーティング根拠）。
ATTACK_SEQUENCE_TYPES: Final[frozenset[str]] = frozenset(
    {
        "AttackSequence:IAM/CompromisedCredentials",
        "AttackSequence:S3/CompromisedData",
        "AttackSequence:EKS/CompromisedCluster",
        "AttackSequence:ECS/CompromisedCluster",
        "AttackSequence:EC2/CompromisedInstanceGroup",
    }
)


def classify(detail: dict[str, Any]) -> dict[str, Any]:
    """副作用を持たない純関数。サンプル finding の JSON でユニットテスト可能。"""
    finding_type: str = detail["type"]
    severity: float = float(detail["severity"])
    is_sample: bool = bool(
        detail.get("service", {}).get("additionalInfo", {}).get("sample", False)
    )

    is_attack_sequence = finding_type in ATTACK_SEQUENCE_TYPES
    # 攻撃シーケンスは必ず Critical。型と severity の両方で二重に確認する。
    is_critical = severity >= 9.0

    return {
        "finding_id": detail["id"],
        "type": finding_type,
        "is_attack_sequence": is_attack_sequence,
        "is_critical": is_critical,
        "is_sample": is_sample,
        # サンプルは『最優先チケット化』までは流すが、封じ込めは絶対に発火させない。
        "allow_containment": is_attack_sequence and is_critical and not is_sample,
    }
```

純粋ロジック（`classify`）に切り出してあるので、サンプル finding の JSON を入力に**ユニットテストで「5型すべてが正しく最優先と判定されるか」「サンプルでは封じ込めが発火しないか」を網羅**できます。コード（vitest 相当の Python テスト）とインフラ（`create-sample-findings`）の両面で対応経路を検証する——これが本サイトの検証ファースト原則の実装です。

---

## 6. ワークスルー：認証情報侵害 → 権限昇格 → S3 持ち出しを、攻撃シーケンスがどう束ねるか

抽象論を、公式が挙げる代表シナリオ（AWS credentials and Amazon S3 bucket data compromise）で具体化します。**S3 Protection を有効化済み**のアカウントを前提にします。

### 6.1 攻撃の進行（攻撃者側の動き）

| 段階 | 攻撃者の操作 | GuardDuty 側で何が「シグナル」になるか | ATT&CK 戦術 |
| --- | --- | --- | --- |
| ① 初期侵入 | 漏洩した EC2 インスタンス認証情報を AWS 外から使用 | `UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS`（finding） | Initial Access / Credential Access |
| ② 偵察 | `iam:ListRoles`、`s3:ListBuckets`、`s3:GetBucketPolicy` を連発 | IAM/S3 への権限探索（弱いシグナル） | Discovery |
| ③ 権限昇格・永続化 | 新しいアクセスキー作成、ポリシーのアタッチ | 異常な IAM 操作（弱いシグナル） | Privilege Escalation / Persistence |
| ④ 防御回避 | バケットポリシーを緩める（`s3:PutBucketPolicy`） | バケットが過度に許可的になる制御プレーン変更（弱いシグナル） | Defense Evasion |
| ⑤ 持ち出し | 緩めたバケットから大量に `s3:GetObject` | S3 データイベント（S3 Protection があれば相関対象） | Exfiltration |

ここで重要なのは——**①〜④の多くは、点で見れば「中程度の不審な操作」**だということです。②の権限探索や④のポリシー変更は、正規の運用でも起こり得ます。個別の finding として severity を切るだけだと、High に届かず通知の海に埋もれかねません。

### 6.2 ETD が束ねた結果

ETD は、これら①〜⑤が **同じ認証情報・同じ24時間窓・整合する順序**で起きたことを相関し、**1つの `AttackSequence:S3/CompromisedData`（Critical）** を生成します。公式の言葉どおり「**同じ認証情報で複数の疑わしく異常な攻撃挙動（API リクエスト）が観測され、認証情報が悪用されているという確信度が高まった**」結果です。この1 finding の details には：

- **Signals タイムライン**：①→②→③→④→⑤ の時系列（どこまで進んだか＝**持ち出しまで到達済み**が一目で分かる）
- **Indicators**：AWS 外からの API 呼び出し元 IP の評判、異常な API シーケンス
- **MITRE マッピング**：Initial Access → Discovery → Privilege Escalation → Defense Evasion → Exfiltration の戦術連鎖
- **Actors / 影響リソース**：悪用された IAM 主体、持ち出された S3 バケット

が含まれます。**点では見えなかった『これは認証情報侵害からの S3 持ち出しという完成した攻撃だ』が、線として一目で読める**——これが攻撃シーケンスの価値です。

### 6.3 S3 Protection を入れていなかったら？

公式の記述どおり、**S3 Protection 無しでも ETD は④（バケットが過度に許可的になった制御プレーン変更）までは検知できます**。しかし⑤の**実際のデータ持ち出し**は相関に入りません。「ポリシーが緩んだ」までは分かるが「実際に抜かれた」かは見えない——この差が、S3 Protection を「ETD のために」有効化する具体的な理由です。

### 6.4 検知の次：対応へ

この `AttackSequence:S3/CompromisedData`（Critical）を受けたら、対応は段階的に：

1. **即時（自動・取り消し可能）**：最優先チケット化＋オンコールへ通知。攻撃シーケンス型は高信頼なので、ここは自動でよい。
2. **封じ込め（承認後 or 厳選自動）**：悪用された認証情報の失効（IAM 主体の無効化／キーローテーション）、緩んだバケットポリシーの巻き戻し。鍵失効は影響が大きいので、`sample` でないことを確認のうえ、承認ゲートを挟むのが安全。
3. **調査**：Detective で主体・リソースのグラフを辿り、持ち出された範囲を確定。

具体的な EventBridge → 冪等な自動対応の配管は、[GuardDuty 自動対応・インシデントレスポンスのスポーク記事](/blog/aws-guardduty-eventbridge-automated-remediation-incident-response-guide)で深掘りします。攻撃シーケンスは**「型の許可リスト＋Critical」という二重条件で最優先ルートに乗せられる、自動対応の理想的なトリガー**です。

---

## 7. 落とし穴：Suppression Rule が攻撃シーケンスを「材料ごと消す」

ETD 運用で最も見落とされ、最も危険なのがこれです。結論から——**ETD は、アーカイブされた finding（Suppression Rule で自動アーカイブされたものを含む）を、攻撃シーケンスの相関材料にしません**。

### 7.1 公式が明言する挙動

公式の Note を正確に引くと：

> 攻撃シーケンスのためにイベントを相関する際、Extended Threat Detection は**アーカイブされた finding を考慮しません。これには Suppression Rule によって自動的にアーカイブされた finding も含まれます**。

そして専用節「Using suppression rules with Extended Threat Detection」では、具体例まで挙げています——**「特定の既知アクティビティを狙うのではなく、EKS クラスタ関連の finding をすべてアーカイブする抑制ルールを作ると、GuardDuty はそれらの finding を使って『コンテナ悪用→特権トークン取得→機密リソースアクセス』の攻撃シーケンスを検知できなくなる」**。

つまり、**「ノイズだから」と広く抑制したシグナルは、本来それが材料となって束ねられるはずだった攻撃シーケンス（Critical）ごと、丸ごと不可視化されます**。誤検知を消したつもりが、最も重大な多段攻撃の検知能力を自分で削っている——これが Suppression Rule の罠です。

### 7.2 公式の推奨と、運用ルール

公式は2点を推奨しています。

- 既知の信頼できるアクティビティからのアラートを減らすために、Suppression Rule は使い続けてよい。
- ただし **Suppression Rule は「GuardDuty に finding を出してほしくない特定の挙動」に絞れ**（finding 型を丸ごと消すような広い抑制を避けよ）。

加えて公式は、Suppression Rule の Best practice として **「reactive に、自分の環境で繰り返し誤検知だと確認できた finding に対してのみ作れ」** とも明言しています。「念のため先に消しておく」は禁物です。

これを運用ルールに落とすと：

| やってよい抑制 | やってはいけない抑制 |
| --- | --- |
| `Recon:EC2/Portscan` を**特定の脆弱性スキャナの AMI/タグに限定**して抑制 | `Recon:*` を型ごと全アカウントで抑制 |
| `UnauthorizedAccess:EC2/SSHBruteForce` を**特定の bastion インスタンスに限定**して抑制 | EKS/S3 関連 finding をリソース無指定で広く抑制 |
| `UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS` を**オンプレ GW の固定 IP に限定**して抑制 | 攻撃シーケンスの材料になり得る finding 型を予防的に抑制 |

**抑制は『リソース／IP／タグで絞り込んだピンポイント』に限る。型を丸ごと消すのは、ETD の目を潰す行為**——これが鉄則です。ノイズを静かにしたいだけなら、抑制（＝アーカイブ＝ETD から不可視）ではなく、[ピラー記事の EventBridge severity 閾値や型ルーティング](/blog/aws-guardduty-threat-detection-multi-account-terraform-eventbridge-guide)で「通知だけ静かにする」のが正解です。finding は GuardDuty 内に残り、ETD の相関材料として生き続けます。

### 7.3 既存の Suppression Rule を監査する

「広すぎる抑制が無いか」は、定期的に棚卸しすべきです。GuardDuty の Suppression Rule は、`service.archived = true` の `findingCriteria` として表現されます。委任管理者アカウント（マルチアカウント環境では**管理者だけが抑制ルールを作れる**）で、現行のフィルタを書き出して監査します。

```bash
# 委任管理者アカウントで実行：現行の filter（= suppression の母体）を一覧し、
# 「リソース指定の無い、型だけの広い抑制」を洗い出す。
DETECTOR_ID="$(aws guardduty list-detectors --query 'DetectorIds[0]' --output text)"

for FILTER in $(aws guardduty list-filters --detector-id "$DETECTOR_ID" \
                  --query 'FilterNames[]' --output text); do
  echo "=== ${FILTER} ==="
  # action=ARCHIVE の filter が suppression rule。criterion を見て絞り込みの粒度を確認する。
  aws guardduty get-filter --detector-id "$DETECTOR_ID" --filter-name "$FILTER" \
    --query '{name:Name, action:Action, criterion:FindingCriteria.Criterion}'
done
```

> **監査の着眼点**：`action` が `ARCHIVE` の filter のうち、`Criterion` が **finding 型（`type`）だけ**で、`resource.*` / IP / タグ等の絞り込みを持たないものが**危険信号**です。特に EKS / S3 / IAM 系を型ごと消している抑制は、対応する攻撃シーケンスを不可視化している可能性が高い。発見したら、リソース指定で絞り込むか、抑制をやめて通知側フィルタへ移します。

---

## 8. トリアージと対応：Critical な攻撃シーケンスをどう優先順位づけ、どう動くか

最後に、攻撃シーケンス finding を受けてからの動き方を、優先順位づけの観点でまとめます。

### 8.1 なぜ「攻撃シーケンス＝最優先」でよいのか

個別 finding のトリアージは「severity の数値で切る」が基本ですが、severity だけだと grey zone が残ります。攻撃シーケンスは違います——**ETD が複数のシグナルの連鎖を確信度の根拠として束ねた結果が Critical** なので、**型が `AttackSequence:*` であること自体が、高い確信度の証**です。だから運用上は：

- **`AttackSequence:*`（必ず Critical）→ 即・最優先エスカレーション**。人間の一次トリアージを待たず、オンコールを起こしてよい数少ないシグナル。
- 個別 finding（High 7.0–8.9 等）→ 通常のトリアージキュー。
- ただし**サンプル（`sample: true`）は除外**——5章のとおり、サンプルで本番の封じ込めを発火させない。

### 8.2 対応の段階設計

攻撃シーケンスへの対応も、本サイトの自動化三原則（**冪等・スコープを絞る・取り消せる**）を守ります。Critical だからといって、いきなり破壊的操作を全自動にしてはいけません。

| 段階 | アクション | 自動化の可否 |
| --- | --- | --- |
| **通知・チケット化** | 最優先チケット作成＋オンコール通知、finding details（Signals/Indicators/MITRE）を enrich | **全自動でよい**（取り消し可能・非破壊） |
| **封じ込め（軽）** | 影響 EC2 群を隔離 SG に付け替え、攻撃元 IP/ドメインの遮断 | **厳選自動**（冪等・取り消し可能なものに限る。型許可リスト＋非サンプル） |
| **封じ込め（重）** | 侵害認証情報の失効、バケットポリシー巻き戻し、インスタンス停止 | **承認ゲートを挟む**（影響が大きい・取り消しにくい） |
| **調査** | Detective でグラフ可視化、Security Hub で他検知と突合、影響範囲の確定 | 半自動（証拠収集は自動、判断は人間） |

公式は各攻撃シーケンス型について、対応先（Remediation）を明示しています——たとえば `AttackSequence:S3/CompromisedData` なら「**侵害された AWS 認証情報の修復**」と「**侵害された S3 バケットの修復**」の両方を辿れ、と。攻撃シーケンスは複数リソースに跨るため、**1つの finding から複数の remediation 経路に分岐する**のが特徴です。EventBridge → 冪等な自動対応の実装は[自動対応のスポーク記事](/blog/aws-guardduty-eventbridge-automated-remediation-incident-response-guide)に委ねます。

> **集約と深掘り**：攻撃シーケンスも委任管理者アカウントに集約され、**Security Hub CSPM** で他の検知と並べて優先順位づけ、**Amazon Detective** でグラフ調査、**S3 エクスポート**で長期保管——という三段構えはピラー記事と同じです。攻撃シーケンスは複数リソースに跨るぶん、Detective のグラフ調査が特に効きます。

---

## 9. まとめ：Extended Threat Detection / 攻撃シーケンス チートシート

迷ったときの早見表です。

- **ETD とは**：個別 finding と API 操作（＝**シグナル**、単体で脅威に見えないものは**弱いシグナル**）を、**1アカウント内・24時間ローリングウィンドウ**で相関し、多段攻撃を1つの**攻撃シーケンス finding** に束ねる上位レイヤー。**追加費用ゼロ・GuardDuty 有効化で自動オン**。
- **攻撃シーケンスの5型**：`AttackSequence:IAM/CompromisedCredentials`・`AttackSequence:S3/CompromisedData`・`AttackSequence:EKS/CompromisedCluster`・`AttackSequence:ECS/CompromisedCluster`・`AttackSequence:EC2/CompromisedInstanceGroup`。**その性質上すべて必ず Critical（9.0〜10.0）**。
- **保護プランで相関範囲が広がる**：IAM は基盤のみで成立（タダで最強）。S3 持ち出しには **S3 Protection**、EKS には **EKS Protection か Runtime Monitoring**（公式は両方推奨）、ECS には **Runtime Monitoring（Fargate/EC2、Managed EC2 は非対応）**、EC2 は **Runtime Monitoring で強化**。
- **EC2 グループ**：ASG / IAM インスタンスプロファイル / 起動テンプレート / CloudFormation スタック / AMI / VPC ID を共有するフリートを1 finding に束ねる（IaC 管理の同一構成は連鎖侵害の前提）。
- **読み方**：攻撃シーケンス finding は **Signals タイムライン・Indicators・MITRE マッピング・Actors/Endpoints・影響リソース**を持つ「線のレポート」。severity だけでなく**どこまで進んだか**を読む。
- **検証**：`create-sample-findings --finding-types AttackSequence:...` で攻撃シーケンスのサンプルを発火させ、EventBridge → 対応パイプラインを事前検証。サンプルは **`[SAMPLE]` 接頭辞**と **`"sample": true`** で見分け、**サンプルでは封じ込めを発火させない**。
- **Suppression Rule の罠（最重要）**：**ETD はアーカイブ済み finding（抑制で自動アーカイブされたものを含む）を相関材料にしない**。型を丸ごと消す広い抑制は攻撃シーケンスごと不可視化する。**抑制はリソース/IP/タグで絞ったピンポイントに限り、ノイズ低減は通知側フィルタで**。既存の `action=ARCHIVE` フィルタを定期監査する。
- **トリアージ**：`AttackSequence:*`（必ず Critical）は**即・最優先エスカレーション**してよい高信頼シグナル。対応は**通知＝全自動 / 軽い封じ込め＝厳選自動 / 重い封じ込め＝承認ゲート**の三段。

攻撃シーケンスは、GuardDuty を「点の finding を人間が追う運用」から「攻撃の文脈を線で受け取る運用」へ引き上げる機能です。最大のレバレッジは、**この高信頼な Critical トリガーを、冪等で・スコープを絞った・取り消せる自動対応に繋ぐ配管**にあります。

私はマルチアカウントの[サーバーレス決済プラットフォーム](/case-studies/payment-platform-reliability)で、**実際の金銭・カーボンクレジット・地域通貨を扱う基盤の IAM・可観測性・DR を横断実装**し、「正しさ」を運用の注意深さではなく**コードの構造と冪等性**で担保してきました（本番二重課金0件）。GuardDuty も実プロジェクトで「導入済み」と謳うことはしませんが、**この ETD・攻撃シーケンスを軸にした検知設計——どの保護プランで相関を解禁し、攻撃シーケンスをどう最優先ルートに乗せ、Suppression Rule の穴をどう塞ぐか——を、同じ思想で設計・実装できます**。

**「自社の AWS で、多段攻撃（攻撃シーケンス）をどう検知し、どこまで自動対応を任せ、誤抑制の穴をどう塞ぐか」——ETD の相関範囲を広げる保護プラン選定から、サンプル検証、EventBridge 連携、Suppression Rule 監査まで、一人 ×生成AI（Claude Code）で速く・安全に伴走できます。** 要件の整理段階からでも、お気軽にご相談ください。

---

### 参考（公式ドキュメント）

- [GuardDuty Extended Threat Detection](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty-extended-threat-detection.html) — ETD の定義・シグナル/弱いシグナル相関・24時間ローリングウィンドウ・攻撃シーケンス（必ず Critical）・保護プランごとの相関範囲（EKS/S3/ECS/EC2）・アーカイブ済みを考慮しない挙動
- [GuardDuty attack sequence finding types](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty-attack-sequence-finding-types.html) — 5つの攻撃シーケンス型（IAM/S3/EKS/ECS/EC2）の正確な型名・Default severity（Critical）・各型のデータソースと脅威シナリオ
- [Suppression rules in GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/findings_suppression-rule.html) — 抑制ルールの自動アーカイブ・ETD との相互作用（アーカイブ済みは相関材料にならない）・絞り込んだ抑制の推奨・reactive な作成
- [Generating sample findings in GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/sample_findings.html) — `create-sample-findings` の構文・攻撃シーケンス型を含むサンプル生成・`[SAMPLE]` 接頭辞と `"sample": true`