Measuring Amazon GuardDuty Detection Time Delta

Introduction

How quickly can Amazon GuardDuty detect threats in your AWS environment? This research quantifies the detection time delta—the critical interval between when an attack occurs and when GuardDuty identifies it—across multiple attack types. Understanding these metrics is essential for organizations relying on GuardDuty as part of their cloud security strategy.

Through controlled testing in an isolated AWS environment, I measured GuardDuty's performance against various attacks, from SSH brute force attempts to IAM credential exfiltration. The findings reveal both strengths and limitations that every AWS security professional should understand.

Testing Environment Setup

The research utilized the AWS GuardDuty Tester repository to create a controlled testing environment with:

• Linux Bastion host for secure access
• RedTeam EC2 instance for launching attacks
• Target Windows and Linux EC2 instances
• Auto Scaling group with additional Linux targets

Attack Types Tested

Five attack types were selected for testing, focusing on rule-based detections that don't require a learning period:

1. IAM Credential Exfiltration

UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.InsideAWS - Testing detection when EC2 instance credentials are used from a different AWS account.

2. Command & Control Activity

Backdoor:EC2/C&Cactivity.B!DNS - Simulating DNS queries to known malicious domains.

3. Port Scanning

Recon:EC2/Portscan - EC2 instance scanning remote hosts for open ports.

4. SSH Brute Force

UnauthorizedAccess:EC2/SSHBruteForce - Both inbound and outbound SSH brute force attempts.

5. RDP Brute Force

UnauthorizedAccess:EC2/RDPBruteForce - Both inbound and outbound RDP brute force attempts.

Attack Simulation Scripts

Modified the AWS GuardDuty Tester scripts to log timestamps and automatically retrieve findings via AWS CLI. Here's a snippet of the core testing logic:

#!/bin/bash
# GuardDuty Detection Testing Script

# Initialize variables
DETECTOR_ID=$(aws guardduty list-detectors --query 'DetectorIds[0]' --output text)
OUTPUT_DIR="./guardduty_tests"
TIMESTAMP=$(date -u +"%Y%m%d-%H%M%S")

# Function to fetch GuardDuty findings
fetch_findings() {
    aws guardduty list-findings \
        --detector-id $DETECTOR_ID \
        --finding-criteria '{"Criterion":{"updatedAt":{"GreaterThanOrEqual":'$(date -d "1 hour ago" +%s000)'}}}'  \
        --output json > "$OUTPUT_DIR/findings_$TIMESTAMP.json"
}

# Log attack timestamp
log_attack() {
    echo "$TIMESTAMP,$1" >> "$OUTPUT_DIR/attacks.csv"
}

# Simulate port scan
echo "[*] Starting port scan simulation..."
log_attack "Recon:EC2/Portscan"
nmap -sT -P0 -p 1-1000 $TARGET_IP

# Wait and fetch findings
sleep 300
fetch_findings

For testing IAM credential exfiltration, I created a separate script that retrieves instance credentials via the metadata service:

#!/bin/bash
# Retrieve IAM credentials from EC2 metadata

# Get instance role
ROLE=$(curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/)

# Get temporary credentials
CREDS=$(curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE)

# Extract credentials
ACCESS_KEY=$(echo $CREDS | jq -r '.AccessKeyId')
SECRET_KEY=$(echo $CREDS | jq -r '.SecretAccessKey')
TOKEN=$(echo $CREDS | jq -r '.Token')

# Configure AWS CLI profile with stolen credentials
aws configure set aws_access_key_id $ACCESS_KEY --profile tester
aws configure set aws_secret_access_key $SECRET_KEY --profile tester
aws configure set aws_session_token $TOKEN --profile tester

# Use credentials from different account
aws ec2 describe-instances --profile tester

Key Findings

After running 53 tests for each attack type over two weeks, the results revealed significant variations in GuardDuty's detection capabilities:

Detection Time Statistics

Notable Observations

• Fastest Detection: SSH brute force (outbound) with consistent 2-3 minute detection times
• Slowest Detection: C&C DNS activity with highly variable times (3 minutes to over 2 hours)
• Consistency: Port scanning and SSH brute force showed the lowest standard deviation (6 seconds)
• Inbound vs Outbound: Inbound attacks consistently took longer to detect than outbound

