Attack Sequence Correlation: What GuardDuty's Five New Indicators Teach CTEM Teams

TL;DR

On May 20, 2026, Amazon GuardDuty Extended Threat Detection began attaching five new indicator types to its attack sequence findings: VULNERABILITY, MALICIOUS_PACKAGE, REACHABILITY, MISCONFIGURATION, and SENSITIVE_DATA. None of these is a detection on its own. Each is context — the resource-state facts that decide whether a weak runtime signal is noise or the middle of a live intrusion. The same discipline applies to external and internal exposure: collect weak signals at scale, then correlate them with exploitability, reachability, and business context before anything reaches an analyst queue. The takeaway is blunt: your detection quality is bounded by your exposure context, not by your signal volume.

What this is

Attack sequence correlation is the practice of grouping individually weak or ambiguous security observations into a single higher-confidence finding, because the combination crosses a credibility threshold that no individual observation reaches on its own.

Three terms matter:

• Signal — any event a detection system evaluates: a process invocation, a pod exec, a syscall pattern, a CVE present on a host, a publicly readable bucket.
• Weak signal — a signal that does not, by itself, indicate malicious intent. A single unpatched CVE tells you a vulnerability exists; it does not tell you anyone is exploiting it.
• Anchor — a resource-state fact that supplies the missing context. Internet reachability is an anchor. A high EPSS score is an anchor. Sensitive data sitting on the same resource is an anchor.

Correlation is not aggregation. Aggregation gives you a longer list. Correlation gives you a narrative: this host is internet-reachable, runs a package with a known malicious indicator, still has IMDSv1 enabled, holds sensitive data, and just executed an unusual process. Individually, four of those five are housekeeping items. Together they are an incident.

Why it matters

Security teams have spent a decade buying more signal sources and a decade complaining about the resulting noise. The GuardDuty update is evidence the industry is finally optimizing in the other direction: fewer, better findings.

The operational math is straightforward. If 100% of raw findings land in an analyst queue, the analyst triages everything, and the real intrusion arrives at position 400 of 1,200. If a correlation layer promotes only combinations that cross a threshold, the same intrusion surfaces as one CRITICAL finding with its supporting evidence already attached. AWS reported that net-new attack-sequence findings on the runtime-process surface rose to roughly one in four prioritized runtime-process sequences, while network-IOC findings barely moved — a useful illustration that correlation adds the most value where signals were weakest, not where they were already clear.

For CTEM programs, the parallel is exact. External attack surface management produces enormous volumes of low-grade observations: an exposed admin panel, a staging subdomain, a TLS misconfiguration, a JavaScript bundle containing a live API key, an unauthenticated API route. Each is a finding. Few are incidents. The value sits in the correlation — this endpoint is reachable, this service version has a KEV-listed exploit, this credential is still valid, this asset supports a revenue system.

How it works

Real intrusions are sequences, not events. A representative cloud-native chain looks like this:

1. Exposure — an internet-reachable workload, an over-permissive IAM role, or a vulnerable dependency gets published or discovered.
2. Access — the attacker uses a public exploit, stolen credentials, or a malicious package to gain a foothold.
3. Reconnaissance in situ — the attacker enumerates the instance metadata service, reads environment variables, or lists cloud storage to see what the workload can reach.
4. Privilege escalation — a misconfigured role, a permissive policy, or a container escape widens access.
5. Impact — exfiltration, crypto-mining, or lateral movement into adjacent workloads and accounts.

Every step produces signals. Every step also produces low-confidence signals, because legitimate workloads do similar things. Container execs happen during incident response. Processes spawn at deploy time. Packages get installed by CI. That is precisely why the correlation threshold matters: without resource-state anchors, a sequence surfaces as eleven disconnected findings spread across eight days — the pattern AWS described in its EKS example.

The defensive implication: you cannot out-detect this with volume. You have to attach context. And most of the context that matters — reachability, exploit likelihood, misconfiguration, sensitive data — is exposure context. It belongs in your CTEM program as much as in your runtime detection.

Detection and response

Hypothesis: a weak runtime signal is only actionable when the resource it touches is reachable, exploitable, misconfigured, or holds sensitive data — so test whether the exposure facts are joined to the finding at evaluation time.

Good telemetry for attack-sequence correlation has four properties.

Weak signals are retained, not discarded. Runtime process events, pod execs, and syscall patterns are noisy, but they are the raw material of a sequence. Dropping them to reduce noise destroys the correlation you will need later. Retain them cheaply, index them by resource, and keep them queryable for at least your longest realistic dwell time.

Resource-state context is joined at evaluation time. A finding should carry its asset's exposure facts inline: is it internet-reachable, what CVEs are present with what EPSS scores, is it publicly exposed, does it hold sensitive data, does it deviate from baseline configuration. If an analyst has to pivot through three consoles to assemble that picture, you have not correlated — you have documented.

Exploit likelihood is a first-class field. CVSS describes inherent severity. EPSS estimates the probability that a published CVE will be exploited in the wild within 30 days. For response prioritization, a medium-CVSS vulnerability with a high EPSS score on a reachable host deserves attention before a critical-CVSS finding on an isolated one.

Promotions and dismissals are both logged. You need to know how often a correlation rule fired, how often it was confirmed, and how often it was closed as benign. Without dismissal telemetry you cannot tune a threshold, and an untuned threshold becomes a brand-new noise source.

What to do

