Amazon GuardDuty

Amazon GuardDuty: Comprehensive Guide for AWS Security Specialty

Amazon GuardDuty: Threat Detection and Incident Response

Why Amazon GuardDuty Is Important

In modern cloud environments, threats can emerge from countless vectors — compromised credentials, unauthorized access, cryptocurrency mining, data exfiltration, and more. Manually monitoring all AWS account activity for suspicious behavior is virtually impossible at scale. Amazon GuardDuty addresses this critical gap by providing an intelligent, always-on threat detection service that continuously analyzes your AWS environment without requiring you to deploy or manage any infrastructure.

For the AWS Security Specialty exam, GuardDuty is one of the most heavily tested services. It sits at the intersection of threat detection, incident response, and security monitoring — all core domains of the exam. Understanding GuardDuty deeply is essential for passing the certification.

What Is Amazon GuardDuty?

Amazon GuardDuty is a managed threat detection service that continuously monitors your AWS accounts and workloads for malicious activity and unauthorized behavior. It uses machine learning, anomaly detection, and integrated threat intelligence feeds to identify potential threats.

Key characteristics:
- Fully managed: No infrastructure to deploy, no software to install, no agents required
- Continuous monitoring: Operates 24/7, analyzing billions of events
- Intelligent detection: Uses ML models, anomaly detection, and third-party threat intelligence
- Regional service: Must be enabled in each AWS Region individually
- Multi-account support: Integrates with AWS Organizations for centralized management
- Pay-per-use pricing: Charged based on the volume of data analyzed

How Amazon GuardDuty Works

1. Data Sources

GuardDuty analyzes several data sources to detect threats. Understanding these is critical for the exam:

- AWS CloudTrail Management Events: Monitors API calls made to your AWS account (e.g., creating IAM users, modifying security groups, launching EC2 instances). These capture control plane activities.

- AWS CloudTrail S3 Data Events: Monitors S3 object-level API operations such as GetObject, PutObject, ListObjects, and DeleteObject to detect suspicious activity against your S3 buckets.

- VPC Flow Logs: Analyzes network traffic metadata (not packet content) flowing to and from your EC2 instances, including IP addresses, ports, protocols, and traffic volume.

- DNS Logs: Analyzes DNS queries made by EC2 instances through AWS DNS resolvers to detect communication with known malicious domains.

- EKS Audit Logs: Monitors Kubernetes audit logs from Amazon EKS clusters to detect potentially suspicious activities in containerized workloads.

- RDS Login Activity: Monitors login attempts to Amazon RDS databases (initially supporting Amazon Aurora) to detect anomalous login behavior.

- Lambda Network Activity: Monitors network activity from AWS Lambda functions to detect potentially malicious communication.

- EBS Volume Data (Malware Protection): Scans EBS volumes attached to EC2 instances and container workloads for malware when GuardDuty detects suspicious behavior.

- S3 Logs for Malware Protection: Scans newly uploaded objects to S3 buckets for malware.

Important: GuardDuty does not need you to enable VPC Flow Logs, CloudTrail, or DNS logging independently. GuardDuty pulls data from these sources directly and independently from your own configurations of these services.

2. Detection Mechanism

GuardDuty uses three primary methods to detect threats:

- Threat Intelligence Feeds: AWS integrates feeds from CrowdStrike, Proofpoint, and AWS's own threat intelligence to identify known malicious IP addresses, domains, and indicators of compromise (IOCs).

- Machine Learning: ML models establish a baseline of normal activity in your account and then flag deviations that could indicate compromise.

- Anomaly Detection: Statistical analysis identifies unusual patterns in API calls, network traffic, and DNS queries.

3. Finding Types

GuardDuty generates findings when it detects suspicious activity. Findings are categorized by the resource type and threat purpose. The naming convention follows this pattern:

ThreatPurpose:ResourceTypeAffected/ThreatFamilyName.DetectionMechanism!Artifact

Examples:
- Recon:EC2/PortProbeUnprotectedPort — An EC2 instance has an unprotected port being probed by a known malicious host
- UnauthorizedAccess:IAMUser/MaliciousIPCaller.Custom — An API was invoked from a custom threat list IP address
- CryptoCurrency:EC2/BitcoinTool.B!DNS — An EC2 instance is querying a domain associated with Bitcoin mining
- Trojan:EC2/BlackholeTraffic — An EC2 instance is communicating with a black hole IP address
- Exfiltration:S3/MaliciousIPCaller — S3 API calls were made from a known malicious IP

Threat Purpose Categories include:
- Backdoor — Resource is compromised and can be used as a backdoor
- Behavior — Activity inconsistent with established baselines
- CryptoCurrency — Cryptocurrency mining activity detected
- DefenseEvasion — Activity suggesting evasion of security controls
- Discovery — Activity suggesting reconnaissance of your systems
- Exfiltration — Data theft attempts detected
- Impact — Activity that may impact the availability of resources
- InitialAccess — Attempt to gain initial unauthorized access
- PenTest — Activity from known penetration testing tools
- Persistence — Attempt to maintain unauthorized access
- Policy — Account behavior violating security best practices
- PrivilegeEscalation — Attempt to gain higher-level permissions
- Recon — Reconnaissance activity detected
- Stealth — Activity to hide malicious actions
- Trojan — Software acting as a Trojan
- UnauthorizedAccess — Unauthorized access attempt detected

