Respond to a leaked AWS access key — fast

Leaked AWS keys are everywhere — committed to GitHub, baked into mobile apps, lifted from a developer's laptop. When one leaks, the gap between a non-event and a breach is how fast you respond. Here's the playbook.

1. Contain first, investigate second

Don't wait to understand everything. Immediately deactivate the exposed access key, and if it belongs to an IAM user, attach a deny-all 'quarantine' policy so it can do nothing while you dig in.

aws iam update-access-key \
  --access-key-id AKIA... \
  --status Inactive \
  --user-name compromised-user

2. Map the blast radius

Use CloudTrail to reconstruct exactly what the key did: which APIs, from which IPs, starting when. Check GuardDuty for findings like anomalous API calls or credential exfiltration. Hunt specifically for persistence the attacker may have planted:

• New IAM users, roles, or access keys you didn't create.
• Changed trust policies or freshly attached admin policies.
• Resources launched in unusual regions — often crypto-mining.

3. Eradicate and rotate

Delete the leaked key, rotate related secrets, revoke active sessions, and remove anything the attacker created. Assume one foothold leads to others until CloudTrail proves otherwise.

4. Make the next leak harmless

• Stop issuing long-lived keys — prefer IAM roles and IAM Identity Center (SSO) with short-lived credentials.
• Enforce IMDSv2 so a stolen instance can't have its role credentials trivially scraped.
• Add secret scanning to your repos and CI to catch keys before they ship.

Rehearse this as a drill before you need it. A team that has practiced key-compromise response contains it in minutes; one that hasn't loses hours — and that's where the damage happens.