Detecting SSRF Metadata Credential Theft: CloudTrail, GuardDuty and Athena Queries

Retrospective: this article looks back at events from July 2019, written in 2026 with the benefit of hindsight.

The Capital One attack path — SSRF to the metadata service, then stolen role credentials used to read data — leaves traces in CloudTrail and GuardDuty if you look for them.

Signals worth watching

• Instance credentials used outside the instance. GuardDuty finding UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS (and the InsideAWS variant) flags EC2 role credentials used from another location.
• Instance roles calling APIs they don't normally use, such as ListBuckets from a web server role.
• Large numbers of S3 GetObject calls by a role in a short time.
• Requests from instances still using IMDSv1 (CloudWatch MetadataNoToken metric).

Where the data lives

• GuardDuty findings (enable S3 Protection for data access anomalies).
• CloudTrail management events, plus S3 data events for sensitive buckets.
• VPC Flow Logs for unusual outbound connections from the instance.

A starting query

Find role sessions issued to EC2 instances but used from IP addresses outside AWS:

AWSCloudTrail
| where UserIdentityType == "AssumedRole"
| where UserIdentityPrincipalid has ":i-"
| where SourceIpAddress !has "amazonaws.com"
| summarize Calls = count(), APIs = make_set(EventName, 20)
    by UserIdentityArn, SourceIpAddress, bin(TimeGenerated, 1h)

Compare source IPs against your instances' known public and NAT gateway addresses.

Response

1. Revoke the role's active sessions (add a deny policy with a aws:TokenIssueTime condition, available in the IAM console as "Revoke active sessions").
2. Isolate the instance and investigate the application for SSRF.
3. Review data accessed using S3 data events.
4. Enforce IMDSv2 and reduce the role's permissions.