Signs of Leaked Access Keys

An IAM access key is a long-term credential — an access key ID and secret — that lets code or a user call AWS APIs. If it leaks, an attacker can act as that identity from anywhere.

Leaked keys are one of the most common AWS breaches, usually because a key was hardcoded and pushed to a public repository.

Keys escape in predictable ways:

• Committed to a public GitHub repository.
• Embedded in a mobile or client-side app.
• Logged in plaintext or shared over chat.
• Stored in a misconfigured public S3 bucket.

Long-term keys are the riskiest credential precisely because they do not expire on their own.

Amazon GuardDuty raises specific findings for credential abuse, such as UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration or anomalous API calls.

It flags activity like a key suddenly used from a new country or a Tor exit node — strong signals that a credential is no longer in the right hands.

AWS proactively scans public sites for exposed keys. If it finds one of yours, it sends an abuse notice and may apply a quarantine policy (AWSCompromisedKeyQuarantine) that blocks dangerous actions.

Receiving such an email is an unmistakable sign: treat it as a confirmed incident immediately.

Watch for behavior that does not fit the key's normal job:

• Calls from unfamiliar regions or IP addresses.
• Reconnaissance actions like ListBuckets or DescribeInstances at odd hours.
• Attempts to create new IAM users or attach admin policies.

Attackers explore before they exploit, and that exploration is detectable.

A sudden surge in your AWS bill or unexpected resources is a classic symptom. Attackers love to spin up large fleets of EC2 instances for cryptomining.

AWS Budgets alerts and Cost Anomaly Detection can warn you of the financial fingerprint a compromised key often leaves behind.

CloudTrail records every API call, including the access key ID that made it. Filtering on a suspect key reveals exactly what the attacker did and when.

Look at the source IP, user agent, and called actions to scope the damage and decide what needs to be rotated or rolled back.

A common attacker goal is to turn a low-privilege key into broad access. Watch for IAM changes: new users, new keys, attached policies, or role assumptions.

IAM Access Analyzer and CloudTrail together help you spot an identity that suddenly gained powers it should not have.

A burst of access-denied errors can be as telling as successful calls. An attacker probing what a stolen key can do generates many failures.

CloudTrail logs these denials too, so a spike of AccessDenied events from one key is a red flag worth investigating right away.

The best signal is the one you never have to read. Prefer temporary credentials from IAM roles over long-term keys, scan repositories for secrets, and rotate keys regularly.

Fewer long-term keys mean fewer ways to leak and a smaller surface for these findings to appear in the first place.

One signal alone may be benign; together they confirm a compromise. A finding from a new region, a cost spike, and IAM changes from the same key form a clear pattern.

Use Security Hub and Detective to correlate signals across services, turning scattered alerts into a single, confident conclusion about a leaked credential.

Spot the strongest leak signal.

Leaked long-term access keys are a top AWS breach vector. Watch for GuardDuty credential findings, AWS abuse emails, calls from new regions, cost spikes from cryptomining, IAM privilege escalation, and bursts of access-denied errors. CloudTrail ties activity to the offending key so you can scope the damage. The best defense is to use temporary role credentials and scan for secrets, so leaks rarely happen at all.