# Leaked AWS Access Key? What to Do in the First Hour > Exposed an AWS access key (AKIA/ASIA)? Deactivate it, audit CloudTrail, remove attacker access and rotate safely. Step-by-step guide. Source: https://leakwatch.net/secrets/aws-access-key --- [LeakWatch](/) [Product](/product)[Live feed](/leaks)[Guides](/secrets)[Blog](/blog)[Free scan](/) 1. [Home](/) 2. [Secrets](/secrets) 3. AWS access key Cloud · Secret guide # Leaked AWS access key: what to do in the first hour Critical severityChecked liveLast verified October 2, 2026 · 4 min read 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](https://console.aws.amazon.com/iam/home#/security_credentials) ## 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: ```text 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 1. **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 ` returns the user name and when the key was last used. 2. **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. 3. **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. 4. **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`. 5. **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. 6. **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. 7. **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](/blog/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](https://console.aws.amazon.com/iam/home#/security_credentials) 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html). ## 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](/leaks/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. ## Related - [GCP Service Account Key](/secrets/gcp-service-account-key) - [Azure Client Secret](/secrets/azure-client-secret) - [Terraform Cloud API Token](/secrets/terraform-cloud-api-token) - [I accidentally pushed an API key to GitHub](/blog/i-accidentally-pushed-an-api-key-to-github) - [Which vendors leak most this week](/leaks/trends) - [All secret guides](/secrets) [Get alerted next time a secret leaks — create a free account](/) LeakWatch is not affiliated with AWS. ![Gabriel Diyan, founder of LeakWatch](/brand/Photo-Gabriel-Diyan.webp) Gabriel Diyan (0xCr0c0) Cybersecurity student, founder of LeakWatch. I built and run the scanner described here — the detection patterns, the false-positive classifier and the provider validators are mine. [More about who I am](/about). [GitHub](https://github.com/Leakwatch-Scan) · [X](https://x.com/LeakwatchScan) · [LinkedIn](https://www.linkedin.com/in/gabriel-diyan-80a378375) · [GitHub (personal)](https://github.com/crocogab) LeakWatch Secrets leak into public commits every minute. This watches the forges for yours. Built and run by [Gabriel Diyan](/about), a cybersecurity student — [why LeakWatch exists](/about). Scan - [Product](/product) - [Live feed](/leaks) - [Trends](/leaks/trends) - [API docs](/docs) - [CI/CD](/docs?tab=ci) Read - [Blog](/blog) - [Secret guides](/secrets) - [Changelog](/changelog) - [About](/about) Verify - [Security](/security) - [Privacy](/privacy) - [Terms](/terms) - [Legal](/legal) - [Contact](/contact) - [Status](https://status.leakwatch.net) © 2026 LeakWatch [GitHub](https://github.com/Leakwatch-Scan)[X](https://x.com/LeakwatchScan)