Leaked AWS Access Key? What to Do in the First Hour

Q: What is the difference between an AKIA and an ASIA key?

AKIA is a long-term key tied to an IAM user: it works until someone deactivates or deletes it. ASIA is a temporary credential issued by STS together with a session token: it expires on its own, but until then it works like any other, and you can invalidate it by revoking the role’s active sessions.

An AWS access key is a login for the AWS API. Depending on the permissions of the IAM user or role behind it, it can start servers, read storage, send email or create new users, and leaked AWS keys are commonly abused to launch servers for crypto-mining. Disable the key first, then find out what it did.

Check your GitHub account for leaked secrets — free

Provider: AWS
Severity: Critical
Impact: Cloud infrastructure access
Checked live by LeakWatch: Yes
Revoke at: AWS IAM

What an AWS access key looks like

An access key is a pair: an access key ID (public-looking, 20 characters) and a secret access key (a separate, longer random string). The ID’s prefix tells you what kind it is:

AKIA…XXXX   long-term key of an IAM user
ASIA…XXXX   temporary credentials from AWS STS (come with a session token)

LeakWatch also recognizes the less common ABIA and ACCA prefixes. The ID alone cannot sign a request, but the secret is usually only a few lines away, in the same file (AWS_SECRET_ACCESS_KEY=…), so treat an exposed ID as an exposed key.

How AWS keys get leaked

The credentials file or .env: ~/.aws/credentials or a project .env copied into a repository.
Infrastructure code: Terraform *.tfvars and state files, CloudFormation parameters, Ansible variables.
Docker and CI: ENV/ARG lines in a Dockerfile (they stay in image layers), or a build log that prints the environment.
Hardcoded in an app: a mobile app, a Lambda function or a script with the key written in the source.
Backups and snapshots pushed to a public bucket or repository with the config inside.

What to do in the first hour

Deactivate the key. In the AWS console go to IAM → Users → the user → Security credentials → Access keys → Actions → Deactivate. Deactivating is instant and reversible, which makes it the safe first move. If you do not know which user owns the key, the AWS CLI command aws iam get-access-key-last-used --access-key-id <KEY_ID> returns the user name and when the key was last used.
Create a replacement and delete the old key. Issue a new key (or better, move the workload to an IAM role so there is no long-lived key at all), deploy it, then delete the deactivated key once nothing depends on it. If it was a root account key, delete it and turn on MFA for root.
If the credentials were temporary (ASIA…) they expire on their own, but you do not have to wait: in IAM, open the role and use Revoke active sessions to invalidate sessions issued before now.
Find out what the key did. Open CloudTrail → Event history, filter by AWS access key with the exposed ID, and set the time range to cover the exposure. Check every region, not just yours. Look for CreateUser, CreateAccessKey, AttachUserPolicy, RunInstances (especially in regions you never use), PutBucketPolicy, mass GetObject calls and SendEmail.
Remove anything the attacker created. Delete unknown IAM users, roles, access keys, EC2 instances, Lambda functions and login profiles. An attacker who got in often leaves a second way back.
Check billing. Open Cost Explorer for unexpected spend and enable a budget alert. If you see activity you did not cause, open a case with AWS Support.
Then clean the repository: remove the value, add the file to .gitignore, rewrite history if you wish. See I accidentally pushed an API key to GitHub for the order of operations.

AWS may react before you do. AWS scans public code for exposed keys and may attach a quarantine policy to the affected user and email the account owner. That limits some actions but is not a fix: the key still exists. Rotate it yourself.

Not sure what else leaked? Run a free scan.

Revoke it at AWS

Use IAM → Users → Security credentials for an IAM user’s key. The IAM security credentials shortcut manages the credentials of the principal you are signed in as; to act on another user’s key, go through IAM → Users. For the exact options, see AWS’s guide to managing access keys.

How LeakWatch detects it

LeakWatch matches the AWS key ID prefixes (AKIA, ASIA, ABIA, ACCA, A3T…) followed by the base32-style body AWS uses. See which vendors leak most this week on the leak trends page.

LeakWatch can check whether a detected key is still active with a read-only request to AWS. It never reads your data or spends your credits.

For AWS the check calls the read-only sts:GetCallerIdentity API, which needs the secret key as well, so it only runs when the secret is found near the key ID. A bare key ID is reported as detected, not as confirmed live. The check returns only who the key belongs to, and never lists or reads your resources.

FAQ

What is the difference between an AKIA and an ASIA key?

AKIA is a long-term key tied to an IAM user: it works until someone deactivates or deletes it. ASIA is a temporary credential issued by STS together with a session token: it expires on its own, but until then it works like any other, and you can invalidate it by revoking the role’s active sessions.

Is the access key ID alone dangerous?

Not by itself, since requests also need the secret. But the ID tells an attacker a valid account exists, and the secret is usually exposed in the same file. Rotate the pair, not just the ID.

Should I deactivate or delete the key?

Both, in that order. Deactivate immediately to stop the abuse, since you can reactivate if something critical breaks. Once the replacement is deployed, delete it so it cannot come back.