Leaked Alibaba Cloud Access Key: what to do in the first hour

• Configuration files committed by accident. Environment files, Terraform variables and the credentials file of an SDK often hold the pair, and they are rarely added to .gitignore on the first commit.
• Hard-coded values in scripts. A deployment script or a test that calls the API with the keys inline, then gets pushed to a public repository.
• Shared tool configuration. Command-line tool profiles and IDE settings that store the pair in plain text, copied into dotfiles repositories.
• CI logs. A debug step that prints environment variables, or a build that echoes its configuration.
• Screenshots and support requests. A console or terminal capture posted in a ticket with the pair still visible.

1. Find out whose key it is. Match the ID against the users in the RAM console. A root account key is the most serious case, and one that belongs to a RAM user with narrow rights is much less so.
2. Create a replacement first. Create a new AccessKey for the same user, and deploy it to your secret store or environment. Check that production still works before you touch the old key.
3. Disable the exposed key. Disabling it stops every request at once and is easy to undo if you find a system that still needed it. Once you are sure nothing depends on it, delete it. See the RAM console page below.
4. Audit the activity. Open ActionTrail, Alibaba Cloud’s audit product, and search for API calls made with the exposed AccessKey ID since the exposure. Look for calls from unfamiliar IP addresses, new instances, new users or keys, changes to security groups and any read of storage buckets.
5. Check for persistence. An attacker with a key often creates a second key, a new RAM user or a login profile. Review the users and their keys, and delete anything you cannot explain.
6. Review the secret half. If the leaked file also held the AccessKey Secret, treat the secret as exposed too, which is why the steps above replace the whole pair.
7. Clean the repository. Remove the value and rewrite history if you want to. See I accidentally pushed an API key to GitHub and Deep scan your whole git history.

Not sure what else leaked? Run a free scan.

AccessKeys are managed in the RAM console. Open the RAM console, go to the user the key belongs to, and open its AccessKey section. Find the key by its ID and disable it first. Keys can be created and deleted from the same place. Make sure you are in the right account, because a key from one account will not show up in another. If the key belonged to the root account, you can manage it from the account security settings, and Alibaba Cloud recommends deleting root account keys altogether in favor of RAM users with only the permissions they need. Menu names change over time, so if the page differs from this description, look for the AccessKey section of the user, and follow Alibaba Cloud’s documentation.

The rule is called Alibaba Cloud Access Key ID. It looks for the literal LTAI prefix, which is case sensitive, followed by exactly 20 letters and digits, with a word boundary on each side. The match is self-contained, so no nearby word is needed. A value that is one character longer or shorter is not reported. The severity is critical. This type is not checked live: LeakWatch does not send any request to Alibaba Cloud with the key it found. A separate rule looks for the secret half near the ID, which is why a file that contains both values is the most urgent case.