GuardDuty Extended Threat Detection

GuardDuty Extended Threat Detection automatically detects multi-stage attacks that span data sources, multiple types of AWS resources, and time within an AWS account. It correlates multiple events including API activities and GuardDuty findings (called "signals") to identify scenarios that present a potential threat.

Because of the nature of the associated threat scenarios, GuardDuty considers ALL attack sequence finding types as Critical. This reflects the serious nature of multi-stage attacks that typically indicate active compromise.

When you enable Amazon GuardDuty in your account in a specific AWS Region, Extended Threat Detection is also enabled by default. There is no additional cost associated with the usage of Extended Threat Detection.

GuardDuty correlates multiple events, including API activities and GuardDuty findings. These events are called "Signals". Some events are termed "weak signals" because, on their own, they don't present a clear potential threat but become significant when correlated with other activities.

The five attack sequence finding types are: AttackSequence:EKS/CompromisedCluster, AttackSequence:ECS/CompromisedCluster, AttackSequence:EC2/CompromisedInstanceGroup, AttackSequence:IAM/CompromisedCredentials, and AttackSequence:S3/CompromisedData. There is no Lambda-specific attack sequence finding type.

GuardDuty is designed to identify potential in-progress or recent attack behaviors within a 24-hour rolling time window in your account. This allows detection of attack sequences where different stages may occur over several hours.

When correlating events for attack sequences, Extended Threat Detection doesn't consider archived findings, including those that are automatically archived because of suppression rules. This ensures only active, relevant signals contribute to attack sequence detection. You should review existing suppression rules to ensure you're not impacted.

GuardDuty's three foundational data sources are: AWS CloudTrail management events (control plane operations), VPC Flow Logs (network traffic metadata), and Route53 Resolver DNS query logs (DNS queries). These are automatically analyzed when GuardDuty is enabled at no additional cost for the data source access.

For maximum coverage and comprehensive threat detection in EKS, GuardDuty recommends enabling both EKS Protection and Runtime Monitoring. EKS Protection monitors control plane activities through audit logs, while Runtime Monitoring observes behaviors within containers. Together, they create a complete view enabling detection of complex attack patterns.

Weak signals are events in your environment that, on their own, don't present themselves as a clear potential threat. GuardDuty terms individual API activities as weak signals because they don't present themselves as potential threats in isolation. Extended Threat Detection identifies when a sequence of multiple actions (including weak signals) align to potentially suspicious activity.

A typical attack sequence involving S3 data compromise would include: a threat actor gaining unauthorized access to a compute workload, then performing actions such as privilege escalation and establishing persistence, and finally exfiltrating data from an Amazon S3 resource. This represents the multi-stage nature of attacks that Extended Threat Detection identifies.

The AttackSequence:ECS/CompromisedCluster finding uses: Runtime Monitoring for Amazon ECS Fargate, Runtime Monitoring for EC2 Instances in Amazon ECS, and GuardDuty Malware Protection for Amazon EC2. These sources detect malicious processes, communications with malicious endpoints, or cryptocurrency mining behaviors in ECS clusters.

When GuardDuty consumes CloudTrail Global Service Events (like IAM, STS, S3, CloudFront, Route 53) with security value, it replicates those events and processes them in each Region where you have enabled GuardDuty. This helps maintain user and role profiles in each Region, vital for detecting anomalous events.

Instance groups typically represent applications managed through infrastructure-as-code, sharing similar configurations such as Auto-scaling group, IAM instance profile role, AWS CloudFormation stack, Amazon EC2 launch template, AMI or VPC ID. The finding indicates potential compromise across this group of related instances.

EKS Protection through audit logs allows GuardDuty to correlate EKS audit logs and AWS API activity. It can detect attack sequences where an actor attempts unauthorized access to cluster secrets, modifies Kubernetes role-based access control (RBAC) permissions, and creates privileged pods. Container-level behaviors like cryptomining are detected by Runtime Monitoring instead.