# A thorough explanation of GuardDuty Extended Threat Detection and attack-sequence findings: reading and responding to weak-signal correlation, the 24-hour window, and Critical multi-stage attacks

> A thorough explanation of GuardDuty Extended Threat Detection (ETD) and attack-sequence (AttackSequence) findings. From the weak-signal correlation model, the 24-hour rolling window, the five attack-sequence types of IAM/S3/EKS/ECS/EC2, why they're all Critical (9.0–10.0), the correlation range that widens by protection plan, verification with sample generation, to the trap where a Suppression Rule ignores the archived — read it as a line with a real example of credential compromise → privilege escalation → S3 exfiltration.

- Published: 2026-06-27
- Author: 友田 陽大
- Tags: セキュリティ, AWS, GuardDuty, 脅威検知, アーキテクチャ設計
- URL: https://tomodahinata.com/en/blog/aws-guardduty-extended-threat-detection-attack-sequence-findings-guide
- Category: Amazon GuardDuty in production
- Pillar guide: https://tomodahinata.com/en/blog/aws-guardduty-threat-detection-multi-account-terraform-eventbridge-guide

## Key points

- ETD is zero additional cost and auto-enabled. Treating API operations and existing findings as 'signals,' and what doesn't look like a threat on its own as 'weak signals,' it correlates within one account over a 24-hour rolling window and bundles a multi-stage attack into one attack-sequence finding.
- There are five attack-sequence types: IAM/CompromisedCredentials, S3/CompromisedData, EKS/CompromisedCluster, ECS/CompromisedCluster, EC2/CompromisedInstanceGroup. By their nature all are necessarily Critical (9.0–10.0).
- The correlatable range widens by protection plan. S3 exfiltration needs S3 Protection, EKS needs EKS Protection or Runtime Monitoring, ECS needs Runtime Monitoring (Fargate/EC2, Managed EC2 unsupported), and EC2 is strengthened by Runtime Monitoring.
- ETD doesn't use archived findings (including those auto-archived by a Suppression Rule) as correlation material. Too-broad suppression makes an entire attack sequence invisible — auditing suppression rules is mandatory.
- Before production, fire an attack-sequence-type sample with create-sample-findings and verify EventBridge → the response pipeline. Identify a sample by the [SAMPLE] prefix and "sample": true.

---

"Lots of GuardDuty findings come up every day, but which are the really bad ones?" — in a setting where I'm consulted about AWS security operation, it's the question that definitely comes up next after enabling protection plans settles down.

This is a correct question. When you enable GuardDuty and add protection plans, `Recon:EC2/Portscan`, `UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS`, and `CryptoCurrency:EC2/BitcoinTool.B!DNS` each come up as independent findings. But **a truly scary attack usually doesn't fit into one finding.** Credentials are stolen, privileges escalated, persistence established, and finally data siphoned from S3 — seen as points, this series looks like a chain of "medium-level suspicious operations," and **until a human analyst manually bundles it as "this is one attack," the overall picture of the attack is visible to no one.**

What does that "bundling" for you, GuardDuty itself, is **Extended Threat Detection (ETD)** and its product, the **attack-sequence finding.** This article digs into **what ETD correlates and how,** and **how to read an attack-sequence finding, how to prioritize it, and how to respond,** strictly based on the official documentation. GuardDuty's overall design (protection-plan selection, organizational control, EventBridge auto-response) is handled in the [GuardDuty production-design pillar article](/blog/aws-guardduty-threat-detection-multi-account-terraform-eventbridge-guide). This article is a **spoke** that digs much deeper into the ETD part of that, from the pillar's concise explanation.

> **The rules of this article**: finding-type names, severity, correlation behavior, and the relationship with protection plans are based on the **AWS official documentation (as of June 2026).** Since the supported protection plans and types of attack sequences are revised, always confirm the latest official information before production. **GuardDuty is a detection service, and even if it detects an attack sequence, it doesn't automatically stop it** — it's one layer of defense-in-depth. And another iron rule — **start the auto-response to an attack sequence too from those that satisfy "idempotent, narrow scope, reversible," and don't unconditionally automate destructive operations just because it's Critical.**

---

## 0. Mental model: an attack sequence is "the necessarily-Critical higher finding that bundles point findings into a line"

