kienbui1995/guardduty-security

AWS GuardDuty Security

When to Use

• Enabling and configuring AWS GuardDuty for threat detection
• Understanding and triaging GuardDuty finding types
• Automating incident response to GuardDuty findings via EventBridge + Lambda
• Managing GuardDuty across multiple AWS accounts (Organization integration)
• Distinguishing GuardDuty from Inspector, Macie, and Security Hub
• Preparing for AWS Certified Security Specialty (SCS-C02) exam

Core Jobs

1. GuardDuty Data Sources

GuardDuty continuously analyzes these sources for threats:

| Data Source | What It Detects | Enabled By Default | |-------------|----------------|-------------------| | AWS CloudTrail management events | API call anomalies, suspicious CLI/console activity | Yes | | AWS CloudTrail S3 data events | Suspicious S3 object access patterns | Optional (S3 Protection) | | VPC Flow Logs | Network anomalies, port scanning, crypto mining traffic | Yes | | DNS logs | DNS-based data exfiltration, C2 communication | Yes (EC2 only, via AWS DNS resolver) | | EKS audit logs | Suspicious Kubernetes API activity, privilege escalation | Optional (EKS Protection) | | ECS runtime | Container-level threat detection | Optional (ECS Runtime Monitoring) | | Lambda network activity | Suspicious outbound network calls from Lambda | Optional (Lambda Protection) | | RDS login events | Brute force, anomalous authentication | Optional (RDS Protection) | | Malware Protection | Malware in EC2 EBS volumes or uploaded S3 objects | Optional |

GuardDuty does NOT require you to enable VPC Flow Logs or CloudTrail separately — it accesses these directly without storing logs in your account.

2. Finding Types

Format: ThreatPurpose:ResourceAffected/ThreatFamilyName.DetectionMechanism!Artifact

| Category | Example Finding | Meaning | |----------|----------------|---------| | Reconnaissance | Recon:EC2/PortProbeUnprotectedPort | Port scanning on EC2 | | Backdoor | Backdoor:EC2/C&CActivity.B | EC2 communicating with known C2 server | | CryptoCurrency | CryptoCurrency:EC2/BitcoinTool.B | EC2 mining cryptocurrency | | UnauthorizedAccess | UnauthorizedAccess:EC2/SSHBruteForce | SSH brute force attempts | | UnauthorizedAccess | UnauthorizedAccess:IAMUser/TorIPCaller | API calls from Tor exit node | | Stealth | Stealth:IAMUser/CloudTrailLoggingDisabled | CloudTrail disabled (cover tracks) | | Policy | Policy:S3/BucketPublicAccessGranted | S3 bucket made public | | Execution | Execution:EC2/MaliciousFile | Malware detected on EC2 | | Exfiltration | Exfiltration:S3/ObjectRead.Unusual | Unusual volume of S3 reads | | PenTest | PenTest:IAMUser/KaliLinux | API calls from Kali Linux machine |

Finding severity:

• 🔴 High (7.0–8.9): Active threat, immediate action required
• 🟡 Medium (4.0–6.9): Suspicious activity, investigate
• 🟢 Low (1.0–3.9): Informational, monitor

3. Multi-Account Management

Administrator account = central visibility and control:

• Sees findings from ALL member accounts
• Can enable/disable GuardDuty for member accounts
• Member accounts CANNOT disable GuardDuty themselves
• Single GuardDuty administrator account across Organization

Setup via AWS Organizations (recommended):

1. Designate GuardDuty administrator account (Security/Audit account)
2. Auto-enable for all current + future member accounts
3. All findings flow to administrator account

Manual invitation method (non-Organizations):

• Administrator sends invitation to member account; member accepts

Suppression rules: Filter known-safe findings by account, region, resource type, or finding type. Suppressions apply to future findings. Suppressed findings still stored but not active.

4. Automated Incident Response

Pattern: GuardDuty finding → EventBridge rule → Lambda/SNS/SQS → automated action

GuardDuty finding
    ↓
EventBridge rule (filter by severity, finding type)
    ↓
SNS topic → email/Slack notification
Lambda function → automated remediation
    ↓
Actions: block IP via NACL, isolate SG, disable IAM key, snapshot EBS

EventBridge rule for high-severity findings:

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {
    "severity": [{"numeric": [">=", 7.0]}]
  }
}

Common automated responses:

