This issue has been assessed as high severity. Review affected configurations immediately.
GuardDuty is the right starting point for AWS threat detection. It ingests CloudTrail management events, VPC Flow Logs, and DNS query logs without requiring any agent deployment, and its threat intelligence integration produces actionable findings on credential misuse, unusual API patterns, and known malicious infrastructure. For most AWS accounts, enabling GuardDuty closes more detection gaps than it creates.
The problem is that “starting point” is not “complete coverage.” Security teams that treat GuardDuty as the ceiling of their AWS detection capability are working with blind spots that experienced cloud threat actors know how to use. Understanding exactly where those gaps are is the prerequisite for fixing them.
What GuardDuty Actually Covers
Before listing the gaps, it’s worth being precise about the baseline. Standard GuardDuty coverage includes:
- CloudTrail management events: API calls for resource creation, modification, deletion, and IAM changes
- VPC Flow Logs: Network connection metadata (source/destination IPs, ports, bytes, protocol) without packet content
- DNS logs: Queries made through the Amazon DNS resolver
- Optional protection plans (require explicit enablement and incur additional cost): S3 Protection (S3 data events), EKS Audit Log Monitoring, Lambda Network Activity Monitoring, EC2 and ECS Runtime Monitoring, RDS Login Activity
Many accounts have GuardDuty enabled but have not enabled all protection plans. The gaps below are partly a function of this configuration gap as well as fundamental protocol-level limitations.
Gap 1: AWS-Native Lateral Movement via SSM
AWS Systems Manager Run Command allows privileged principals to execute shell commands on EC2 instances via IAM without opening any network port. From a network perspective, there is no lateral movement to detect: no SMB, no SSH, no unusual outbound connections. The traffic flows through AWS service endpoints and looks identical to routine fleet management operations.
GuardDuty does not have a finding type for SSM-based lateral movement. CloudTrail logs ssm:SendCommand and ssm:StartSession API calls, and the commands executed, but GuardDuty’s anomaly detection does not flag unusual SSM usage patterns by default.
An attacker who has compromised an IAM identity with ssm:SendCommand permissions and ec2:DescribeInstances can enumerate all running instances and execute commands across them without triggering a GuardDuty finding unless the IAM credentials themselves were obtained from a source flagged by threat intelligence.
Fill the gap: Create a CloudWatch metric filter on CloudTrail for ssm:SendCommand and ssm:StartSession calls from IAM principals that don’t normally use SSM. Alert on executions targeting multiple distinct instance IDs within a short window from the same principal. Consider using Service Control Policies to restrict SSM access to federated human identities rather than IAM roles.
Gap 2: EC2 Instance Metadata Without Runtime Monitoring
GuardDuty’s VPC Flow Logs coverage shows that an EC2 instance made an outbound connection, but not what process on that instance made it. Without EC2 Runtime Monitoring (GuardDuty’s agent-based option), an attacker who has established persistence inside an EC2 instance through a web shell, compromised application, or remote code execution can perform reconnaissance, exfiltration, and lateral movement prep while GuardDuty sees only normal-looking traffic patterns.
Runtime Monitoring adds a GuardDuty security agent to EC2 instances that provides process-level visibility. It is not enabled by default, requires explicit opt-in per account or via delegated administrator, and incurs additional cost based on the number of monitored instances.
The coverage gap is real in a large fraction of AWS accounts: EC2 Runtime Monitoring is enabled in fewer than 30% of accounts where standard GuardDuty is active, based on public cloud security posture reporting.
Fill the gap: Enable EC2 Runtime Monitoring (and ECS Container Runtime Monitoring if Fargate workloads are present). For existing fleets, use SSM Distributor to push the GuardDuty agent at scale. If runtime monitoring costs are prohibitive for the full fleet, prioritise instances with public-facing exposure and instances with access to sensitive data stores.
Gap 3: S3 Presigned URL Exfiltration
GuardDuty’s S3 Protection monitors S3 data events when enabled. It detects unusual access patterns, access from known malicious IPs, and anomalous download volumes from within your AWS environment. What it cannot see is data downloaded via presigned URLs from external infrastructure.
A presigned URL grants access to an S3 object for a defined period without requiring AWS credentials at request time. An attacker who has momentary access to an IAM identity with s3:GetObject permissions can generate presigned URLs for any accessible object and exfiltrate data from external infrastructure after the credential is no longer accessible. The download appears as an anonymous HTTPS request to S3 from an external IP, associated with the object’s bucket but not attributable to an IAM identity in GuardDuty’s data plane.
CloudTrail logs the s3:GetObject calls used to generate presigned URLs as management API calls. GuardDuty does not generate a specific finding for unusual presigned URL generation volume.
Fill the gap: Create a CloudWatch alarm on CloudTrail for s3:GetObject with requesterIsAnAWSSERVICE = false and high volume within short windows from a single IAM identity. For sensitive buckets, S3 access logging captures every request including presigned URL downloads with the generating principal’s signature.
Gap 4: Credential Exfiltration via EC2 Instance Metadata v1
GuardDuty has a finding type for credential use from unusual locations (UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration), which triggers when instance profile credentials appear to be used from outside AWS. However, the finding only fires when credentials are used from an external IP. If an attacker exfiltrates credentials via an SSRF on an EC2 instance and uses them from a different EC2 instance within the same AWS region, there is no unusual source IP and no GuardDuty finding.
IMDSv1 allows any process on an EC2 instance (or any server-side request forgery attacker who can reach the metadata endpoint) to retrieve instance profile credentials with a single HTTP request. IMDSv2 requires a session token obtained through a PUT request, which prevents simple SSRF attacks but not malware or application-layer code execution from directly accessing the metadata endpoint.
Fill the gap: Enforce IMDSv2-only access at the EC2 instance level using the HttpTokens: required setting, or enforce it at the account level through a Service Control Policy on ec2:ModifyInstanceMetadataOptions. This eliminates the SSRF credential theft path entirely. Monitor CloudTrail for ec2:ModifyInstanceMetadataOptions calls that remove IMDSv2 enforcement.
Gap 5: CloudTrail Exclusion Filters
CloudTrail supports resource-level logging filters, and GuardDuty’s findings are only as complete as the CloudTrail data it receives. An attacker who gains access to an account’s CloudTrail configuration can add exclusion filters that suppress logging for specific API calls, principals, or resource ARNs. Until that filter is removed, GuardDuty has no data to analyse for the excluded activity.
GuardDuty does generate a finding when CloudTrail is disabled (Stealth:IAMUser/CloudTrailLoggingDisabled). It does not generate a finding when CloudTrail remains enabled but is silently filtered to exclude specific activity.
Fill the gap: Monitor CloudTrail for cloudtrail:PutEventSelectors and cloudtrail:UpdateTrail via a CloudWatch Events rule that alerts on any modification to trail configuration. Lock down permissions to modify CloudTrail to a break-glass identity that is not used for routine operations. Use AWS Config rules to enforce that CloudTrail logging is enabled and unfiltered on critical API categories.
Closing the Gaps: Complementary Controls
No single service covers everything. A layered approach that builds on GuardDuty:
Amazon Security Hub: Aggregates GuardDuty findings with AWS Config compliance findings, Inspector vulnerability findings, and third-party integrations. Provides a single console and enables cross-service correlation.
AWS Security Lake: Ingests CloudTrail, VPC Flow Logs, Route 53 logs, and GuardDuty findings into an OCSF-normalised data lake in your own S3 buckets. Enables custom detection queries using Athena or any OCSF-compatible SIEM without depending on GuardDuty’s built-in finding types. For the gaps described above, Security Lake enables you to write custom detections against raw CloudTrail data.
VPC Traffic Mirroring: Copies packets from EC2 network interfaces to a monitoring appliance or third-party NDR tool. Provides packet-level visibility that VPC Flow Logs don’t, enabling content-based detection for encrypted protocols where the endpoint is known.
GuardDuty Runtime Monitoring: The most impactful single add-on to enable for EC2 workloads, covering process-level activity that VPC Flow Logs cannot surface.
The goal isn’t to replace GuardDuty but to layer controls so that the documented gaps don’t represent unmonitored terrain. An attacker who knows that SSM lateral movement won’t trigger a GuardDuty finding is exploiting a known blind spot. The teams that close those gaps force adversaries to operate in covered territory.