1. Inventory the context you already generate. Most organizations already run vulnerability scanning, cloud posture management, storage discovery, and reachability analysis for their own reasons. The GuardDuty update works because those outputs are joined. Map your equivalents before buying anything new.
2. Normalize exposure context into one queryable store. Domains, IPs, services, technologies, ownership, environment (prod versus non-prod), data sensitivity, and reachability should live somewhere both detection and vulnerability workflows can query.
3. Require reachability before severity. An unreachable host with a critical CVE is a patch backlog item. A reachable host with a medium CVE can be an incident. Encode that distinction in scoring rather than in analyst intuition.
4. Weight exploit likelihood alongside severity. Treat EPSS and the CISA KEV catalog as ranking inputs for remediation queues, not as trivia in a quarterly report.
5. Insert a validation gate before the SOC queue. Define explicit criteria — reachable, exploitable, evidence of a live path — that promote a finding to an alarm. Everything else stays in the exposure backlog where it belongs.
6. Write the playbook before the alert. For each indicator type, decide who responds, what evidence they pull, and what containment looks like. A CRITICAL finding with no owner is a dashboard decoration.
7. Instrument the prerequisites. Correlation only works when the contributing sources are enabled and current. Track coverage of scanning agents, reachability analysis, and storage discovery as first-class metrics.
8. Measure precision, not just volume. Track findings promoted per week, the confirmed-true rate among them, and mean time from promotion to containment. If promoted volume rises while the confirmed rate falls, your threshold is too loose.
9. Revalidate continuously. Reachability, configuration, and exploitability change daily. A correlation decision made on last quarter's asset state is a guess with a timestamp.

FAQ

What are the five new GuardDuty Extended Threat Detection indicators? VULNERABILITY (CVE list from Amazon Inspector with CVSS severity and EPSS exploit-likelihood scores), MALICIOUS_PACKAGE (Amazon Inspector MAL-* package indicators), REACHABILITY (Amazon VPC Reachability Analyzer — whether the host or cluster is reachable from the internet), MISCONFIGURATION (AWS Security Hub posture controls, such as IMDSv1 still enabled, overly permissive admin policies, or publicly accessible Amazon S3 buckets), and SENSITIVE_DATA (Amazon Macie). They appear on the Indicators tab of an attack-sequence finding and in the GetFindings JSON.

What is a weak signal in threat detection? An observation that is individually ambiguous. A process spawning at 3 a.m. is weak. A container exec is weak. An unpatched CVE is weak. Weak signals become strong findings only when correlated with resource-state context that makes the combination unlikely to be benign.

Does GuardDuty replace a CTEM platform? No. GuardDuty Extended Threat Detection correlates runtime and resource-state signals inside your AWS accounts. A CTEM platform covers the external and internal attack surface — what is exposed, what is reachable, what is exploitable, and what to fix first — across cloud and non-cloud assets. They are complementary: exposure context improves detection, and detection context improves prioritization.

Is CTEM just vulnerability scanning with a different name? No. A scanner produces signals at a point in time. CTEM is a continuous loop: discover the attack surface, prioritize by exploitability, validate what actually matters, remediate, then re-measure. Scanning is one input to that loop. The validation gate and the prioritization logic are what separate an exposure management program from a scan report.

How do EPSS and CVSS differ, and which should drive response? CVSS describes the inherent severity of a vulnerability. EPSS estimates the probability that a published CVE will be exploited in the wild in the next 30 days, on a scale from 0 to 1. For incident response, EPSS is generally the more useful number because it predicts activity rather than potential. Use both: EPSS tells you what is likely to be attacked, reachability tells you whether you can be attacked.

What is the difference between reachability and exploitability? Reachability asks whether an attacker can route to the asset. Exploitability asks whether a viable technique exists to abuse it. A host can be reachable but unexploitable (hardened, no known technique), or exploitable but unreachable (air-gapped, behind a strong control). Correlation needs both signals before it promotes anything.

How do you measure whether correlation is actually reducing noise? Track four numbers: total raw findings, findings promoted past the validation gate, confirmed-true rate among promoted findings, and mean time from promotion to containment. Falling promoted volume with a stable or rising confirmed rate means the threshold is working.

Can mid-market teams do attack sequence correlation without a full SIEM? Yes, in a reduced form. Start by joining the context you already own — asset inventory, vulnerability data, exposure status — and apply a simple gate: reachable plus exploitable plus sensitive equals escalate. You will not cover every sequence, but you will stop treating a raw scanner feed as a threat feed.

Where this fits in a program

Correlation only pays off when the exposure facts are already collected. An attack surface inventory across domains, IPs, services, and technologies keeps that context current, and validation ensures a scanner hit is not treated as proof. API surface testing and deeper web application testing cover the layers where most reachable exposure lives. Trusteed CTEM runs that loop continuously so detection and prioritization draw on the same evidence.

Sources

• Trusteed CTEM platform — continuous threat exposure management for external and internal attack surface.
• Trusteed app — scan plans, findings, validation gates, and reporting.
• GuardDuty Extended Threat Detection: five new indicators — the source update from the AWS Security Blog.
• FIRST EPSS — the Exploit Prediction Scoring System model and how to interpret scores.
• CISA Known Exploited Vulnerabilities Catalog — exploited-in-the-wild evidence for prioritization.
• NIST SP 800-40 Rev. 4 — enterprise patch and vulnerability management guidance.
• OWASP Vulnerability Management Guide — practical program design for application and API exposure.