• Crypto mining finding → block outbound traffic to mining pool IPs via NACL
• Compromised IAM key → disable access key via iam:UpdateAccessKey
• Malicious EC2 → isolate by replacing SG with deny-all forensic SG
• C2 communication → isolate EC2 to forensic VPC, take EBS snapshot for analysis

5. S3 Protection and Malware Protection

S3 Protection:

• Analyzes CloudTrail S3 data events for unusual access patterns
• Detects: unusual API callers, access from new geographic locations, high-volume data exfiltration
• Enable per-account (not enabled by default even when GuardDuty is enabled)

Malware Protection for EC2:

• Scans EBS volumes attached to EC2 when GuardDuty detects suspicious activity
• Creates EBS snapshot, attaches to GuardDuty-managed scanner instance
• Does not impact running instance performance

Malware Protection for S3:

• Scans objects uploaded to S3 (on new object uploads)
• Creates prefixed/tagged findings for malicious objects

6. Suppression vs Archiving

| Action | Effect | Use When | |--------|--------|---------| | Suppress | Future matching findings not shown in active list | Known-safe activity that generates noise | | Archive | Mark individual finding as reviewed/resolved | Investigated finding; not a real threat | | Trust IP list | IP addresses that GuardDuty never generates findings for | Your pen test IP ranges, internal scanners | | Threat IP list | IP addresses that GuardDuty always flags | Known bad IPs specific to your environment |

Key Concepts

• Threat intelligence feeds — GuardDuty uses AWS-curated threat intelligence (known bad IPs, domains, hashes) + custom lists
• Anomaly detection — ML-based baselines; alerts on deviations from normal behavior (new geographic access, unusual API patterns)
• Finding retention — findings retained for 90 days by default; archive to S3 via EventBridge for longer retention
• GuardDuty delegated administrator — in AWS Organizations, designate specific account to manage GuardDuty for all accounts
• Runtime Monitoring — installs lightweight security agent on EC2/ECS/EKS to detect runtime threats (file access, process execution, network activity)
• Cross-region — GuardDuty is regional; enable in every region where you have resources; aggregate via Security Hub

Checklist

• [ ] GuardDuty enabled in ALL AWS regions (threats don't respect regional boundaries)?
• [ ] Multi-account: GuardDuty administrator account designated in AWS Organizations?
• [ ] S3 Protection enabled (not on by default)?
• [ ] EKS Protection enabled for Kubernetes workloads?
• [ ] EventBridge rules configured to route high-severity findings to incident response?
• [ ] Suppression rules documented and reviewed (know what you're filtering out)?
• [ ] Custom threat IP list added for known external threat feeds?
• [ ] Trust IP list includes pen test IP ranges (to avoid false positives during authorized tests)?

Output Format

• 🔴 Critical — GuardDuty disabled in active regions; high-severity finding (CryptoCurrency, Backdoor, UnauthorizedAccess) with no response; member accounts able to disable GuardDuty (not using Organizations)
• 🟡 Warning — S3 Protection not enabled (S3 threats not detected); no automated response for medium/high findings; suppression rules too broad (hiding real threats)
• 🟢 Suggestion — Security Hub integration to aggregate GuardDuty + Inspector + Macie findings; Runtime Monitoring for deep container/EC2 threat visibility; Detective for investigation of GuardDuty findings

Exam Tips

• GuardDuty = threat detection (behavioral anomalies); Inspector = vulnerability scanning (CVEs, network exposure); Macie = PII/sensitive data discovery in S3 — different tools, different purposes
• GuardDuty does NOT block traffic; use Lambda + NACL/SG for automated blocking in response to findings
• Multi-account: administrator account sees all member account findings; members cannot disable GuardDuty (when enrolled via Organizations)
• CryptoCurrency finding = EC2 communicating with known cryptocurrency mining infrastructure (one of the most common exam questions)
• EventBridge integration = route findings to SIEM, ticketing system (Jira), Slack, or Lambda automation — this is the standard response pattern
• Suppression rules ≠ fixing the threat — only suppress after confirming finding is definitely not a real threat (e.g., authorized pen test activity)
• S3 Protection must be enabled separately — enabling GuardDuty does NOT automatically enable S3 data event analysis
• DNS logs: GuardDuty only analyzes DNS queries going through AWS DNS resolver (Route 53 Resolver); custom DNS servers on EC2 bypass this