Remediation Time Comparison

I compared manual versus automated remediation for SSH brute force attacks using EventBridge rules:

Automated Remediation Setup

import boto3
import json
from datetime import datetime

def lambda_handler(event, context):
    # Parse GuardDuty finding
    finding = json.loads(event['detail'])
    instance_id = finding['resource']['instanceDetails']['instanceId']
    
    # Initialize EC2 client
    ec2 = boto3.client('ec2')
    
    # Terminate the compromised instance
    response = ec2.terminate_instances(InstanceIds=[instance_id])
    
    # Log remediation timestamp
    timestamp = datetime.utcnow().strftime('%Y%m%d-%H%M%S')
    
    return {
        'statusCode': 200,
        'body': json.dumps(f'Instance {instance_id} terminated at {timestamp}')
    }

Results

• Automated Remediation: Average 3m 48s (range: 53s - 14m 57s)
• Manual Remediation: Average 6m 9s (range: 3m - 17m)
• Time Saved: Automation was ~2m 21s faster on average

Both methods showed high variability due to EventBridge processing times, suggesting that remediation speed depends on multiple factors beyond just the detection mechanism.

Practical Implications

Strengths

• Excellent at detecting outbound attacks from compromised instances
• Consistent performance for SSH brute force and port scanning
• Quick detection of IAM credential exfiltration attempts

Limitations

• Highly variable detection times for C&C DNS activity
• Slower detection of inbound attacks compared to outbound
• Machine learning model may stop alerting on repeated credential use from external accounts

Important: During testing, GuardDuty stopped generating findings after 5-6 alerts for the same IAM credential exfiltration pattern, as its ML model categorized it as expected behavior. This highlights a potential blind spot in continuous attacks.

Recommendations

1. Layer Your Defenses

GuardDuty should be part of a comprehensive security strategy, not a standalone solution. Integrate it with:

• AWS Security Hub for centralized findings
• Amazon Detective for investigation
• AWS Config for compliance monitoring
• Third-party SIEM solutions for correlation

2. Prioritize Automation

While automated remediation showed variability, it consistently outperformed manual methods. Focus on:

• Lambda functions for immediate response
• Step Functions for complex remediation workflows
• Systems Manager for instance-level actions

3. Adjust Expectations

Understanding GuardDuty's detection patterns helps set realistic expectations:

• Budget 10+ minutes for inbound attack detection
• Don't rely solely on GuardDuty for C&C detection
• Implement additional monitoring for high-value assets

4. Custom Threat Intel

Supplement GuardDuty's threat intelligence with your own:

# Add custom threat list to GuardDuty
aws guardduty create-threat-intel-set \
    --detector-id $DETECTOR_ID \
    --name "Custom-C2-Domains" \
    --format TXT \
    --location s3://your-bucket/threat-intel.txt \
    --activate

Future Research Directions

This foundational research opens several avenues for further investigation:

• Comparative analysis with Azure Sentinel and Google Cloud Security Command Center
• Testing GuardDuty's machine learning-based detections over extended periods
• Evaluation in production environments with real-world traffic patterns
• Analysis of detection effectiveness for advanced persistent threats (APTs)

Conclusion

Amazon GuardDuty demonstrates variable effectiveness across different attack types, excelling at detecting outbound attacks and SSH-based threats while struggling with consistency in C&C detection. The key takeaway: GuardDuty is a valuable component of AWS security, but shouldn't be your only line of defense.

Organizations should integrate GuardDuty into a multi-layered security architecture, set appropriate expectations based on these metrics, and prioritize automated response mechanisms despite their variability. Understanding these detection time deltas enables security teams to make informed decisions about additional controls and monitoring requirements.

Remember that this research was conducted in a controlled environment—real-world performance may vary based on account activity, region, and GuardDuty's evolving detection algorithms. Regular testing and validation of your security controls remains essential.

Resources

• AWS GuardDuty Tester Repository
• Amazon GuardDuty Documentation
• AWS Security Reference Architecture
• AWS Security Hub