GuardDuty Not Detecting "CredentialAccess:InstanceCredentialExfiltration" After Simulating Attack

Question

I'm trying to test AWS GuardDuty’s detection capability for "CredentialAccess:InstanceCredentialExfiltration" but haven't been able to trigger an alert. Here’s what I did:

Setup:

1.Launched an EC2 instance and attached an IAM role to it.

2. Verified that the IAM role attached has permissions to perform some administrative actions.

Attack Simulation:

Retrieved temporary credentials from the instance metadata:

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2testrole
Copied the AccessKeyId, SecretAccessKey, and SessionToken.

Configured AWS CLI on my personal laptop (outside AWS) using these credentials:

aws configure set aws_access_key_id  --profile sujal
aws configure set aws_secret_access_key  --profile sujal
aws configure set aws_session_token  --profile sujal

Ran the following command to test access:
aws sts get-caller-identity --profile sujal 
To avoid direct attribution, I routed traffic through Tor using ProxyChains before making AWS CLI requests.

Issue:

GuardDuty is not generating any findings under "CredentialAccess:InstanceCredentialExfiltration" or any other category.

I expected GuardDuty to detect that temporary credentials were used outside AWS, but there are no alerts in the GuardDuty console.

Questions:

Are there any specific conditions under which GuardDuty triggers this finding?

Does GuardDuty consider traffic routed via Tor/ProxyChains as a valid exfiltration indicator?

Could GuardDuty be ignoring this due to my AWS account’s region, GuardDuty settings, or some other factor?

Any recommendations to ensure this attack simulation triggers the expected GuardDuty finding?

Would appreciate any insights from AWS security experts!

BrianDAnderson_AWS · Answer

Hello Sujal, Based on your scenario, there are a couple of scenarios where GuardDuty might not be triggering.  I've outlined those scenarios below and suggested some modifications to your test:

Key Requirements for Detection:

GuardDuty primarily looks for credential usage from IP addresses outside of AWS's IP ranges
    The credentials need to be used to make AWS API calls
    There should be a clear pattern of credential exfiltration (not just a single API call)

Why Your Test Might Not Trigger:

Single API call (sts:GetCallerIdentity) might not be sufficient
    Tor exit nodes might be filtered out by GuardDuty's detection logic
    The time window between credential retrieval and usage might matter

Modified Test Approach:

# On EC2 instance
# Get credentials
ROLE_NAME=$(curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/)
CREDS=$(curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE_NAME)

# On external machine (without Tor initially)
# Make multiple API calls to different services
aws configure set aws_access_key_id  --profile test
aws configure set aws_secret_access_key  --profile test
aws configure set aws_session_token  --profile test

# Make multiple API calls
aws s3 ls --profile test
aws ec2 describe-instances --profile test
aws iam list-users --profile test
aws sts get-caller-identity --profile test

Additional Testing Considerations:

Try without Tor first to establish a baseline
    Ensure GuardDuty is properly configured:

aws guardduty get-detector-status --detector-id

Check if your test region has GuardDuty enabled
Verify findings settings:

aws guardduty list-findings --detector-id

Common Gotchas:

GuardDuty might have a detection delay (up to 30 minutes)
    The IP address you're testing from might be allow-listed
    Some finding types might be disabled in your GuardDuty configuration

Enhanced Test Scenario:

#!/bin/bash
# Script to simulate multiple credential usage patterns

# Configure AWS CLI with stolen credentials
aws configure set region us-east-1 --profile stolen
aws configure set aws_access_key_id $ACCESS_KEY --profile stolen
aws configure set aws_secret_access_key $SECRET_KEY --profile stolen
aws configure set aws_session_token $SESSION_TOKEN --profile stolen

# Make multiple API calls over time
services=("s3" "ec2" "iam" "rds" "lambda")
for service in "${services[@]}"; do
    case $service in
        "s3")
            aws s3 ls --profile stolen
            ;;
        "ec2")
            aws ec2 describe-instances --profile stolen
            ;;
        "iam")
            aws iam list-users --profile stolen
            ;;
        "rds")
            aws rds describe-db-instances --profile stolen
            ;;
        "lambda")
            aws lambda list-functions --profile stolen
            ;;
    esac
    sleep 30  # Wait between calls
done

Verification Steps:

# Check GuardDuty findings
aws guardduty list-findings \
    --detector-id  \
    --finding-criteria '{"Criterion": {"type": {"Eq": ["CredentialAccess:InstanceCredentialExfiltration"]}}}'

Recommendations:

Start testing without Tor/ProxyChains

Make multiple API calls to different services

Ensure your external IP is clearly outside AWS ranges

Wait at least 30 minutes for detection

Verify GuardDuty settings in the console

Check CloudTrail to confirm API calls are being logged

If still no findings appear, consider:

Opening a support ticket with AWS
    Verifying GuardDuty's service-linked role permissions
    Testing in a different region
    Creating a fresh AWS account for testing

Note: Remember to clean up any test credentials and roles after testing to maintain security.

Hopefully this provides some clarity on the issue and gives some direction on identifying a potential root cause.

Thank you for using AWS!
Brian

GuardDuty Not Detecting "CredentialAccess:InstanceCredentialExfiltration" After Simulating Attack

On EC2 instance

Get credentials

On external machine (without Tor initially)

Make multiple API calls to different services

Make multiple API calls

Script to simulate multiple credential usage patterns

Configure AWS CLI with stolen credentials

Make multiple API calls over time

Check GuardDuty findings

Relevant content