Responding to a Compromised AWS Access Key

You wake up to this email from AWS: Irregular Activity Detected for Your AWS Access Key As part of our standard monitoring of AWS systems, we observed anomalous activity in your AWS account that indicated your AWS access key(s), along with the corresponding secret key, may have been inappropriately accessed by a third party. Your stomach drops. The email links to a compromised access key: AKIA1234567890ABCDEF . User: app-integration-user . Event: GetCallerIdentity . Time: yesterday at 12:11:58 UTC. IP: 198.51.100.50 . AWS gives you four steps: Rotate the key. Check CloudTrail for unwanted activity. Review account for unexpected usage. Respond to the support case. Four steps. Clean. Linear. Assumes everything goes right. It won't. What AWS Documentation Assumes AWS's steps assume: CloudTrail is already enabled and logs are queryable. Someone on your team knows how to read CloudTrail. You have time to investigate without pressure. The only damage is the exposed key. Rotating the key is enough to fix it. In reality: CloudTrail might not be enabled. Or enabled but logs are in an S3 bucket nobody checks. The person who set up the account left months ago. You have 4 hours before customers start calling about errors. The attacker might have created backdoor credentials, roles, or policies while they were in. Rotating the key stops them from using that key. But if they left a trail of IAM users, keys, or assumed roles behind, you're still exposed. What Actually Happened You look at the details. The compromised key belongs to app-integration-user . A user who was supposed to only send emails via SES. Instead, someone called GetCallerIdentity from IP 198.51.100.50 at 12:11 UTC. (If the compromised key is your root account's access key : this is a P1 incident. Root cannot be restricted by IAM policies. Rotate immediately, audit all root activity in the last 30+ days, and contact AWS Security right now.) That one call tells you: The key was exfiltrated (not guessed in a bruteforce). The attacker tested it immediately to confirm it works. They got basic information about your account and role. The next calls happened after that test. Now you need to answer: What did they do next? This is where the 4-step plan breaks down. AWS doesn't tell you how to find that out if your logs aren't ready. The Three Things That Actually Save You 1. Access to CloudTrail, Even If It's Basic If CloudTrail is off or inaccessible, you're blind. You can't answer the question: What happened after that GetCallerIdentity call? If CloudTrail is on: aws cloudtrail lookup-events \ --lookup-attributes AttributeKey = AccessKeyId,AttributeValue = AKIA1234567890ABCDEF \ --start-time 2026-05-21T12:00:00Z \ --end-time 2026-05-21T14:00:00Z \ --region us-east-1 You'll see every API call made with that key. Not glamorous. Not a dashboard. But it works. And it shows you the sequence: GetCallerIdentity → what came next. From a typical reconnaissance scenario, that query might show: GetCallerIdentity (12:11:58) ListUsers (12:12:05) ListAccessKeys (12:12:12) ListRoles (12:12:19) ListPolicies (12:12:25) GetUser (12:12:33, targeting 'admin-user') The attacker was doing reconnaissance. They're mapping your account structure. That tells you what they might do next: assume the admin role, create a backdoor key, or escalate. Without CloudTrail, you're guessing. With CloudTrail, even basic, you have facts. 2. A Playbook The four AWS steps are necessary but insufficient. A playbook is what you execute while following those steps, what you execute before the key is fully rotated, and what you execute after you think it's over. A minimal playbook for a compromised key looks like this: Immediate (first 30 minutes): Do NOT delete the exposed key yet. Mark it as inactive. You need it in CloudTrail for the investigation. Query CloudTrail for all events from that key in the last 30 days (not just the past hour). Check if that key was used to assume any roles or create temporary credentials. If y