4. Finding Severity Levels

Each finding has a severity score from 0.1 to 8.9:
- Low (0.1 - 3.9): Suspicious activity that did not compromise your resource but may indicate reconnaissance
- Medium (4.0 - 6.9): Suspicious activity that deviates from normal behavior, such as unusual API calls or unexpected traffic
- High (7.0 - 8.9): Resource is compromised and actively being used for unauthorized purposes (e.g., cryptocurrency mining, data exfiltration)

5. Architecture and Integration

GuardDuty integrates deeply with the AWS ecosystem for automated response:

- Amazon EventBridge (CloudWatch Events): GuardDuty findings can be sent to EventBridge to trigger automated responses. This is the primary integration point for automation.

- AWS Lambda: Use Lambda functions triggered by EventBridge rules to automate remediation (e.g., isolating an EC2 instance by changing its security group, revoking IAM credentials, blocking IP addresses in NACLs or WAF).

- AWS Security Hub: GuardDuty findings are automatically sent to Security Hub for centralized security findings management.

- Amazon Detective: Investigate GuardDuty findings in detail using Amazon Detective for root cause analysis.

- AWS Step Functions: Orchestrate complex incident response workflows triggered by GuardDuty findings.

- Amazon SNS: Send notifications to security teams via SNS topics triggered through EventBridge.

- Amazon S3: Export findings to S3 for long-term storage and analysis. Findings are encrypted using a KMS key that you configure.

6. Multi-Account Management

GuardDuty supports multi-account management through two methods:

- AWS Organizations integration (recommended): A designated GuardDuty delegated administrator account can automatically enable and manage GuardDuty across all member accounts in the organization. This is the preferred approach.

- Invitation-based: A GuardDuty administrator account sends invitations to other AWS accounts. Those accounts must accept to become members. This is the legacy approach.

The administrator account can view and manage findings from all member accounts, configure suppression rules, and manage trusted IP lists and threat lists across the organization.

7. Trusted IP Lists and Threat Lists

- Trusted IP Lists: Whitelist of IP addresses that you trust. GuardDuty will not generate findings for activity from these IPs. Only the administrator account can manage trusted IP lists. You can have only one trusted IP list per account per Region.

- Threat IP Lists: Custom lists of known malicious IP addresses. GuardDuty will use these in addition to its built-in threat intelligence. You can have up to six threat lists per account per Region.

8. Suppression Rules

Suppression rules allow you to filter and automatically archive findings that match specific criteria. This is useful for reducing noise from known benign activities. Suppressed findings are still generated and stored but are automatically marked as archived. They do not appear in the current findings list and do not trigger EventBridge notifications.

9. GuardDuty Malware Protection

GuardDuty Malware Protection extends detection capabilities by scanning EBS volumes for malware:

- GuardDuty-initiated malware scan: Automatically triggered when GuardDuty detects suspicious behavior on an EC2 instance or container workload. GuardDuty creates a snapshot of the EBS volume, scans it in an isolated AWS-managed account, and generates findings if malware is detected.

- On-demand malware scan: You can manually initiate a scan on any EC2 instance.

- S3 Malware Protection: Automatically scans newly uploaded S3 objects for malware and can tag objects with their scan status.

Important: Malware Protection scans snapshots — it does not scan the live EBS volume. The original instance is not affected by the scanning process.

10. GuardDuty and S3 Protection

S3 Protection monitors CloudTrail S3 data events to detect suspicious activity against your S3 buckets, including:
- Access from unusual locations
- Disabling of bucket policies or ACLs that open buckets to the public
- API call patterns consistent with data discovery or exfiltration
- Access from known malicious IP addresses

11. GuardDuty Runtime Monitoring

GuardDuty Runtime Monitoring provides runtime threat detection for EKS, ECS (Fargate), and EC2 workloads. It deploys a GuardDuty security agent that monitors OS-level events, including process execution, network connections, and file access to detect runtime threats like privilege escalation, container escape, and unauthorized access.

Common Exam Scenarios and Solutions

Scenario 1: Automate response to compromised EC2 instance
Solution: GuardDuty finding → EventBridge rule → Lambda function → Isolate EC2 instance (modify security group to block all traffic, create snapshot for forensics, tag the instance)

Scenario 2: Detect cryptocurrency mining
Solution: GuardDuty automatically detects this via DNS logs (queries to mining pool domains) and VPC Flow Logs (traffic to known mining IPs). Finding type: CryptoCurrency:EC2/BitcoinTool.B!DNS

