Threat detection with GuardDuty
GuardDuty foundational sources and protection plans, Extended Threat Detection attack sequences, finding types and severity, suppression rules, threat lists and organization-wide rollout.
Exam tasks: 1.1 (skills 1.1.1 to 1.1.4: monitoring requirements, aggregating security events, detecting anomalous activity)
The decision: which GuardDuty protection plans does this workload need, who administers GuardDuty for the whole organization, and how do you cut noise without blinding the detector?
What GuardDuty sees
- GuardDuty reads its sources through an independent stream. You don't have to turn on a trail, flow logs or Resolver query logging for GuardDuty to analyze them, and turning them on doesn't change what it sees.
- It is Regional. Enable it in every Region, including ones you don't use: attackers love idle Regions.
- It detects only. It never blocks traffic or revokes keys. Blocking is your EventBridge-driven response.
Your own DNS server
DNS-based findings (for example Backdoor:EC2/C&CActivity.B!DNS) come from queries sent to the Amazon-provided
VPC resolver. If instances use a self-managed DNS server, GuardDuty loses that signal. Runtime Monitoring restores
DNS visibility from inside the host, because the agent sees the lookups directly.
Protection plans
| Plan | Data it adds | Turn it on when |
|---|---|---|
| S3 Protection | CloudTrail S3 data events (GetObject, PutObject, DeleteObject) | Buckets hold anything you'd miss. Also unlocks S3 exfiltration attack sequences |
| EKS Protection | Kubernetes audit logs, pulled directly from EKS (no cluster logging needed) | You run EKS and want API-level detections: anonymous access, privileged pods |
| Runtime Monitoring | OS-level process, file and network events from a GuardDuty security agent | You need to see inside hosts and containers: reverse shells, miners, container escape |
| Malware Protection for EC2 | Agentless scan of EBS volumes, started by a suspicious finding or on demand | You want evidence of malware on an instance without installing anything |
| Malware Protection for S3 | Scans newly uploaded objects in chosen buckets, can tag results | Untrusted uploads (user files, partner drops). Usable without the rest of GuardDuty |
| Malware Protection for AWS Backup | Scans EBS snapshots, AMIs and recovery points | You need to prove a restore point is clean before recovery |
| RDS Protection | Login activity for supported Aurora and RDS engines | Brute force or anomalous logins to databases |
| Lambda Protection | Network activity of Lambda functions | Functions that could be abused for mining or C2 traffic |
| AI Protection | CloudTrail data events from Bedrock, Bedrock AgentCore and SageMaker AI | Model invocation abuse, cost harvesting, prompt injection |
- New GuardDuty accounts get every plan except Runtime Monitoring enabled during the 30-day trial. Accounts that enabled GuardDuty before a plan launched don't get the new plan automatically.
- Runtime Monitoring needs the agent. GuardDuty can manage it for you: an EKS add-on, a Fargate sidecar, or Systems Manager for EC2. The agent reaches GuardDuty through a VPC endpoint that GuardDuty creates.
Exam signal
"Detect a reverse shell / crypto-miner process inside a container" means Runtime Monitoring. "Detect access to the Kubernetes API from a Tor exit node" means EKS Protection (audit logs). "Scan files uploaded by customers before processing" means Malware Protection for S3.
Findings: names and severity
Every finding type follows ThreatPurpose:ResourceTypeAffected/ThreatFamilyName.DetectionMechanism!Artifact:
- ThreatPurpose tells you the attacker's goal:
Recon,UnauthorizedAccess,CryptoCurrency,Backdoor,Trojan,Exfiltration,Impact,Persistence,PrivilegeEscalation,DefenseEvasion,Stealth,Policy,Execution,Discovery,PenTest, andAttackSequence. - ResourceType tells you where to look:
EC2,IAMUser,S3,Kubernetes,Runtime,Lambda,RDS. !DNSmeans it came from DNS logs;.Custommeans it matched your threat list.
Worth recognising on sight:
| Finding | What it means | First response |
|---|---|---|
UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS | Role credentials from an instance are being used from outside AWS | Revoke the role's active sessions, then investigate the instance |
CryptoCurrency:EC2/BitcoinTool.B!DNS | Instance resolves mining pool domains | Isolate the instance, snapshot for forensics |
Stealth:IAMUser/CloudTrailLoggingDisabled | Someone stopped or deleted a trail | Restart logging, find the principal, check SCPs |
Policy:IAMUser/RootCredentialUsage | Root user credentials called an API | Confirm it was planned, review root MFA |
Recon:EC2/PortProbeUnprotectedPort | Internet hosts probing an open port | Tighten the security group if the port shouldn't be public |
Exfiltration:S3/AnomalousBehavior | Unusual volume or pattern of S3 reads | Check who, from where, and which objects |
| Severity | Value | Meaning |
|---|---|---|
| Critical | 9.0 to 10.0 | An attack sequence is in progress or just happened. All attack sequence findings are Critical |
| High | 7.0 to 8.9 | The resource is compromised and actively misused |
| Medium | 4.0 to 6.9 | Behaviour deviates from the baseline and may mean compromise |
| Low | 1.0 to 3.9 | An attempt that didn't succeed, such as a blocked scan |
Extended Threat Detection
- On by default wherever GuardDuty is on, at no extra cost. You can't really "enable" it; you feed it by turning on more protection plans.
- It correlates signals (API calls, weak signals that aren't findings on their own, and existing findings) across sources and time, within one account, and raises a single attack sequence finding.
- Attack sequence types include
AttackSequence:IAM/CompromisedCredentials,AttackSequence:S3/CompromisedData,AttackSequence:EKS/CompromisedCluster,AttackSequence:ECS/CompromisedClusterandAttackSequence:EC2/CompromisedInstanceGroup. - Coverage depends on your plans: S3 exfiltration sequences need S3 Protection, EKS sequences need EKS Protection or Runtime Monitoring, ECS and EC2 group sequences lean on Runtime Monitoring, and AI workload signals need AI Protection.
Exam signal
"Reduce alert fatigue from dozens of related Medium findings and see the whole attack as one story" points to Extended Threat Detection and its attack sequence findings, not to a SIEM correlation rule you build yourself.
Tuning: suppression rules, trusted lists and threat lists
- A suppression rule is a saved filter that auto-archives matching new findings. GuardDuty still generates them (you can see them under Archived), but they are not sent to EventBridge, Security Hub, Detective or the S3 export, and they don't start malware scans.
- Keep rules narrow: finding type plus something specific, such as the scanner's AMI ID, a tag on bastion hosts, or your on-premises egress IP.
- Trusted IP lists stop findings for traffic from IPs you own. Threat lists add your own bad IPs and
domains, producing
.Customfindings. - In a multi-account setup, only the administrator account manages suppression rules, trusted IP lists and threat lists. Members can't.
Suppress everything from a noisy resource
Suppressed findings are archived, and Extended Threat Detection ignores archived findings when it builds attack sequences. A broad rule such as "archive all Kubernetes findings" quietly removes the signals that would have revealed a cluster compromise. Suppress specific known-good behaviour only, and only after you've seen the false positive repeat.
Trusted IP list as a suppression tool
Adding your vulnerability scanner's IP to a trusted IP list hides every finding involving that IP, including
real ones if the scanner is ever compromised. A suppression rule scoped to Recon:EC2/Portscan from the scanner
instance is the targeted fix.
Running GuardDuty across an organization
- The management account designates a delegated administrator, normally the security tooling account. Using the management account itself is allowed but goes against least privilege.
- The designation is per Region, and it must be the same account in every Region.
- Auto-enable can apply to
ALLaccounts (existing and new),NEWonly, orNONE, and can be set per protection plan. ChooseALLif the question says "no account may be left out". - Findings from members appear in the admin account. The admin's EventBridge bus gets every member's findings, so one rule there covers the organization in that Region.
- Members can't disassociate themselves or suspend GuardDuty when managed through Organizations. Changing the delegated admin removes the membership links but leaves GuardDuty enabled in members.
- The old invitation method still works for accounts outside the organization, but Organizations is the recommended path.
- Export findings to an S3 bucket for retention beyond 90 days. The export requires a KMS key whose policy lets GuardDuty use it.
Legacy: use protection plans and Runtime Monitoring instead
Older material refers to GuardDuty "data sources" you toggle (S3 logs, Kubernetes logs) and to a separate "EKS Runtime Monitoring" feature. Current GuardDuty groups these as protection plans, and runtime coverage for EKS, EC2 and ECS (including Fargate) is one Runtime Monitoring plan.
Scenarios
A delegated administrator with auto-enable set to ALL covers existing and new accounts, and threat lists are managed centrally by the administrator for all members. StackSets would work for enablement but leave findings scattered and threat lists duplicated. Invitations don't scale and using the management account breaks least privilege. Security Hub only receives GuardDuty findings; it doesn't turn GuardDuty on.
A suppression rule scoped to that finding type and the scanner AMI archives exactly the expected findings, and archived findings aren't sent to EventBridge. A trusted IP list would hide every finding involving those IPs, including real attacks. Dropping all Recon findings hides other scanners, which the SOC explicitly needs. You can't switch off GuardDuty's foundational flow log source per subnet.
Without S3 Protection, GuardDuty sees only management events such as the policy change. S3 Protection adds data events, which lets GuardDuty flag the anomalous download and lets Extended Threat Detection link it to the policy change as one Critical attack sequence. GuardDuty doesn't consume your trails. Macie classifies data but doesn't detect exfiltration. Weekly queries aren't detection.
Further reading
Domain 1 · Detection
16% of the exam. Choosing what to watch, where the logs land, how findings become alerts, and why a monitoring pipeline goes quiet.
Security findings hub
Which AWS security service finds what, how Security Hub and Security Hub CSPM aggregate findings in ASFF and OCSF, where Detective and Security Lake fit, and how to schedule recurring assessments.