Tools · Cloud security · 24 / 24
Leaked cloud access key: a first-hour response checklist
A calm, ordered checklist for when an access key or service account key shows up in a public repository: contain, scope with logs, remove persistence, and rotate.
Contain first
Disable or delete the leaked key immediately. On AWS, deactivate the access key and, if the key belonged to a role session, revoke active sessions by adding a deny for tokens issued before now. On GCP, delete the service account key. On Azure, rotate the client secret or certificate for the app registration. Removing the file from the repository is not enough: the history and any forks still have it.
Scope with logs
Search the audit logs for every call made with that key, starting from the time it was first exposed. Note the source IPs, regions, and API calls. Typical attacker activity includes identity enumeration calls, creating new users or keys, launching compute in unusual regions, and reading storage.
# AWS: all events for one access key in the last 90 days
aws cloudtrail lookup-events --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIAEXAMPLEKEY \
--query 'Events[].{t:EventTime,name:EventName,src:CloudTrailEvent}' --max-results 50Lab: tabletop the scenario
In a sandbox account, create a throwaway IAM user with a key and read-only permissions, use it for a few harmless calls such as listing buckets, then pretend it leaked. Time yourself through the checklist: deactivate the key, find every event it produced in CloudTrail, list any IAM users, keys, or roles created in the window, and write a short timeline. Delete the user at the end.
Remove persistence and recover
Look for anything created during the exposure window: new IAM users, access keys, roles with trust policies to unknown accounts, Lambda functions, instances, and changes to logging. Remove them, then rotate any secrets the key could read. Finally, find the root cause: add secret scanning to the repository and replace long-lived keys with short-lived credentials.
Diagram
First hour after a key leak
- Contain
Deactivate or delete the key; revoke sessions.
- Scope
Pull every audit event for the key since exposure.
- Remove
Delete users, keys, roles, and resources created by the attacker.
- Recover
Rotate reachable secrets, add secret scanning, move to short-lived credentials.
Check yourself
1. What is the first action when a key is found in a public repository?
2. Why is removing the key in a new commit not enough?
3. Which artifacts often indicate attacker persistence after a key leak?