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

「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 本番設計のピラー記事で扱っています。本記事はその 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 自動対応の配管にそのまま乗せられます——乗せ方さえ設計すれば。

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

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

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

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

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

公式の表現を借りれば、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 です。

ピラー記事の 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 のスポーク記事で扱います。

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

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

この表から導ける設計上の含意は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 は攻撃全体を物語る構造化されたレポートです。トリアージのために、何が入っているかを押さえます。

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

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

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

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

# 攻撃シーケンス型のサンプルを発火させ、対応パイプラインを検証する。
# 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 で攻撃シーケンスだけを拾うパターンは、型の接頭辞でフィルタするのが簡潔です。

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

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

"""攻撃シーケンス 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 攻撃の進行（攻撃者側の動き）

ここで重要なのは——**①〜④の多くは、点で見れば「中程度の不審な操作」**だということです。②の権限探索や④のポリシー変更は、正規の運用でも起こり得ます。個別の 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 自動対応・インシデントレスポンスのスポーク記事で深掘りします。攻撃シーケンスは**「型の許可リスト＋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 に対してのみ作れ」 とも明言しています。「念のため先に消しておく」は禁物です。

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

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

7.3 既存の Suppression Rule を監査する

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

# 委任管理者アカウントで実行：現行の 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 だからといって、いきなり破壊的操作を全自動にしてはいけません。

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

集約と深掘り：攻撃シーケンスも委任管理者アカウントに集約され、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 トリガーを、冪等で・スコープを絞った・取り消せる自動対応に繋ぐ配管にあります。

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

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

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

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