Before starting the design, let me fix in one line what ETD and an attack sequence are.

> **Extended Threat Detection = the zero-additional-cost, auto-enabled higher layer that correlates individual findings and API operations (= signals), within one account over a 24-hour rolling window, and bundles "the chain of a multi-stage attack" into one attack-sequence finding (necessarily Critical 9.0–10.0).**

From here, three consequences emerge. This is the foundation of all the triage design in this article.

1. **An attack sequence can be treated as a "top-priority trigger."** An attack-sequence finding is, by its nature, classified **all as Critical (9.0–10.0).** That is, the condition "severity is numerically 9.0 or above" and "the type is `AttackSequence:*`" is **one of the few high-trust signals you may route to the top-priority escalation without waiting for human judgment.** Rather than slicing point findings one by one by severity, reacting first to the bundle ETD judged as "this is a series of attacks" doesn't miss the context.

2. **ETD can't bundle if the "signals to be the material" aren't visible.** ETD works even with just the foundational data sources, but the correlatable range **widens in proportion to the protection plans you enabled.** Bundling S3 exfiltration needs S3 Protection; bundling EKS compromise needs EKS Protection or Runtime Monitoring. And what's decisive — **ETD doesn't use archived findings as correlation material.** A signal you erased with a Suppression Rule as "noise" is made invisible, along with the attack sequence it was supposed to bundle (detailed in chapter 7).

3. **An attack sequence also flows to EventBridge as a "normal finding."** There's no special delivery channel. An attack-sequence finding is, like other findings, sent to EventBridge, and if configured, exported to S3 too. So you can put it on the [pillar article's EventBridge auto-response](/blog/aws-guardduty-threat-detection-multi-account-terraform-eventbridge-guide) plumbing as-is — **as long as you design how to put it on.**

Grasping these three points, ETD operation can be decomposed into three designs: **"① what attack sequences are bundled (the correspondence of types and protection plans) → ② how to read the bundled finding (indicators, timeline, MITRE) → ③ how to verify and respond (sample firing, triage, containment)."** Let's build them in order.

---

## 1. The correlation model: signals, weak signals, the 24-hour rolling window

ETD's core is "correlation." First, let me fix its material and window exactly per the official definition.

### 1.1 Signals and "weak signals"

GuardDuty calls the events that become correlation material **Signals.** There are two kinds of signals.

| Kind of signal | Contents | Example |
| --- | --- | --- |
| **An existing GuardDuty finding** | a finding that individual detection logic already fired | `UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS` |
| **Weak signals** | events like API operations that don't look like a "clear threat" on their own | IAM-privilege probing of the S3 API, control-plane operations that loosen a bucket policy |

To borrow the official expression, GuardDuty treats **individual API activity as a "weak signal"** — because it doesn't look like a threat on its own. ETD's value lies in **aligning these "weak signals that look harmless on their own" and "findings already raised" as a time-series pattern.** For example, the following chain, seen as points, is all "common operations," but seen as a line is a clear attack.

