Detecting Leaked AWS Access Keys: CloudTrail, GuardDuty and Athena Queries

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

Leaked AWS access keys are often used within minutes of exposure. Detecting misuse quickly limits how much an attacker can do.

Signals worth watching

• API calls with an access key from an IP address or country never seen before for that key.
• Reconnaissance calls immediately after first use: GetCallerIdentity, ListBuckets, ListUsers, DescribeInstances.
• Many AccessDenied errors as an attacker probes permissions.
• Creation of new IAM users, access keys or login profiles.
• Launching large or GPU instances in unused regions (crypto mining).

Where the data lives

• CloudTrail management events in every region.
• GuardDuty findings such as unusual API calls and credential use from external IPs.
• AWS Health / support notifications: AWS may notify you if it detects your key publicly exposed (the AWSCompromisedKeyQuarantine managed policy is sometimes attached automatically).

A starting query

In Sentinel with CloudTrail connected, look for keys generating many access-denied errors:

AWSCloudTrail
| where ErrorCode in ("AccessDenied", "UnauthorizedOperation")
| summarize Errors = count(), APIs = make_set(EventName, 20)
    by UserIdentityAccessKeyId, SourceIpAddress, bin(TimeGenerated, 1h)
| where Errors > 20

Response

1. Deactivate the key immediately — do not wait to finish investigating.
2. Review everything the key did in CloudTrail, in all regions.
3. Remove any resources or identities the attacker created.
4. Find out how the key leaked and close that path.