AWS GuardDuty Adds Five Indicators to Improve Cloud Attack Detection

AWS GuardDuty Adds Five Indicators to Improve Cloud Attack Detection

Amazon Web Services (AWS) has expanded Amazon GuardDuty Extended Threat Detection with five additional security indicators designed to help identify and prioritize multi-stage attacks across cloud workloads.

Detailed in an AWS Security Blog post published on October 12, 2026, the update brings together security information from Amazon Inspector, Amazon VPC Reachability Analyzer, Amazon Macie, and AWS Security Hub. The indicators provide additional context about vulnerabilities, malicious packages, resource misconfigurations, internet reachability, and potential sensitive-data exposure.

AWS says correlating these indicators with existing GuardDuty activity signals can help turn otherwise inconclusive events into a single, critical-severity attack sequence finding. The five indicator types began appearing in attack-sequence findings on May 20, 2026, according to AWS documentation. Source

The update focuses on Amazon Elastic Compute Cloud (Amazon EC2), Amazon Elastic Container Service (Amazon ECS), and Amazon Elastic Kubernetes Service (Amazon EKS) workloads. It is particularly relevant to security teams that already use the supporting AWS security services and need better context when investigating suspicious activity.

What Is GuardDuty Extended Threat Detection?

Amazon GuardDuty Extended Threat Detection analyzes security signals from multiple sources, resources, and time periods to identify activity that may indicate a coordinated attack.

A single event does not always provide enough evidence to establish a threat. For example, a vulnerability finding shows that a resource contains a vulnerability, but it does not by itself prove that an attacker is exploiting it.

Similarly, an unusual process invocation or container command may not clearly indicate malicious activity when examined in isolation.

Extended Threat Detection correlates these signals and looks for combinations that provide stronger evidence of a potential compromise. When the combined activity crosses its credibility threshold, GuardDuty can present the related evidence as a single attack-sequence finding with critical severity.

The five additional indicators expand the context available to this correlation process. Instead of evaluating runtime activity alone, the service can also consider the affected resource's security posture, software risks, network exposure, and potential sensitive-data presence.

The Five New GuardDuty Indicators

AWS introduced five indicator types that draw on information from its existing security and cloud analysis services.

These indicators appear in the Indicators tab of an attack-sequence finding in the GuardDuty console. They are also available through the GetFindings API response.

The indicators are not independent proof that an attack has succeeded. Their value comes from the additional context they provide when correlated with other suspicious activity.

Which AWS Services Are Required?

The additional indicators depend on findings and resource information from several AWS services. AWS lists the following prerequisites for populating them:

• Amazon Inspector: Enable it on Amazon EC2 and Amazon EKS to supply vulnerability and malicious-package indicators.
  

• AWS Security Hub: Supplies misconfiguration information based on AWS Foundational Security Best Practices controls.
  

• Amazon VPC Reachability Analyzer: Provides reachability information for production VPCs.
  

• GuardDuty Runtime Monitoring: Supplies runtime signals from Amazon EC2, Amazon ECS, and Amazon EKS.
  

• Amazon Macie: Supplies sensitive-data indicators.

Organizations already using these services can benefit from the additional context in their GuardDuty attack-sequence findings. Teams that have not enabled the relevant services may need to review their configuration before all five indicator types can be populated.

AWS describes the update as an integration of existing security signals into Extended Threat Detection, rather than a replacement for the underlying services.

How the Indicators Strengthen Runtime Threat Detection

Runtime monitoring can generate events that are difficult to interpret individually. These may include process invocations, Kubernetes pod execution, or system-call patterns that do not match a known offensive-tool signature.

Without additional context, an isolated event may not meet the threshold for a critical attack-sequence finding.

The new indicators can change that assessment when a suspicious runtime signal occurs on a resource with several other risk factors. AWS gives the example of a host with high-priority unpatched vulnerabilities, a known malicious package, an instance metadata configuration issue, and internet reachability.

When those conditions appear together with suspicious runtime activity, GuardDuty can correlate them into a single CRITICAL attack-sequence finding.

AWS says this approach addresses customer feedback that individual runtime findings can be noisy and difficult to prioritize. In the first week after the indicators launched, the company observed a substantial increase in newly surfaced attack-sequence findings on the runtime-process surface, reaching roughly one in four prioritized runtime-process attack sequences. AWS reported little change on the network indicator-of-compromise surface.

These are AWS's reported observations from its launch sample, not a guarantee of the same results for every customer environment.

Example 1: GuardDuty Identifies a High-Risk Amazon EKS Cluster

AWS describes an observed Amazon EKS scenario involving activity over eight days and eleven different GuardDuty findings.

During that period, GuardDuty recorded 55 EKS audit-log signals involving pod execution, role assumptions, and AssumeRoleWithWebIdentity calls. It also recorded 18 finding-level signals. The activity originated from one external IP address that authenticated as four different IAM identities to the same EKS cluster.

The runtime activity did not match a known malicious execution path, and no unusual-suspicious-tool profile was triggered. Under the previous correlation conditions described by AWS, the activity did not produce a correlated attack-sequence finding.

The new indicators added important resource context:

• Malicious package: Amazon Inspector identified package indicator MAL-2022-4933 on the cluster.

• Vulnerabilities: The cluster had 42 CVEs, including 33 rated critical under CVSS. The five worker nodes had 379 CVEs in total, of which 68 were rated critical by Amazon Inspector.

• Internet reachability: The cluster API endpoint and three of the five worker nodes were internet-reachable.

• Misconfiguration: All five worker nodes still exposed IMDSv1.

