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
👉 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:

---

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.

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:

• 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.

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:

2. Severity Levels

GuardDuty uses numerical scores from 0.1 to 8.9, and classifies them into:

Note: Severity scores are influenced by threat type, impact, origin (e.g., Tor), and AWS intelligence feeds.

3. Sample Finding Table

Use GuardDuty finding types documentation for full list.

Example 1: High-Severity Finding

{
  "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

"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)

aws guardduty create-detector --enable

Get the Detector ID:

aws guardduty list-detectors

Enable optional features like S3 and EKS logs:

aws guardduty update-detector \
  --detector-id <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

# 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 <DELEGATED_ADMIN_ACCT_ID>

# Step 3: Enable Org-wide GuardDuty
aws guardduty update-organization-configuration \
  --detector-id <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 <DETECTOR_ID> \
  --account-details AccountId=<MEMBER_ID>, Email=<EMAIL>

---

Real-World Use Cases

Download full code examples from git - 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.

EventBridge Rule Sample:

# 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:<region>:<account-id>:function:GDIsolateEC2"
  }]

Lambda Sample:

# 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:

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:<region>:<account-id>:function:GDTagInstance"
  }]

Lambda Sample:

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:

# 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:

{
  "RoleARN": "arn:aws:iam::123456789012:role/FirehoseRole",
  "BucketARN": "arn:aws:s3:::guardduty-findings-bucket"
}

---

Best Practices

---

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.