Scenario 3: Centralize threat detection across an organization
Solution: Enable GuardDuty with AWS Organizations, designate a delegated administrator account, auto-enable for all accounts and Regions

Scenario 4: Detect compromised IAM credentials
Solution: GuardDuty monitors CloudTrail for anomalous API activity and generates findings like UnauthorizedAccess:IAMUser/MaliciousIPCaller or Discovery:IAMUser/AnomalousBehavior

Scenario 5: Export findings for compliance and long-term storage
Solution: Configure GuardDuty to export findings to S3. Findings are encrypted using a KMS key. Set up S3 lifecycle policies for retention management.

Scenario 6: Detect potential data exfiltration from S3
Solution: Enable S3 Protection in GuardDuty. Findings such as Exfiltration:S3/MaliciousIPCaller or Exfiltration:S3/AnomalousBehavior will be generated.

---

Exam Tips: Answering Questions on Amazon GuardDuty

1. GuardDuty is the go-to answer for threat detection. If an exam question asks about detecting threats, unauthorized behavior, malicious activity, or anomalous behavior in AWS — GuardDuty is almost always the correct answer. Do not confuse it with AWS Config (compliance), Inspector (vulnerability assessment), or Macie (data classification).

2. Know the data sources. A very common question type will ask what data source GuardDuty uses to detect a specific type of threat. Remember: CloudTrail for API activity, VPC Flow Logs for network traffic, DNS logs for domain queries. If the question is about S3 object-level access, the answer is CloudTrail S3 Data Events.

3. GuardDuty does NOT require you to independently enable VPC Flow Logs, CloudTrail, or DNS logging. GuardDuty accesses these data sources independently. If a question implies you need to enable these first, that answer option is likely wrong.

4. Remember: GuardDuty is a Regional service. It must be enabled in each Region where you want monitoring. For organization-wide deployment, use the delegated administrator approach with AWS Organizations and enable auto-provisioning across all Regions.

5. EventBridge is the integration point for automation. Almost every question about automating a response to a GuardDuty finding will involve EventBridge (or CloudWatch Events) triggering a Lambda function. Know this pattern cold.

6. GuardDuty does not remediate — it detects. GuardDuty only generates findings. You must build remediation workflows yourself using EventBridge + Lambda, Step Functions, or other automation tools. If a question asks about automated remediation, look for the GuardDuty → EventBridge → Lambda pattern.

7. Understand suppression rules vs. trusted IP lists vs. disabling. If the question is about reducing false positives from known safe IPs, the answer is trusted IP lists. If it's about filtering specific finding types, the answer is suppression rules. If it's about stopping all GuardDuty activity, the answer is to suspend or disable the service (which deletes all findings and configurations).

8. Know the difference between suspending and disabling. Suspending GuardDuty stops analysis but retains your configurations, findings, and settings. Disabling GuardDuty permanently deletes all findings, configurations, trusted IP lists, and threat lists. For the exam, if they want to temporarily stop monitoring, suspend. If they want to permanently remove everything, disable.

9. Findings export requires a KMS key. When configuring S3 export, you must specify a KMS key for encryption. The S3 bucket must have a policy that grants GuardDuty permissions to put objects and the KMS key policy must allow GuardDuty to encrypt.

10. Multi-account: Organizations > Invitations. If the question mentions AWS Organizations, the answer will involve delegated administrator. If it mentions accounts outside the organization, it will involve the invitation method.

11. GuardDuty + Detective for investigation. If the question asks about investigating or performing root cause analysis on a GuardDuty finding, Amazon Detective is the answer. GuardDuty detects, Detective investigates.

12. Cryptocurrency mining is a classic GuardDuty use case. If you see any question about detecting crypto mining on EC2 instances, GuardDuty is the answer. It detects this through both DNS logs (mining pool domain queries) and VPC Flow Logs (traffic to known mining IPs).

13. Malware Protection creates snapshots. GuardDuty Malware Protection does not scan live volumes. It creates EBS snapshots and scans them in an isolated environment. The scanning does not impact the running instance's performance.

14. Understand what GuardDuty is NOT. It is not a WAF, not a firewall, not a vulnerability scanner (that's Inspector), not a data classification tool (that's Macie), and not a compliance tool (that's AWS Config). It is purely a threat detection and monitoring service.

15. Cost considerations. GuardDuty charges based on the volume of data analyzed (CloudTrail events, VPC Flow Logs, DNS queries, etc.). If a question asks about cost optimization for GuardDuty, consider that the 30-day free trial exists for new enablement and that you can estimate costs using the GuardDuty usage page before enabling additional protection plans.

16. Remember the one trusted IP list limit. You can only have one trusted IP list per account per Region (but it can contain many IP addresses and CIDR ranges). You can have up to six threat intelligence lists per account per Region.

17. GuardDuty and Security Hub. Findings flow automatically to Security Hub when both are enabled. If a question asks about centralizing findings from multiple security services, Security Hub is the aggregator, and GuardDuty is one of the producers.