GuardDuty Deep Dive: What It Catches, What It Misses, and How to Wire It Up

Amazon GuardDuty is the closest thing AWS offers to a managed threat detection service. Enable it in a region, and within minutes it begins analyzing a continuous stream of data sources looking for indicators of compromise, behavioral anomalies, and known-malicious activity. It requires no agents on most resource types, no log pipelines to configure, and no signature updates to maintain. What it does require is a clear understanding of what it actually covers — and what it deliberately does not.

What GuardDuty analyzes

GuardDuty ingests six categories of data, all pulled directly from AWS’s internal telemetry without requiring you to configure or route the logs yourself:

VPC Flow Logs provide network-layer visibility: which IPs communicated with which ports, bytes transferred, and whether connections were accepted or rejected. GuardDuty uses these to detect port scanning, communication with known command-and-control infrastructure, and cryptocurrency mining traffic patterns.

CloudTrail management events capture every AWS API call — console logins, IAM changes, S3 bucket configuration changes, EC2 instance launches. This is GuardDuty’s primary source for detecting credential abuse, unauthorized access, and unusual IAM activity.

CloudTrail S3 data events — object-level reads and writes — must be explicitly enabled as a GuardDuty protection plan (S3 Protection). Without it, GuardDuty sees bucket configuration changes but not individual GetObject calls. S3 Protection is the data source behind findings like Discovery:S3/AnomalousBehavior and Exfiltration:S3/MaliciousIPCaller.

Route 53 DNS query logs allow GuardDuty to detect DNS-based command-and-control, domain generation algorithm (DGA) traffic, and data exfiltration over DNS (Exfiltration:EC2/DNSDataExfiltration).

EKS audit logs and EKS/EC2/ECS Runtime Monitoring (agent-based) cover container workloads: privilege escalation within pods, anomalous process execution, and container escape attempts.

Finding categories and what triggers them

GuardDuty organizes findings into MITRE ATT&CK-aligned categories. Understanding what triggers each category is essential for tuning and response prioritization.

Recon findings indicate an attacker or automated scanner probing your environment. Recon:EC2/PortProbeUnprotectedPort fires when an EC2 instance’s ports are probed from a known scanning IP — common in internet-exposed instances but worth investigating in private subnets.

Persistence findings indicate an attacker establishing a foothold. Backdoor:EC2/C&CActivity.B fires when an EC2 instance communicates with an IP or domain on GuardDuty’s threat intelligence list for command-and-control. This is a high-confidence, high-severity finding that warrants immediate isolation. UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B fires when a console login originates from a Tor exit node or anonymizing proxy.

CredentialAccess findings are among the highest value. UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS fires when EC2 instance profile credentials (temporary credentials from the metadata service) are used to make API calls from an IP address outside AWS — a near-certain indicator of credential theft via SSRF or metadata service abuse. This finding directly describes the Capital One attack pattern.

Discovery findings fire on behavioral anomalies: an IAM user or role making API calls to enumerate resources at an unusual rate or against services it has never previously accessed. Discovery:S3/AnomalousBehavior and Discovery:IAMUser/AnomalousBehavior use ML baselines built over 14 days of observed behavior — they have a ramp-up period before becoming reliable.

Exfiltration findings correlate data movement with threat intelligence. Exfiltration:S3/MaliciousIPCaller fires when S3 objects are accessed by an IP on GuardDuty’s malicious IP list.

What GuardDuty does not cover

Understanding GuardDuty’s gaps is as important as understanding its coverage.

Application-layer attacks — SQL injection, cross-site scripting, path traversal, authentication bypass — are not visible to GuardDuty. They occur at the HTTP layer, above the network and API telemetry GuardDuty analyzes. AWS WAF with managed rule groups addresses this layer.

S3 object content is not analyzed by GuardDuty. It can detect that a known-malicious IP accessed an S3 object; it cannot detect that the object contains PII or malware. That is Amazon Macie’s domain.

Authorized-principal exfiltration is GuardDuty’s most significant blind spot. If a legitimate IAM role with s3:GetObject permission downloads every object in a sensitive bucket, GuardDuty generates no finding — the activity is indistinguishable from normal authorized access. Detecting this requires behavioral analytics on access volume, which GuardDuty’s S3 anomaly detection partially addresses but does not guarantee.

Misconfigurations — public S3 buckets, overly broad security groups, missing encryption — are not GuardDuty’s domain. AWS Config with managed rules and AWS Security Hub’s FSBP standard cover this.

Severity levels and false positive management

GuardDuty assigns a numeric severity from 0.1 to 10.0, mapped to Low (0.1–3.9), Medium (4.0–6.9), and High (7.0–10.0). In practice, treat High findings as requiring immediate response, Medium as requiring same-day investigation, and Low as feeding a weekly review queue.

Suppress known-good findings using GuardDuty’s suppression rules: match on finding.type, resource.instanceDetails.tags, or service.action.networkConnectionAction.remoteIpDetails.ipAddressV4 to filter out findings from your own security scanning tools or known corporate egress IPs. Add these IPs to GuardDuty’s Trusted IP list (up to 2,000 CIDRs) to prevent findings from being generated for them at all.

The EventBridge automation pattern

The production-grade integration runs: GuardDuty finding → Security Hub (aggregation and normalization) → EventBridge rule → Lambda function. The EventBridge rule matches on finding type and severity:

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Severity": { "Label": ["HIGH", "CRITICAL"] },
      "ProductName": ["GuardDuty"]
    }
  }
}

The Lambda function receives the finding detail and takes automated action based on finding type. For Backdoor:EC2/C&CActivity.B: attach an isolation security group (no inbound or outbound rules), take an EBS snapshot for forensic preservation, and post to the security Slack channel with the instance ID and finding detail. For InstanceCredentialExfiltration: call iam:DeleteAccessKey to revoke the active session and trigger a CloudTrail Lake query to identify all API calls made with the exfiltrated credentials in the prior 24 hours.

Takeaway

GuardDuty is a high signal-to-noise threat detection layer for the network, API, and credential abuse planes. Enable it in every account, enable S3 Protection and EKS Protection as add-on plans, and build the EventBridge-to-Lambda automation before you need it. But maintain clear expectations: GuardDuty does not replace a WAF, does not scan data content, and does not detect misconfigurations. Pair it with Security Hub, Config, Macie, and WAF to cover all four planes — network behavior, API behavior, data sensitivity, and configuration compliance.