GuardDuty

ML-based threat detection monitoring CloudTrail, VPC flow logs, and DNS logs

Amazon GuardDuty is a managed threat detection service that continuously analyzes CloudTrail API logs, VPC Flow Logs, DNS query logs, and other data sources to identify malicious activity and unauthorized behavior in your AWS environment. It uses machine learning, anomaly detection, and integrated AWS threat intelligence to surface findings without requiring you to configure or manage any infrastructure.

How GuardDuty Detects Threats

GuardDuty ingests data from multiple sources and runs it through detection engines that combine rule-based signatures, ML behavioral baselines, and threat intelligence feeds.

Data source	What it detects
CloudTrail management events	Unusual API calls, privilege escalation, disabled logging, public S3 bucket exposure
CloudTrail S3 data events	Suspicious S3 data access patterns, exfiltration from buckets
VPC Flow Logs	Port scanning, C2 communication, crypto mining traffic, unusual outbound connections
DNS logs	Domain generation algorithm (DGA) traffic, requests to known malicious domains, DNS exfiltration
EKS audit logs	Suspicious Kubernetes API activity, container escape attempts
RDS login activity	Brute force and unusual login patterns to Aurora/RDS
Lambda network activity	Lambda functions communicating with known malicious IPs or domains
S3 malware protection	Scans newly uploaded S3 objects for malware

💡

GuardDuty does not see inside encrypted data and does not inspect application-layer traffic. It works entirely from metadata and API event logs. This means it cannot detect application-layer attacks like SQL injection - that is what WAF is for.

Finding Types and Severity Levels

GuardDuty findings are categorized by threat type and assigned a severity from 0.1 (informational) to 8.9 (high). Finding types follow the pattern ThreatPurpose:ResourceTypeAffected/ThreatFamilyName.

Finding example	Severity	What it means
UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B	Medium	Console login from an unusual location
Recon:EC2/PortProbeUnprotectedPort	Low	Port scanning detected against your EC2 instance
CryptoCurrency:EC2/BitcoinTool.B!DNS	High	EC2 instance is making DNS requests associated with crypto mining pools
Backdoor:EC2/C&CActivity.B!DNS	High	EC2 instance calling a known C2 domain
Stealth:IAMUser/LoggingConfigurationModified	Medium	CloudTrail logging was disabled or modified
PrivilegeEscalation:IAMUser/AnomalousBehavior	High	ML model detected unusual privilege escalation pattern
Impact:S3/AnomalousBehavior.Delete	High	Unusual number of S3 delete operations

⚠️

Do not treat all GuardDuty findings as equal. Low severity findings like port probing are common and often benign. Focus your immediate response on High severity findings, particularly anything involving IAM credential compromise, C2 communication, or data exfiltration.

Multi-Account GuardDuty with AWS Organizations

In a multi-account AWS Organization, GuardDuty should be enabled in every account and centrally managed from a delegated administrator account. This aggregates all findings in one place.

bash

# Enable GuardDuty organization auto-enable from management account
aws guardduty update-organization-configuration \
  --detector-id <detector-id> \
  --auto-enable

# List all member accounts and their GuardDuty status
aws guardduty list-members --detector-id <detector-id>

# Get findings from the administrator account (aggregated)
aws guardduty list-findings --detector-id <detector-id> \
  --finding-criteria '{"Criterion": {"severity": {"Gte": 7}}}'

💡

When auto-enable is on, any new account added to the AWS Organization automatically gets GuardDuty enabled within 24 hours. This prevents security blind spots in new accounts created for projects or sandboxes.

Automated Response with EventBridge

GuardDuty emits findings as EventBridge events. You can trigger automated remediation using EventBridge rules that invoke Lambda, SNS, Step Functions, or Systems Manager Automation.

bash

# EventBridge rule to trigger Lambda on high-severity findings
# Rule pattern:
{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {
    "severity": [{"numeric": [">=", 7]}]
  }
}

# Example Lambda response: isolate a compromised EC2 instance
# 1. Identify instance from finding
# 2. Remove from all security groups
# 3. Add to quarantine security group (no inbound/outbound except SSM)
# 4. Create snapshot for forensics
# 5. Notify security team via PagerDuty/Slack
# 6. Optionally: suspend IAM credentials used by instance

Finding type	Automated response
IAMUser/AnomalousBehavior	Disable IAM access keys, notify via SNS
EC2/C&CActivity	Quarantine instance (move to isolated SG), take snapshot
EC2/CryptoCurrency	Terminate or isolate instance, notify team
S3/AnomalousBehavior.Delete	Enable S3 Object Lock temporarily, notify team

🎯

Interview Focus Points

1What data sources does GuardDuty analyze? What is it NOT able to detect?
2Walk me through how you would respond to a GuardDuty finding that an EC2 instance is communicating with a known C2 server.
3How do you set up GuardDuty centrally across all accounts in an AWS Organization?
4What is the difference between a GuardDuty finding and an AWS Config rule violation?
5How would you build an automated response to isolate a compromised EC2 instance based on a GuardDuty finding?
6A GuardDuty finding shows unusual IAM console login from a new geography. What are your next steps?
7How does GuardDuty's ML-based anomaly detection differ from signature-based threat detection?
8What is the pricing model for GuardDuty and what drives cost at scale?