# Mastering AWS Security - Post 3: GuardDuty – Your Intelligent Threat Hunter ## **Introduction** In today’s cloud-native world, security threats are becoming more sophisticated and evasive. AWS **GuardDuty** is a powerful threat detection service designed to help you monitor and protect your AWS environment using intelligent anomaly detection. Whether you're preparing for the AWS Security Specialty Certification or looking to implement enterprise-grade threat detection, this guide will walk you through everything—from fundamentals to real-world use cases and automation. --- This article is Part 3 of the blog series **“Mastering AWS Security Specialty”** If you missed previous posts please check below. 👉 [**Part 1: Deep Dive into IAM – Core of AWS Security**](https://techbrains.hashnode.dev/mastering-aws-security-specialty-post-1-deep-dive-into-iam-core-of-aws-security) 👉 [**Post 2: CloudTrail – Your First Line of Forensics**](https://techbrains.hashnode.dev/mastering-aws-security-specialty-post-2-cloudtrail-your-first-line-of-forensics) --- ## **What is AWS GuardDuty** **AWS GuardDuty** is a managed threat detection service that continuously monitors your AWS accounts, workloads, and data for malicious or unauthorized behavior using machine learning, anomaly detection, and threat intelligence. > No agents to install. No infrastructure to manage. Pay only for the events analyzed. --- ## Key Features of AWS GuardDuty Let’s explore what makes GuardDuty such a powerful security ally— in high level it offers **Foundational, Extended threat detection** and **Use-case focused protection plans.** These features simplify threat detection at scale and add enterprise-grade intelligence: | **Feature** | **What It Does** | | --- | --- | | **Threat Intelligence Feeds** | Uses curated feeds from AWS, CrowdStrike, and Proofpoint to detect known threats | | **IAM Anomaly Detection** | Flags account hijacking, like logins from unusual geographies or access patterns | | **EKS Protection** | Analyzes audit logs to detect container misuse, privilege escalation, or misconfigurations | | **S3 Protection** | Identifies unusual S3 access, like anomalous reads from sensitive buckets | | **Runtime Monitoring** | Tracks OS-level threats (e.g., file tampering, suspicious processes) across **EC2, ECS** (incl. **Fargate**), and **EKS**. | | **RDS Protection** | Monitors RDS/Aurora login activity for access threats, potential brute-force or lateral movement. | | **Lambda Protection** | Analyzes Lambda network traffic (VPC flow logs) for indicators of compromise like cryptomining or C2 communication. | | **Malware Protection** | Scans **EC2 EBS volumes** and newly uploaded **S3 objects** for malware signatures | | **Security services Integration** | Auto integration with **Security Hub, Detective** and **EventBridge** for further actions | | **Cross-Account Monitoring** | Set up a delegated administrator to manage GuardDuty across AWS Organizations | --- ## How GuardDuty Works (with Architecture Overview) Understanding *how* GuardDuty works is essential to realizing its power in threat detection. Its architecture is designed to be **agentless**, **scalable**, and **cost-efficient**, requiring **no configuration changes** to monitored resources. ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1746500546060/056706e8-f15b-4fe7-a826-82eefdbe209b.png align="center") **Architecture Overview** : At a high level, it 1. Consumes Telemetry data (logs) from AWS Services 2. Examines Traffic and Behavior 3. Generate Findings which are actionable insights. 4. Integrate Findings for Actions Let’s walk through **how it works** using both process logic and architectural components. ### 1\. Telemetry Data Sources GuardDuty passively monitors and ingests telemetry from multiple AWS services **without needing any agent**: | **Data Source** | **Description** | | --- | --- | | **VPC Flow Logs** | Tracks inbound/outbound network traffic at ENI level | | **AWS CloudTrail** | Captures API activity (including management & data events) | | **DNS Logs** | Monitors DNS query logs from **Amazon Route 53** | | **EKS Audit Logs** | Observes control plane events for Kubernetes clusters (add-on) | | **S3 Data Events** | Monitors S3 access logs for suspicious access patterns (add-on) | | **Runtime Events** | OS-level, networking, and file events for EKS, ECS (incl. Fargate), and EC2 (add-on) | | **RDS logins** | Analyzes and profiles RDS login activity for potential access threats (add-on) | | **Lambda network Logs** | Lambda network activity and invocation Logs (incl. VPC flow logs) | | **Malware Protection** | Scans EBS volumes for malware (Optional add-on) | * These logs are not stored in your account — **GuardDuty analyzes them directly** through AWS’s internal streams, so there’s no added logging cost. * These are *read-only*, and GuardDuty does **not** impact your existing workloads. ### 2\. Threat Detection Engine - Traffic and Behavior Analysis Once telemetry is ingested, GuardDuty applies a layered detection strategy: * **Threat Intelligence Feeds** * Uses AWS, **CrowdStrike**, and **Proofpoint** intelligence to detect known **botnets**, **malware domains**, **command-and-control** hosts, and more. * **Machine Learning & Behavioral Analytics** * Learns from account-specific baseline behavior to detect anomalies: * Suspicious API usage (e.g., `CreateAccessKey` from unknown IPs) * Lateral movement across regions or accounts * Escalated privileges, or signs of reconnaissance activity * Unexpected geolocations or sudden spikes in data exfiltration * Anomalous container access or misused system calls for EKS This process happens in near real-time—no manual rule-writing needed. ### 3\. Findings Generation When GuardDuty detects a threat, It generates a **finding**—which is essentially an alert with context. * Findings are categorized by type (e.g., Recon:PortProbe, UnauthorizedAccess:IAMUser, Trojan:EC2) * Each finding includes **severity**, **resource affected**, and **remediation recommendation** ### 4\. Findings Access and Integration You can access and act on GuardDuty findings using: * **AWS Console or CLI/API** * **Amazon EventBridge** → Route findings to Lambda, SNS, SQS, or Step Functions * **AWS Security Hub** → Aggregate findings across services * **Amazon Detective** → Deep dive into security investigations **Example**: Auto-remediate a `Backdoor:EC2/DenialOfService` finding by tagging the instance and isolating it via Lambda. --- ## **Common Findings Categories** GuardDuty uses a rich set of **threat categories** to classify and prioritize detections. These categories map to real-world attacker tactics and help responders quickly identify the type of threat. | **Category** | **Examples** | | --- | --- | | **Recon** | Port scans, probes, or enumeration (e.g., `Recon:EC2/PortProbeUnprotectedPort`) | | **UnauthorizedAccess** | Attempts to access AWS services or resources with stolen credentials | | **PrivilegeEscalation** | Usage of IAM privilege escalation techniques | | **Backdoor** | Communication with known malware or C2 domains | | **CryptoCurrency** | Use of EC2 for crypto mining (`CryptoCurrency:EC2/BitcoinTool.B`) | | **Impact** | Evidence of destructive actions (e.g., S3 exfiltration) | | **Persistence** | Use of backdoors or IAM policies to maintain access | | **Trojan** | Malware communicating with external IPs or known botnets | | **Behavioral** | Unusual activity by users or roles (e.g., `Behavior:CredentialExfiltration`) | > Each finding has a **severity level**: **Low**, **Medium**, **High** --- ## Understanding GuardDuty Findings Findings are classified by **types**, **severity**, and **resources involved**. Understanding **findings** is key to taking timely and effective action. Let’s dive deep.. ### 1\. Structure of a Finding A finding is a JSON document with rich metadata. Key attributes include: | **Field** | **Description** | | --- | --- | | `id` | Unique identifier for the finding | | `type` | Threat type (e.g., `Recon:EC2/PortProbeUnprotectedPort`) | | `severity` | Level of threat: `1.0–3.9` (Low), `4.0–6.9` (Medium), `7.0–8.9` (High) | | `resource` | Resource involved (EC2 instance, IAM user, etc.) | | `region` | AWS region where activity was observed | | `service.action` | Details of the suspicious action (e.g., port probe, API call) | | `service.additionalInfo` | Optional data like threat list name, threat purpose | | `createdAt`, `updatedAt` | Timestamps indicating first and last observed occurrence | ### 2\. Severity Levels GuardDuty uses numerical scores from **0.1 to 8.9**, and classifies them into: | **Severity Level** | **Range** | **Meaning** | | --- | --- | --- | | **Low** | 0.1 – 3.9 | Suspicious behavior, may be benign (e.g., port scanning) | | **Medium** | 4.0 – 6.9 | Possibly unauthorized activity, investigation recommended | | **High** | 7.0 – 8.9 | Confirmed malicious intent or resource compromise, immediate action needed | > **Note:** Severity scores are influenced by threat type, impact, origin (e.g., Tor), and AWS intelligence feeds. ### 3\. **Sample Finding Table** | **Finding Type** | **Description** | **Severity** | | --- | --- | --- | | `CryptoCurrency:EC2/BitcoinTool.B!DNS` | Bitcoin mining detected via DNS queries | High | | `UnauthorizedAccess:EC2/SSHBruteForce` | Repeated SSH login attempts from known IPs | Medium | | `Recon:EC2/PortProbeUnprotectedPort` | Port scanning to public IPs | Low | | `Backdoor:EC2/Spambot` | EC2 used as spam bot | High | | `PrivilegeEscalation:Kubernetes/Exec` | Suspicious kubectl exec into container (EKS) | Medium | > Use [GuardDuty finding types documentation](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types.html) for full list. **Example 1**: **High-Severity Finding** ```json { "findings": [ { "schemaVersion": "2.0", "accountId": "111122223333", "region": "us-west-2", "resource": { "resourceType": "Instance", "instanceDetails": { "instanceId": "i-0abc1234567890xyz", "tags": [{"key": "Name", "value": "webserver"}] } }, "type": "CryptoCurrency:EC2/BitcoinTool.B", "severity": 8.0, "title": "EC2 instance involved in Bitcoin mining activity", "description": "Detected known Bitcoin mining software communicating to mining pool.", "service": { "action": { "networkConnectionAction": { "remoteIpDetails": { "ipAddressV4": "172.31.22.44", "organization": {"asn": "BitcoinPool"} } } }, "additionalInfo": { "threatListName": "Bitcoin Mining Pools" } } } ] } ``` **Interpretation:** * Severity 8.0 = **High**. * Confirms EC2 instance compromise for mining cryptocurrency. * Requires immediate response: isolate instance, investigate persistence, rotate credentials. **Example 2**: **Low-Severity Finding** ```json "type": "Recon:EC2/PortProbeUnprotectedPort", "severity": 2.0, "title": "Unprotected port probed", "description": "Remote host attempted to access port 22 (SSH) on this EC2 instance." ``` **Interpretation:** * Severity 2.0 = **Low** * Common scanning behavior, possibly from bots. * Not critical but monitor and consider reducing attack surface (e.g., Security Group tightening). --- ## **GuardDuty Setup** ### 1\. **Enable GuardDuty (Single Account Setup)** ```bash aws guardduty create-detector --enable ``` Get the Detector ID: ```bash aws guardduty list-detectors ``` Enable optional features like S3 and EKS logs: ```bash aws guardduty update-detector \ --detector-id \ --data-sources '{"S3Logs":{"Enable":true}, "Kubernetes":{"AuditLogs":{"Enable":true}}}' ``` ### 2\. **Multi-Account (Organization) Setup with Delegated Administrator** **Steps:** 1. Enable GuardDuty in management account 2. Designate delegated admin (optional) 3. Auto-enable for new accounts 4. Link member accounts to central detector ```bash # Step 1: Enable in Org master aws guardduty create-detector --enable # Step 2: Register delegated admin aws guardduty enable-organization-admin-account --admin-account-id # Step 3: Enable Org-wide GuardDuty aws guardduty update-organization-configuration \   --detector-id \   --auto-enable ORGANIZATION \   --data-sources '{"S3Logs":{"AutoEnable":true},"Kubernetes":{"AuditLogs":{"AutoEnable":true}}}' # Step 4: Add existing members aws guardduty create-members \   --detector-id \   --account-details AccountId=, Email= ``` --- ## **Real-World Use Cases** > Download full code examples from git - [aws-guardduty-automation](https://github.com/sthallapelly/aws-guardduty-automation) ### **Case 1: Crypto Mining in EC2** **Problem**: An EC2 instance was compromised and used for Bitcoin mining, leading to increased costs. **Solution**: * GuardDuty detects EC2 involvement in crypto mining (`CryptoCurrency:EC2/BitcoinTool.B!DNS`) * We create EventBridge Rule to filter the event and * Auto-triggers Lambda to isolate instance. **Implementation Steps:** 1. Enable GuardDuty in your account 2. Create IAM role for Lambda with proper permissions Isolate EC2 3. Create Lambda and deploy 4. Create EventBridge Rule for Crypto Threat and attach Labda as target. ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1746368046392/907a2326-3798-4d46-8099-71ca2a484b63.png align="center") **EventBridge Rule Sample:** ```bash # Create rule aws events put-rule --name GDCryptoMiningThreats \ --event-pattern '{ "source": ["aws.guardduty"], "detail-type": ["GuardDuty Finding"], "detail": { "type": ["CryptoCurrency:EC2/BitcoinTool.B!DNS"] } }' # Add Lambda as target aws events put-targets \ --rule GDCryptoMiningThreats \ --targets '[{ "Id": "IsolateEC2", "Arn": "arn:aws:lambda:::function:GDIsolateEC2" }] ``` **Lambda Sample:** ```python # isolate_ec2.py import json import boto3 ISOLATION_SG_ID = 'sg-0isolate123abc' # Pre-created SG with no inbound rules def lambda_handler(event, context): ec2 = boto3.client('ec2') for finding in event['detail']['resource']['instanceDetails'].get('instanceId', []): response = ec2.modify_instance_attribute( InstanceId=finding, Groups=[ISOLATION_SG_ID] ) return {'status': 'Isolated'} ``` ### Case 2: Auto-Tag Compromised EC2 from Port Probing **Problem**: An EC2 instance was compromised and used for **reconnaissance attempts** like **port scanning or probing** from unauthorized IPs. **Solution**: * GuardDuty detects EC2 involvement in probe (`Recon:EC2/PortProbeUnprotectedPort`) * We create EventBridge Rule to filter the event and * Auto-triggers Lambda to Tag EC2 instance for identification and further investigation. **Implementation Steps:** 1. Enable GuardDuty in your account 2. Create IAM role for Lambda with proper permissions for Tagging EC2 3. Create Lambda and deploy 4. Create EventBridge Rule for Recon Threat and attach Labda as target. **EventBridge Rule Sample:** ```bash aws events put-rule \ --name "GD-PortProbe-Detection" \ --event-pattern '{ "source": ["aws.guardduty"], "detail-type": ["GuardDuty Finding"], "detail": { "type": ["Recon:EC2/PortProbeUnprotectedPort"] } }' # Add Lambda as target aws events put-targets \ --rule GDCryptoMiningThreats \ --targets '[{ "Id": "TagEC2", "Arn": "arn:aws:lambda:::function:GDTagInstance" }] ``` **Lambda Sample:** ```python import json import boto3 def lambda_handler(event, context): detail = event['detail'] instance_id = detail['resource']['instanceDetails']['instanceId'] ec2 = boto3.client('ec2') ec2.create_tags(Resources=[instance_id], Tags=[{'Key': 'SecurityStatus', 'Value': 'Compromised'}]) return {'status': 'Tagged'} ``` ### **Case 3: Automated actions based on severity** **Problem**: Enterprise want to monitor all sevier Threats and take actions * Notify SOC on the Event * Auto-remediate to reduce the impact * Store evidences in S3 for future use. **Solution**: * Use EventBridge to route findings to multiple targets to take actions such as * Integrate with SNS for notification * Auto-remediate with Lambda (As explained above examples) * Sent to Firehose to store in S3 for evidence. **EventBridge Rule Sample:** ```bash # Create new Rule aws events put-rule \   --name "GD-Finding-High" \   --event-pattern '{     "source": ["aws.guardduty"],     "detail-type": ["GuardDuty Finding"],     "detail": {       "severity": { "numeric": [">=", 7] }     }   }' # Create Firehose to deliver findings to S3: aws firehose create-delivery-stream \   --delivery-stream-name GuardDutyStream \   --s3-destination-configuration [file://s3-config.json] # Attach Targets: aws events put-targets \   --rule GD-Finding-High \   --targets '[{"Id":"SendAlert","Arn":"arn:aws:sns:us-east-1:123456789012:SecurityAlerts"},               {"Id":"RemediationLambda","Arn":"arn:aws:lambda:us-east-1:123456789012:function:IsolateEC2"},               {"Id":"FirehoseTarget","Arn":"arn:aws:firehose:us-east-1:123456789012:deliverystream/GuardDutyStream"}]' ``` **Sample s3-config.json:** ```json {   "RoleARN": "arn:aws:iam::123456789012:role/FirehoseRole",   "BucketARN": "arn:aws:s3:::guardduty-findings-bucket" } ``` --- ## **Best Practices** | **Practice** | **Why It Matters** | | --- | --- | | Enable in all regions | Attackers can target unused areas | | Enable auto-enable on new accounts | Ensures coverage in expanding orgs | | Forward findings to Security Hub | Centralized security visibility | | Utilize EventBridge for remediation | Automate isolation of compromised resources | | Enable all data sources | Maximize threat coverage | | Use severity thresholding | Prioritize alerts (e.g., severity > 7) | --- ## **Exam Tips**

Topic

Exam Insight

Data Sources

Know that CloudTrail, VPC Flow Logs, and DNS logs are default

S3 Protection

Not enabled by default — must explicitly enable

Findings

Severity ranges from 0.1 to 8.9 — expect scenario-based questions

Cross-Account Setup

GuardDuty master/member setup is a common exam scenario

Remediation

Expect use cases with EventBridge and Lambda automation

EKS Logging

A newer topic — be aware it's available and what it detects

Auto-enablement

Must enable for new accounts + regions in orgs for coverage

Integration

Know how it integrates with Security Hub, Lambda, EventBridge

--- ## **Final Thoughts** AWS GuardDuty offers a powerful, low-maintenance way to gain visibility into threats across your AWS environments. Whether you're a security engineer or preparing for the Security Specialty exam, mastering GuardDuty helps you design and operate secure cloud infrastructures.