Leaked AWS access key: what to do in the first hour

An AWS access key pushed to a public repository can be found and used by automated scanners within minutes. The usual result is a burst of large EC2 instances mining cryptocurrency in every region, new IAM users created for persistence, or data copied out of S3. If you've been told a key leaked, by GitHub, by AWS or by a colleague, treat it as already compromised and work through these steps in order.

1. Deactivate the key now

Deactivating stops the key working immediately and can be reversed if something legitimate breaks. Deleting can't be undone, so deactivate first.

aws iam update-access-key --user-name <user> --access-key-id AKIA... --status Inactive

If the key belongs to the root user, deactivate and delete it in the console under the root account's security credentials, and enable MFA on root if it isn't already. Root access keys shouldn't exist at all.

2. Check whether AWS has already acted

AWS scans public code for its own keys. When it finds one, it may attach a quarantine managed policy (AWSCompromisedKeyQuarantine) to the user and open a support case. The quarantine policy denies some risky actions, but not all, so don't rely on it: deactivating the key is still your job.

3. Find out what the key did

CloudTrail records API calls. Event history covers the last 90 days of management events in each region; search it by access key.

aws iam get-access-key-last-used --access-key-id AKIA...
aws cloudtrail lookup-events --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIA... --region <region>

Repeat the lookup in every region, because attackers often use regions you never touch. Look for RunInstances, CreateUser, CreateAccessKey, AttachUserPolicy, PutBucketPolicy, GetObject in bulk, CreateLoginProfile and changes to CloudTrail itself. Note the source IP addresses and user agents.

4. Remove what the attacker created

• Terminate instances, spot requests and launch templates you didn't create, in every region.
• Delete IAM users, access keys, roles and policies the attacker added, and check for new trust relationships on existing roles.
• Look for new Lambda functions, ECS tasks and SageMaker or GPU resources.
• Check S3 bucket policies and ACLs for new public access, and look for data access in S3 server access logs or CloudTrail data events if you have them.
• Check billing and Cost Explorer by region and service for the last few days; ask AWS Support about charges from unauthorised use.

5. Rotate safely

If the key was in legitimate use, create a new key, update every place that used the old one (CI variables, servers, applications, developers' machines), confirm they work, and then delete the old key. A user can have two keys at once, which lets you rotate without downtime.

aws iam create-access-key --user-name <user>
# update every consumer, confirm, then:
aws iam delete-access-key --user-name <user> --access-key-id AKIA...OLD

6. Remove the secret from the code

Delete the key from the repository and its history with git filter-repo or BFG Repo-Cleaner, and ask collaborators to re-clone. Do this after rotation, not instead of it: anything pushed publicly must be assumed copied. Check forks, CI logs, container images and wikis for other copies.

7. Decide who you need to tell

If personal data may have been accessed, breach notification rules can apply, some within hours: CERT-In's 6-hour rule for listed incidents in India, 72 hours for GDPR regulators. Record when you became aware. Our free breach deadline calculator lists the deadlines that may apply.

8. Stop it happening again

• Replace long-lived access keys with IAM roles: instance profiles, IRSA or EKS Pod Identity, and OIDC federation for GitHub Actions and other CI systems.
• Use IAM Identity Center for people, with short-lived credentials.
• Turn on GitHub secret scanning and push protection, and run a scanner in pre-commit hooks.
• Grant least privilege, so a leaked key can do less.
• Alert on new access keys, new IAM users and activity in unused regions.

What attackers usually do

Automated tools that harvest keys from public repositories tend to follow the same script. They call sts get-caller-identity to see whose key it is, list what the key can access, and, if it has broad permissions, start large or GPU instances in many regions at once for cryptocurrency mining. Many also create a new IAM user or access key so they keep access after the original key is disabled. Some read S3 buckets or databases for data to sell or ransom. Knowing this pattern tells you where to look first: EC2 in every region, IAM changes, and data access.

Common mistakes

• Deleting the key from the repository and assuming the problem is solved.
• Checking only the region you normally use.
• Rotating the key but leaving the attacker's new IAM user or access key in place.
• Deleting the key before finding which systems use it, causing an outage, then re-enabling it under pressure.
• Not recording the time you became aware, which matters for any notification deadlines.

Preparing before it happens

Write this runbook down before you need it, with the exact commands and who has the permissions to run them. Turn on a CloudTrail trail for all regions delivering to a protected S3 bucket, so you have more than 90 days of history. Set up alerts for new IAM users, new access keys, and activity in regions you don't use. And keep a list of where each long-lived key is used, so rotation takes minutes rather than a day of searching.

When the leak is somewhere else

Public repositories are the best-known source of leaked keys, but not the only one. Keys turn up in CI build logs that print environment variables, in container images pushed to public registries, in mobile apps and front-end bundles, in screenshots and screen recordings shared in support tickets, in chat messages and in documents uploaded to AI assistants. The response is the same wherever it leaked: deactivate, investigate, clean up and rotate. The prevention differs. Mask secrets in CI logs, scan images before pushing them, never ship cloud keys in client-side code, and keep a list of where every long-lived credential lives, so you can rotate it quickly when the next leak happens.

Checklist

• Key deactivated, with the time recorded.
• CloudTrail searched by access key in every region.
• Unauthorised resources, users, keys and policies removed.
• New key in place and old key deleted, or the workload moved to a role.
• Secret removed from code and history, and other copies found.
• Notification obligations checked.
• Long-lived keys replaced and secret scanning enabled.