- An anomalous principal repeatedly runs `s3:ListBuckets` / `s3:GetBucketPolicy` (privilege probing = weak signal)
- Then loosens the bucket policy with `s3:PutBucketPolicy` (control-plane change = weak signal)
- After that, fetches a large number of objects from the loosened bucket (data exfiltration = becomes a finding if there's S3 Protection)

An important fact the official clearly states — **with just the foundational data sources, ETD can detect the chain "IAM-privilege probing of the S3 API → a control-plane change making the bucket policy more permissive."** Adding S3 Protection brings even "actual data exfiltration" into the correlation range.

### 1.2 The 24-hour rolling window

ETD correlates **attack behavior in progress or recent (within a 24-hour rolling time window).** "Rolling" is the crux — not a fixed midnight start but a window that **constantly keeps looking at the latest 24 hours.**

This 24-hour design has two operational implications.

1. **It presupposes that an attack doesn't complete in minutes.** Reconnaissance → intrusion → escalation → exfiltration usually proceeds on the order of minutes to hours. A 1-hour or 6-hour window misses a slowly-proceeding attack (low-and-slow). 24 hours is that balance point.
2. **The finding delay and the window are separate.** The finding's "recurrence delivery frequency" follows `finding_publishing_frequency` (default 6 hours), but the window ETD uses for correlation is 24 hours. **If you want the auto-response reaction faster, the recommendation is `finding_publishing_frequency = FIFTEEN_MINUTES` as in the pillar article** — because if the attack sequence's "follow-up report" is delayed up to 6 hours, containment falls behind.

### 1.3 Why "correlation" is stronger than point detection

In a word, because **the context filter for false positives works.** An individual finding, on its own, contains a lot of the "might be legitimate operation" grey zone. ETD makes **the very fact that "multiple suspicious behaviors chained on the same principal and the same resource group" the basis of confidence.** The official also explains that an attack sequence is issued as a result of "multiple suspicious and anomalous attack behaviors observed with the same credentials, and **the confidence that the credentials are being abused increased.**" That's why an attack sequence is Critical — the confidence is structurally high.

---

## 2. All attack-sequence finding types: the five kinds, and the threat scenario each bundles

The attack-sequence findings the official documentation defines are currently **five types.** The type name is in the form **`AttackSequence:ResourceType/ThreatName`,** with the resource kind and scenario encoded. **All have a Default severity of Critical.**

| Finding type | Threat scenario it bundles | Data sources used for detection (official) |
| --- | --- | --- |
| **`AttackSequence:IAM/CompromisedCredentials`** | A series of API requests by compromised AWS credentials (escalation, persistence, lateral movement) | CloudTrail management events (holds with the foundation only) |
| **`AttackSequence:S3/CompromisedData`** | An attempt to exfiltrate/destroy S3 data by compromised credentials (can also be part of ransomware) | S3 CloudTrail data events + CloudTrail management events |
| **`AttackSequence:EKS/CompromisedCluster`** | Compromise of an EKS cluster (abusing a vulnerable container → obtaining a privileged token → accessing secrets/AWS resources) | EKS audit logs, Runtime Monitoring for EKS, malware detection for EC2, S3 data events, CloudTrail management events, VPC Flow Logs, DNS query logs |
| **`AttackSequence:ECS/CompromisedCluster`** | Compromise of an ECS cluster (malicious processes, communication with malicious endpoints, cryptocurrency mining) | Runtime Monitoring for Fargate/EC2, malware detection for EC2 |
| **`AttackSequence:EC2/CompromisedInstanceGroup`** | Compromise of an EC2 instance group sharing common attributes (malicious processes, C&C communication, mining, anomalous use of instance credentials) | Runtime Monitoring for EC2, malware detection for EC2, VPC Flow Logs, DNS query logs |

> **The diff from the pillar article's brief (an honest note to the reader)**: in the GuardDuty production-design pillar article, I abbreviated it as `AttackSequence:S3/...`, but **the official accurate type name is `AttackSequence:S3/CompromisedData`.** Also, **`AttackSequence:IAM/CompromisedCredentials` (an attack sequence of credential abuse that holds with just the foundational data sources)**, not touched on in the pillar, exists. When routing auto-response by type name, use these accurate five types as the basis of the allowlist.

### 2.1 What the EC2 "instance group" is

Only `AttackSequence:EC2/CompromisedInstanceGroup` has the concept of "group," so let me supplement. According to the official, ETD makes **an individual instance, or an instance group sharing common attributes,** the target of an attack sequence. The common attributes are:

- **Auto Scaling group**
- **IAM instance profile (role)**
- **Launch template**
- **CloudFormation stack**
- **AMI**
- **VPC ID**

Why group — because **an IaC-managed fleet of the same configuration, if one is compromised, the others are highly likely similarly compromised.** By the attack sequence bundling this as a "group" into one finding, instead of "100 findings scattered one per instance among 100," you receive one decision unit of "this ASG was compromised." The scope of triage and containment is sliced at the correct granularity from the start.

### 2.2 An important constraint of ECS

`AttackSequence:ECS/CompromisedCluster` has an easily-overlooked premise. As the official clearly states as **Important** —

- The ECS attack sequence **requires Runtime Monitoring (Fargate or EC2).**
- **ECS on Managed EC2 instances is unsupported.**

If you run ECS on Fargate, you need Runtime Monitoring for Fargate; for the EC2 launch type, Runtime Monitoring for EC2. It's not that "using ECS automatically makes the ECS attack sequence work" — note that **it can be bundled only once you put in runtime visibility.** Details are handled in the [Runtime Monitoring spoke article](/blog/aws-guardduty-runtime-monitoring-eks-ecs-fargate-ec2-guide).

---

## 3. The correspondence table of protection plans and correlation range: what you enable to make which attack sequence "bundleable"

This is, in ETD's design, the most practical judgment point. **ETD itself is free and automatic, but the kinds of attack sequences that can be bundled are decided by the protection plans you enabled.** Let me reconstruct the official description into a form usable for enablement judgment.

| Attack sequence | Minimum needed | Recommended (maximize coverage) | What happens if not enabled |
| --- | --- | --- | --- |
| **IAM/CompromisedCredentials** | foundational data sources only (CloudTrail management events) | — | enabling GuardDuty = works immediately. No additional plan needed |
| **S3/CompromisedData** | **S3 Protection** | S3 Protection | without S3 Protection, you can detect up to "the bucket became overly permissive" but can't correlate the subsequent **data exfiltration** |
| **EKS/CompromisedCluster** | **EKS Protection** or **Runtime Monitoring (the EKS add-on)** | enable both | without either, no EKS individual findings come up and the EKS attack sequence can't be bundled |
| **ECS/CompromisedCluster** | **Runtime Monitoring (Fargate or EC2)** | Runtime Monitoring | without Runtime Monitoring, the ECS attack sequence is undetectable (ECS on Managed EC2 is unsupported) |
| **EC2/CompromisedInstanceGroup** | foundational data sources (CloudTrail + network) | strengthened **+ Runtime Monitoring** | holds in part with just the foundation. Adding Runtime Monitoring brings process behavior and system calls into the correlation |

The design implications derivable from this table are three.

1. **IAM/CompromisedCredentials is "free yet strongest."** It works with just the foundational data sources (on immediately on enabling GuardDuty). Since credential abuse is the most universal attack route, **the moment you enable GuardDuty, you've got the highest-value attack-sequence detection.**
2. **The reason to enable S3 Protection is "both individual detection + ETD correlation."** As touched on in the pillar article, S3 Protection is cheap and effective. From the viewpoint of **unlocking ETD's S3/CompromisedData** too, it's almost always recommended for accounts handling sensitive data.
3. **For EKS and ETD, "enable both" is the official recommendation.** EKS Protection (audit logs = control plane) and Runtime Monitoring (inside the container = data plane) **see different layers,** so with only one, you see only half the attack. The official explains that "by enabling both, you can express the chain of an anomalous deployment of a privileged container (detected by EKS Protection) → persistence/mining/reverse shell within it (detected by Runtime Monitoring) as one Critical finding."

> **A cost-viewpoint supplement**: Runtime Monitoring is the protection plan most likely to be the most expensive with vCPU billing (pricing details in chapter 8 of the pillar article). That's exactly why, rather than "put it all in," a phased introduction of **① secure the IAM attack sequence free with the foundation → ② cheaply add the S3 attack sequence with S3 Protection → ③ add the runtime correlation of EKS/ECS/EC2 with Runtime Monitoring 'only when that asset is in production'** wins on cost-effectiveness.

---

## 4. The "reading" of an attack-sequence finding: what's different from an individual finding

An attack-sequence finding flows to the same EventBridge / the same Findings page as an individual finding, but **the contents (details) of the finding are decisively different.** Whereas an individual finding describes "one suspicious event," an attack-sequence finding is **a structured report that tells the story of the whole attack.** For triage, let me pin down what's in it.

| Element included in an attack-sequence finding | What it conveys | Where it's used in triage |
| --- | --- | --- |
| **Signals (the signal timeline)** | when and in what order the bundled individual signals (findings + weak signals) occurred | grasp the attack's progression stage in time series. Judge how far it progressed (did it reach exfiltration) |
| **Indicators** | concrete evidence backing the attack (bad-reputation IPs/domains, anomalous API sequences, user settings, etc.) | the basis of confidence for "why this was judged an attack." Used for false-positive judgment |
| **MITRE ATT&CK mapping** | which tactics/techniques of ATT&CK each signal corresponds to | grasp the attack's intent (Discovery / PrivilegeEscalation / Exfiltration …) in a common language |
| **Actors / Endpoints** | the principals (IAM principals, IPs) involved in the attack, and the external endpoints communicated with | identify containment targets (the principal whose keys to revoke, the IP/domain to block) |
| **Affected resources** | the AWS resources the attack sequence touched (S3 buckets, EC2 group, EKS cluster, etc.) | decide the scope of containment/investigation |

The official clearly states that an attack sequence uses multiple factors as correlation basis, like "**IP reputation, API sequence, user settings, potentially-affected resources.**" In other words, when reading an attack-sequence finding, **don't move on "just because severity is Critical," but look at the Signals timeline and Indicators to judge "how far the attack progressed"** — this is the reading unique to a line finding, not present in a point finding.

---

## 5. Hands-on: fire an attack-sequence sample and verify the response path

"Build the verification path first" is a consistent principle of this site. Before assembling the auto-response to an attack sequence, **without waiting for an actual attack, confirm with a sample finding whether EventBridge → the response pipeline works as expected.**

The official `CreateSampleFindings` can **generate samples of each finding type, including attack-sequence types.** The console's "Generate sample findings" generates **all types one by one** (attack sequences included), and the CLI/API can fire **only a specific type** targeted.

```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"
```

> **How to identify a sample (an important point to prevent mis-response)**: a sample finding, on the console, **always starts the title with `[SAMPLE]`** and has **`"sample": true`** in the `additionalInfo` section of the finding JSON. In the auto-response Lambda, it's safe to look at this `sample` flag and **skip destructive actions for samples** (you want to verify, but don't want to isolate a production EC2 with a sample). Understand also that a sample is approximated with placeholder values and looks different from a real finding.

