GuardDuty Extended Threat Detection has added five new indicators to surface attack sequences

What it is

On May 20, 2026, GuardDuty Extended Threat Detection began attaching five resource-state indicators to attack sequence findings: MALICIOUS_PACKAGE, MISCONFIGURATION, REACHABILITY, SENSITIVE_DATA and VULNERABILITY. They matter mainly for runtime findings on EC2, ECS and EKS. A weak runtime signal that previously stayed below the Critical threshold can now be promoted when it lands on a host with the right exposure.

How it works

The page says AWS reports roughly one in four prioritized runtime-process attack sequences are now net-new. The network IOC surface barely changed. The anchor is a GuardDuty Runtime Monitoring signal, and the indicators add resource-state context to it.

flowchart LR
    A[Weak runtime signal] --> E[CRITICAL attack sequence]
    B[High-EPSS CVEs] --> E
    C[Malicious package] --> E
    D[IMDSv1 / internet-reachable] --> E

The EKS example ran over 8 days with eleven findings. It included 55 EKS_AUDIT_LOGS signals, and one external IP (198.51.100.69) authenticated as four IAM identities. No offensive-tool path matched, so the pre-launch EKS_MALICIOUS_PROCESS rule never fired. These indicators tipped it into AttackSequence:EKS/CompromisedCluster:

• MALICIOUS_PACKAGE: Inspector MAL-2022-4933.
• VULNERABILITY: 42 CVEs on the cluster, including CVE-2022-1471 (EPSS 0.94) and CVE-2022-37434 (EPSS 0.92).
• REACHABILITY: cluster API endpoint and 3 of 5 worker nodes internet-reachable.
• MISCONFIGURATION: IMDSv1 still exposed on all 5 nodes.

The EC2 cryptomining case would have fired anyway. There the indicators only added remediation context: CVE-2007-4559 (Python tarfile, EPSS ~0.9) on two of three instances.

Preconditions

Indicators populate only if the source services are already enabled:

If those services are already on, the indicators appear automatically. Otherwise you get no new context.

What to do

• Check the Indicators tab of attack sequence findings, or GetFindings JSON, for the new values.
• Treat MALICIOUS_PACKAGE plus a high-priority VULNERABILITY as an ongoing risk. Contain the exposure and rotate every IAM credential, instance profile or IRSA-bound role that could have been exposed.
• Patch by EPSS, not CVSS alone. The finding's VULNERABILITY list is already filtered to high-EPSS CVEs. In the EKS case, over 100 worker-node CVEs were mostly low priority by EPSS.
• Isolate internet-reachable hosts that carry exploitable vulnerabilities.
• Hunt for the observed artifacts:
• Linux/frp (Fast Reverse Proxy) used as a C2 tunnel, often disguised as kuboard-agent or kuboard-agent-server. It was also seen under /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/.../usr/bin/.
• Burp Collaborator callbacks matching <35-char base32>[.]oastify[.]com.
• One external IP authenticating as several distinct human IAM identities across EKS, ECS and EC2 in a short window. This was the most common identity signature in the new EKS class.
• Other CVEs seen in the first-week sample: CVE-2024-4577 (EPSS 0.97+), CVE-2025-29927, CVE-2024-34351, CVE-2023-44487.

Caveats

• Because frp binaries sit in the container image and on the node, rebuilding a node from an unpatched AMI is not sufficient remediation.
• EPSS values are point-in-time, so later findings will show current scores.
• The page says the indicators don't change runbooks for attack sequences that already occurred, only new findings.
• The "one in four" figure and the "many customer accounts" claim are AWS's own first-week observations. The page gives no method or sample size.
• The oastify co-occurrence with frp is described only as "probably a second tool or actor."