The cluster-level vulnerability list included CVE-2022-1471, CVE-2024-4577, CVE-2024-34351, CVE-2025-29927, CVE-2023-44487, and CVE-2022-37434. AWS also reported high EPSS scores for several of these vulnerabilities at the time of the observed findings.

With the additional context, GuardDuty surfaced an AttackSequence:EKS/CompromisedCluster finding with CRITICAL severity. AWS says the finding included four populated indicators and MITRE ATT&CK mappings for Initial Access through External Remote Services, Discovery, and Persistence.

The example illustrates how combining runtime activity with software risk and exposure information can help security teams prioritize a cluster that might otherwise present as several disconnected findings.

Example 2: Cryptomining Activity on Amazon EC2

AWS also describes a group of Amazon EC2 instances communicating with a destination identified by threat intelligence as associated with cryptomining.

In this case, the network indicator already provided strong evidence of suspicious activity. The additional vulnerability information helped responders identify a possible underlying entry point.

The VULNERABILITY indicator highlighted CVE-2007-4559, a Python tarfile path-traversal vulnerability, with an EPSS score around 0.9 on two of the three involved instances.

AWS says the added context made the resulting AttackSequence:EC2/CompromisedInstanceGroup finding more actionable. Rather than only blocking the cryptomining destination, responders could investigate and remediate the relevant vulnerability.

AWS notes that the attack sequence would have been generated even without the vulnerability context because the network evidence was already strong. The added indicator helped with investigation and remediation, rather than creating the original detection.

Vulnerabilities and Malware Indicators Seen in the Launch Sample

AWS also listed vulnerabilities observed on hosts across customer accounts that received the new indicators during the first week after launch.

Examples included:

• CVE-2024-4577: PHP-CGI argument injection on Windows, with an EPSS score above 0.97 in the reported sample.

• CVE-2022-1471: SnakeYAML deserialization, with an EPSS score of 0.94 and critical CVSS severity.

• CVE-2022-37434: zlib heap buffer overflow, with an EPSS score of 0.92.

• CVE-2007-4559: Python tarfile path traversal, with an EPSS score above 0.9.

• CVE-2025-29927: Next.js authentication bypass.

• CVE-2024-34351: Next.js server-side request forgery.

• CVE-2023-44487: HTTP/2 Rapid Reset.

These EPSS values reflect the time when the associated indicators were generated. EPSS is time-sensitive, so current scores may differ.

AWS also reported Linux Fast Reverse Proxy (frp) tooling artifacts on compromised EKS worker nodes, including binaries named kuboard-agent and kuboard-agent-server. Related artifacts were found in container images and on nodes.

This distinction matters for remediation. AWS warns that rebuilding a node from an unpatched Amazon Machine Image may not be sufficient when the relevant tooling remains present in the container image.

The launch sample also included Burp Collaborator out-of-band callback hostnames and the malicious-package indicator MAL-2022-4933 in both EC2 and EKS contexts. AWS described some of these artifacts as potentially associated with separate tools or actors on shared infrastructure, rather than establishing a definitive relationship.

How Security Teams Should Respond to Attack-Sequence Findings

AWS recommends treating attack-sequence findings containing malicious-package indicators and high-priority vulnerabilities with urgency.

Its operational guidance focuses on three actions.

1. Contain exposed resources and address the underlying risks.

Investigate the affected hosts, containers, or clusters. Contain the exposure and remediate the vulnerabilities or malicious packages identified in the finding.

AWS also advises rotating IAM credentials, instance-profile credentials, and IAM Roles for Service Accounts (IRSA)-bound roles that could have been exposed.

2. Prioritize patching with exploit likelihood in mind.

The vulnerability indicator can include both CVSS severity and EPSS scores. CVSS describes vulnerability severity, while EPSS estimates the probability that a published vulnerability will be exploited in the wild over the next 30 days.

AWS recommends using the finding's high-priority vulnerability list to help prioritize remediation instead of relying on CVSS severity alone.

3. Isolate internet-reachable resources when necessary.

Review the REACHABILITY indicator to identify publicly reachable hosts or clusters. If a resource is internet-reachable and has exploitable vulnerabilities, AWS advises isolating it for remediation.

These actions should be guided by the complete finding and the organization's incident-response procedures. The presence of an indicator is valuable context, but responders still need to assess the affected resource and observed activity.

What the Update Means for Cloud Security Teams

The addition of these indicators reflects the importance of combining runtime activity with broader resource context when investigating cloud threats.

For security teams, the practical benefit is a more consolidated view of potential attack sequences. Instead of manually correlating every vulnerability, package alert, configuration issue, and runtime event, responders can use the additional context in GuardDuty findings to help decide which incidents require the most urgent attention.

The update also highlights the value of integrating cloud security services. Amazon Inspector, Security Hub, VPC Reachability Analyzer, Macie, and GuardDuty Runtime Monitoring contribute different information that can become more useful when analyzed together.

Organizations should still review which prerequisite services are enabled, confirm that findings contain the expected context, and maintain incident-response procedures that address both the observed activity and its underlying causes.

Conclusion

AWS GuardDuty Extended Threat Detection now incorporates five additional indicator types to enrich attack-sequence findings with vulnerability, malicious-package, reachability, misconfiguration, and sensitive-data context.

AWS's published examples show how this information can help connect otherwise inconclusive runtime events with broader evidence of risk, including a critical Amazon EKS finding and a cryptomining scenario involving EC2 instances.

For cloud security teams, the main takeaway is the value of correlating signals rather than investigating them in isolation. The new indicators can help prioritize investigations and guide remediation, provided the relevant AWS services are enabled and responders assess the full context of each finding.