The pattern to pick up only attack sequences in EventBridge is concise to filter by the type prefix.

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

The skeleton of a verification handler that "branches looking at the `sample` flag" on sample receipt is as follows. Separate decision (pure logic) and side effect (API call) so the whole path can be safely flowed even with a sample.

```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,
    }
```

Since it's carved out into pure logic (`classify`), you can comprehensively **unit-test "are all five types correctly judged top-priority" and "doesn't containment fire on a sample"** with sample-finding JSON as input. Verify the response path from both the code (Python tests equivalent to vitest) and the infrastructure (`create-sample-findings`) — this is the implementation of this site's verification-first principle.

---

## 6. Walkthrough: how an attack sequence bundles credential compromise → privilege escalation → S3 exfiltration

Let me concretize the abstract with the representative scenario the official cites (AWS credentials and Amazon S3 bucket data compromise). Premise: an account with **S3 Protection enabled.**

### 6.1 The attack's progression (the attacker side's moves)

| Stage | The attacker's operation | What becomes a "signal" on the GuardDuty side | ATT&CK tactic |
| --- | --- | --- | --- |
| ① Initial intrusion | use leaked EC2 instance credentials from outside AWS | `UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS` (finding) | Initial Access / Credential Access |
| ② Reconnaissance | repeatedly run `iam:ListRoles`, `s3:ListBuckets`, `s3:GetBucketPolicy` | privilege probing of IAM/S3 (weak signal) | Discovery |
| ③ Privilege escalation / persistence | create a new access key, attach a policy | anomalous IAM operations (weak signal) | Privilege Escalation / Persistence |
| ④ Defense evasion | loosen the bucket policy (`s3:PutBucketPolicy`) | a control-plane change making the bucket overly permissive (weak signal) | Defense Evasion |
| ⑤ Exfiltration | mass `s3:GetObject` from the loosened bucket | S3 data events (a correlation target if there's S3 Protection) | Exfiltration |

What's important here — **many of ①–④, seen as points, are "moderately suspicious operations."** ②'s privilege probing and ④'s policy change can also happen in legitimate operation. If you only slice severity as individual findings, they may not reach High and get buried in the sea of notifications.

### 6.2 The result ETD bundled

ETD correlates that these ①–⑤ occurred with **the same credentials, the same 24-hour window, and a consistent order,** and generates **one `AttackSequence:S3/CompromisedData` (Critical).** As the official words go, it's the result of "**multiple suspicious and anomalous attack behaviors (API requests) observed with the same credentials, and the confidence that the credentials are being abused increased.**" This one finding's details include:

- **The Signals timeline**: the time series ①→②→③→④→⑤ (you can tell at a glance how far it progressed = **already reached exfiltration**)
- **Indicators**: the reputation of the API-caller IP from outside AWS, the anomalous API sequence
- **MITRE mapping**: the tactic chain Initial Access → Discovery → Privilege Escalation → Defense Evasion → Exfiltration
- **Actors / affected resources**: the abused IAM principal, the exfiltrated S3 bucket

**The "this is a completed attack of S3 exfiltration from credential compromise," invisible as points, reads at a glance as a line** — this is the value of an attack sequence.

### 6.3 What if you hadn't put in S3 Protection?

As the official describes, **even without S3 Protection, ETD can detect up to ④ (the control-plane change making the bucket overly permissive).** But ⑤'s **actual data exfiltration** isn't in the correlation. You can tell "the policy loosened" but can't see whether "it was actually siphoned" — this difference is the concrete reason to enable S3 Protection "for ETD."

### 6.4 After detection: to response

On receiving this `AttackSequence:S3/CompromisedData` (Critical), the response is phased:

1. **Immediate (automatic, reversible)**: top-priority ticketing + notify on-call. Since the attack-sequence type is high-trust, this can be automatic.
2. **Containment (after approval or selectively automatic)**: revoke the abused credentials (disable the IAM principal / rotate keys), roll back the loosened bucket policy. Since key revocation has large impact, it's safe to interpose an approval gate after confirming it's not a `sample`.
3. **Investigation**: trace the principal/resource graph with Detective and fix the exfiltrated scope.

The concrete EventBridge → idempotent auto-response plumbing is dug into in the [GuardDuty auto-response / incident-response spoke article](/blog/aws-guardduty-eventbridge-automated-remediation-incident-response-guide). An attack sequence is **an ideal trigger for auto-response that you can put on the top-priority route with the double condition "type allowlist + Critical."**

---

## 7. Pitfall: a Suppression Rule "erases the attack sequence along with its material"

The most overlooked and most dangerous thing in ETD operation is this. From the conclusion — **ETD doesn't use archived findings (including those auto-archived by a Suppression Rule) as correlation material for an attack sequence.**

### 7.1 The behavior the official clearly states

Quoting the official Note accurately:

> When correlating events for attack sequences, Extended Threat Detection **doesn't consider archived findings. This includes findings that were automatically archived by a Suppression Rule.**

And the dedicated section "Using suppression rules with Extended Threat Detection" even gives a concrete example — **"if you create a suppression rule that archives all EKS-cluster-related findings, rather than targeting a specific known activity, GuardDuty can no longer use those findings to detect the attack sequence 'container abuse → obtaining a privileged token → accessing sensitive resources.'"**

In other words, **a signal you broadly suppressed as "noise" is made wholly invisible, along with the attack sequence (Critical) it was supposed to be the material for.** You thought you erased a false positive but are cutting your own ability to detect the most serious multi-stage attack — this is the trap of the Suppression Rule.

### 7.2 The official recommendation, and the operational rule

The official recommends two points.

- You may keep using a Suppression Rule to reduce alerts from known trusted activity.
- But **narrow the Suppression Rule to "a specific behavior you don't want GuardDuty to issue a finding for"** (avoid broad suppression that erases an entire finding type).

In addition, the official also clearly states, as a Best practice for Suppression Rules, **"create them reactively, only for findings you've repeatedly confirmed are false positives in your own environment."** "Erase it in advance just in case" is forbidden.

Dropping this into an operational rule:

| Suppression you may do | Suppression you must not do |
| --- | --- |
| suppress `Recon:EC2/Portscan` **limited to a specific vulnerability scanner's AMI/tag** | suppress `Recon:*` by type across all accounts |
| suppress `UnauthorizedAccess:EC2/SSHBruteForce` **limited to a specific bastion instance** | broadly suppress EKS/S3-related findings with no resource specification |
| suppress `UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS` **limited to the on-prem GW's fixed IP** | preemptively suppress a finding type that could be material for an attack sequence |

**Limit suppression to "a pinpoint narrowed by resource/IP/tag." Erasing a whole type is the act of gouging out ETD's eyes** — this is the iron rule. If you just want to quiet noise, the correct answer isn't suppression (= archive = invisible from ETD) but to "quiet only the notification" with [the pillar article's EventBridge severity threshold or type routing](/blog/aws-guardduty-threat-detection-multi-account-terraform-eventbridge-guide). The finding remains inside GuardDuty and stays alive as ETD's correlation material.

### 7.3 Audit existing Suppression Rules

"Is there a too-broad suppression" should be taken stock of periodically. GuardDuty's Suppression Rule is expressed as a `findingCriteria` of `service.archived = true`. In the delegated administrator account (in a multi-account environment, **only the administrator can create suppression rules**), write out the current filters and audit.

```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
```

> **The audit focus**: among filters with `action` of `ARCHIVE`, those whose `Criterion` is **the finding type (`type`) only** and have no narrowing by `resource.*` / IP / tag are a **danger signal.** Especially suppression that erases EKS / S3 / IAM kinds by type is highly likely making the corresponding attack sequence invisible. If found, narrow it by resource specification, or stop the suppression and move it to a notification-side filter.

---

## 8. Triage and response: how to prioritize a Critical attack sequence, and how to move

Finally, let me organize how to move after receiving an attack-sequence finding, from the prioritization viewpoint.

### 8.1 Why "attack sequence = top priority" is fine

The triage of individual findings is basically "slice by the severity number," but with just severity, a grey zone remains. An attack sequence is different — since **the result of ETD bundling a chain of multiple signals as the basis of confidence is Critical,** **the type being `AttackSequence:*` itself is proof of high confidence.** So operationally:

- **`AttackSequence:*` (necessarily Critical) → immediate, top-priority escalation.** One of the few signals you may wake on-call for without waiting for human primary triage.
- Individual findings (High 7.0–8.9, etc.) → the normal triage queue.
- But **exclude samples (`sample: true`)** — as in chapter 5, don't fire production containment with a sample.

### 8.2 The phased design of response

The response to an attack sequence too follows this site's three automation principles (**idempotent, narrow scope, reversible**). Don't fully automate destructive operations out of the blue just because it's Critical.

| Stage | Action | Automatable? |
| --- | --- | --- |
| **Notify, ticket** | create a top-priority ticket + on-call notification, enrich with finding details (Signals/Indicators/MITRE) | **fully automatic OK** (reversible, non-destructive) |
| **Containment (light)** | re-attach the affected EC2 group to an isolation SG, block the attack-source IP/domain | **selectively automatic** (limited to idempotent, reversible ones. Type allowlist + non-sample) |
| **Containment (heavy)** | revoke compromised credentials, roll back the bucket policy, stop instances | **interpose an approval gate** (large impact, hard to reverse) |
| **Investigation** | graph visualization with Detective, cross-check with other detections in Security Hub, fix the affected scope | semi-automatic (evidence collection automatic, judgment human) |

The official clearly states the remediation destination for each attack-sequence type — for example, for `AttackSequence:S3/CompromisedData`, "trace both **the remediation of the compromised AWS credentials** and **the remediation of the compromised S3 bucket**." Since an attack sequence spans multiple resources, it's characteristic that **one finding branches into multiple remediation paths.** The implementation of EventBridge → idempotent auto-response is left to the [auto-response spoke article](/blog/aws-guardduty-eventbridge-automated-remediation-incident-response-guide).

> **Aggregation and deep-dive**: an attack sequence is also aggregated to the delegated administrator account, and the three-stage setup — prioritize alongside other detections with **Security Hub CSPM,** graph-investigate with **Amazon Detective,** long-term retain with **S3 export** — is the same as the pillar article. Since an attack sequence spans multiple resources, Detective's graph investigation especially pays off.

---

## 9. Summary: Extended Threat Detection / attack-sequence cheat sheet

A quick reference for when you're lost.

- **What ETD is**: the higher layer that correlates individual findings and API operations (= **signals**, those that don't look like a threat on their own are **weak signals**), within **one account over a 24-hour rolling window,** and bundles a multi-stage attack into one **attack-sequence finding.** **Zero additional cost, auto-on on enabling GuardDuty.**
- **The five attack-sequence types**: `AttackSequence:IAM/CompromisedCredentials`, `AttackSequence:S3/CompromisedData`, `AttackSequence:EKS/CompromisedCluster`, `AttackSequence:ECS/CompromisedCluster`, `AttackSequence:EC2/CompromisedInstanceGroup`. **By their nature all are necessarily Critical (9.0–10.0).**
- **The correlation range widens by protection plan**: IAM holds with the foundation only (free yet strongest). S3 exfiltration needs **S3 Protection,** EKS needs **EKS Protection or Runtime Monitoring** (official recommends both), ECS needs **Runtime Monitoring (Fargate/EC2, Managed EC2 unsupported),** and EC2 is **strengthened by Runtime Monitoring.**
- **EC2 group**: bundles a fleet sharing ASG / IAM instance profile / launch template / CloudFormation stack / AMI / VPC ID into one finding (IaC-managed same-configuration is the premise of chained compromise).
- **Reading**: an attack-sequence finding is a "line report" with the **Signals timeline, Indicators, MITRE mapping, Actors/Endpoints, and affected resources.** Read not just severity but **how far it progressed.**
- **Verification**: fire an attack-sequence sample with `create-sample-findings --finding-types AttackSequence:...` and pre-verify EventBridge → the response pipeline. Identify a sample by the **`[SAMPLE]` prefix** and **`"sample": true`,** and **don't fire containment on a sample.**
- **The Suppression Rule trap (most important)**: **ETD doesn't use archived findings (including those auto-archived by suppression) as correlation material.** Broad suppression that erases a whole type makes the attack sequence invisible too. **Limit suppression to a pinpoint narrowed by resource/IP/tag, and reduce noise with a notification-side filter.** Periodically audit existing `action=ARCHIVE` filters.
- **Triage**: `AttackSequence:*` (necessarily Critical) is a high-trust signal you may **immediately, top-priority escalate.** The response is the three stages of **notify = fully automatic / light containment = selectively automatic / heavy containment = approval gate.**

An attack sequence is a feature that raises GuardDuty from "operation where a human chases point findings" to "operation where you receive the attack's context as a line." The biggest leverage lies in **the plumbing that connects this high-trust Critical trigger to idempotent, narrow-scope, reversible auto-response.**

I, on a multi-account [serverless payment platform](/case-studies/payment-platform-reliability), **cross-implemented the IAM, observability, and DR of a platform handling actual money, carbon credits, and regional currency,** and guaranteed "correctness" not by operational carefulness but by **the structure of code and idempotency** (0 double charges in production). I won't claim GuardDuty as "introduced" in a real project, but **I can design and implement detection design centered on this ETD/attack sequence — which protection plans to unlock correlation with, how to put the attack sequence on the top-priority route, and how to plug the Suppression Rule holes — with the same philosophy.**

**"How to detect a multi-stage attack (attack sequence) in your AWS, how far to leave auto-response, and how to plug the mis-suppression holes" — from selecting protection plans to widen ETD's correlation range, to sample verification, EventBridge integration, and Suppression Rule auditing, I can accompany you fast and safely with one person × generative AI (Claude Code).** Even from the requirement-organizing stage, please feel free to consult me.

---

### References (official documentation)

- [GuardDuty Extended Threat Detection](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty-extended-threat-detection.html) — ETD's definition, signal/weak-signal correlation, the 24-hour rolling window, attack sequences (necessarily Critical), the per-protection-plan correlation range (EKS/S3/ECS/EC2), the behavior of not considering the archived
- [GuardDuty attack sequence finding types](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty-attack-sequence-finding-types.html) — the accurate type names of the five attack-sequence types (IAM/S3/EKS/ECS/EC2), the Default severity (Critical), and each type's data sources and threat scenario
- [Suppression rules in GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/findings_suppression-rule.html) — the auto-archive of suppression rules, the interaction with ETD (the archived isn't correlation material), the recommendation of narrowed suppression, reactive creation
- [Generating sample findings in GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/sample_findings.html) — the syntax of `create-sample-findings`, sample generation including attack-sequence types, the `[SAMPLE]` prefix and `"sample": true`