HackBlue

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.

9 min read · practice only with authorization

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.

Snippet
# 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 50

Lab: 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

  1. Contain

    Deactivate or delete the key; revoke sessions.

  2. Scope

    Pull every audit event for the key since exposure.

  3. Remove

    Delete users, keys, roles, and resources created by the attacker.

  4. 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?