AWS Account Compromise Response: What to Do in the First Hour

IAM credential compromise is the most common AWS security incident — stolen access keys, leaked CI/CD secrets, compromised developer laptops with AWS credentials cached in ~/.aws/credentials. The attack pattern is consistent: attacker obtains credentials, quickly tests permissions, launches EC2 instances for crypto mining or other abuse, and may attempt to create backdoor access before the credentials are revoked.

The response timeline matters enormously. A credential that's compromised but revoked within 15 minutes causes far less damage than one that runs for 4 hours. This guide documents the specific response playbook for IAM credential compromise, with the actions organized by priority.

Step 1: Contain (0-5 Minutes)

The single most important action is disabling the compromised credential as fast as possible. Don't pause to investigate first. Investigation takes time; containment takes 30 seconds.

For an IAM access key:

aws iam update-access-key   --access-key-id AKIAIOSFODNN7EXAMPLE   --status Inactive   --user-name username-here

For a role with potentially compromised sessions, revoke all active sessions:

aws iam update-assume-role-policy   --role-name role-name   --policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Deny","Principal":{"AWS":"*"},"Action":"sts:AssumeRole"}]}'

Or use the IAM console to add a deny-all inline policy to the role, which takes effect immediately for all subsequent API calls (but doesn't invalidate already-issued session tokens until they expire — typically in 1-12 hours).

To immediately invalidate all active sessions for a role, use the role's "Revoke active sessions" feature in the IAM console, which adds a condition-based policy that denies all actions for sessions issued before the revocation time. This is more aggressive than modifying the trust policy and takes effect immediately for all active session tokens.

Step 2: Alert and Escalate (0-5 Minutes, Concurrent)

Notify your security lead and incident commander while containment is happening. One person runs containment commands; another starts the escalation tree. The incident commander:

• Opens a dedicated communication channel (Slack incident channel, Zoom call)
• Notifies leadership if the incident severity warrants it
• Opens an AWS Support case if the incident involves significant unauthorized resource creation or requires AWS assistance
• Starts the incident timeline documentation (real-time log of actions taken, when, and by whom)

Step 3: Assess Scope (5-30 Minutes)

With the compromised credential disabled, begin CloudTrail investigation to understand what was done during the compromise window.

Query CloudTrail for all actions by the compromised principal. If the incident started more than 90 minutes ago, you need to look at multiple CloudTrail log files. For urgent investigation, use CloudTrail Event History in the console (filtered by username or access key ID) which provides the past 90 days of data immediately without Athena setup.

Key questions to answer during scope assessment:

• What new resources were created? EC2 instances, S3 buckets, IAM users/roles/policies, Lambda functions, SES sending identities. List all resources created by the compromised principal.
• What data was accessed? S3 GetObject calls, DynamoDB queries, RDS connections (via CloudTrail data events if enabled). Identify whether customer data, credentials, or other sensitive data was accessed.
• Were backdoors created? New IAM users, new access keys for existing users, new roles with administrative permissions, Lambda functions or EC2 user data scripts that establish ongoing access. This is the highest-priority item — if the attacker created backdoors before containment, they can continue operating despite the original credential being revoked.
• Were other credentials exposed? If the compromised credential was used to read Secrets Manager, SSM Parameter Store, or environment variables containing other credentials, those secondary credentials may also be compromised.

Step 4: Eradicate (30-60 Minutes)

Remove everything the attacker created and close all backdoors identified in the scope assessment:

• Terminate all unauthorized EC2 instances (verify which instances are legitimate before terminating)
• Delete unauthorized IAM users, access keys, and roles
• Detach or delete unauthorized IAM policies
• Delete unauthorized S3 buckets (after verifying contents — data may need to be preserved as evidence)
• Revoke or delete unauthorized Lambda functions or other automation resources
• Remove unauthorized SES sending identities

For each eradication action, document: what was removed, what legitimate purpose (if any) it might have served, and how you verified it was unauthorized. This documentation is essential for post-incident review and any insurance or legal proceedings.

Step 5: Recover and Harden (1-24 Hours)

After eradication, restore normal operations with improved security:

Issue new credentials to replace the disabled ones. For IAM access keys, create a new key and distribute it to the legitimate user or system that was using the compromised key. Update all places the key was used (CI/CD secrets, application environment variables, developer machines).

Rotate all credentials that might have been accessed during the compromise, not just the one you know was compromised. This includes: any access keys visible in the environment where the original key was stored, any Secrets Manager secrets readable by the compromised role, any RDS or other service passwords stored in the account.

Enable MFA for any accounts that didn't have it. Add a waiting period before MFA can be bypassed. Consider hardware MFA for the most privileged accounts.

Review and tighten permissions on the compromised principal's account. If a developer's personal access key was compromised, review whether that developer's key had permissions that were broader than needed for their actual work.

Step 6: Review (24-72 Hours)

Conduct a post-incident review within 72 hours while details are fresh. Key questions: How were the credentials obtained? (GitHub leak, laptop compromise, phishing, CI/CD exposure.) What monitoring should have detected this faster? What controls would have limited the blast radius? What actions need to be added to the incident response runbook?

Document the timeline, root cause, contributing factors, and remediation actions. This document is essential for compliance audits (SOC 2 incident log, HIPAA breach determination), customer notifications if required, and continuous improvement of your security posture.

Related Reading

• AWS incident response plan — building the broader incident response process
• Security runbooks — pre-built response procedures for common scenarios
• IAM security monitoring — detection controls that identify compromise early
• CloudTrail forensic analysis — using CloudTrail for incident investigation

FAQ

How do I know which CloudTrail events were from the attacker vs. legitimate use?

Filter CloudTrail by the access key ID, not just the username. The access key ID uniquely identifies the credential — legitimate access might use a different key on the same account. Check the sourceIPAddress field for geographic anomalies: legitimate use is from your office IP, your CI/CD runner IPs, or known developer IP ranges. Access from an unfamiliar IP to the same user account as known-good IPs is a strong indicator of compromise.

Should I preserve the compromised resources for forensics before destroying them?

For significant incidents involving potential legal action, insurance claims, or regulatory notification, preserve evidence before destroying. Create AMI snapshots of compromised EC2 instances before termination. Export relevant CloudTrail logs to S3 with a preservation note. Store these artifacts in an isolated account or S3 bucket with restricted access and a legal hold. For routine incidents without legal implications, eradication is more important than preservation.

How do I prevent IAM credential compromise in the first place?

The most effective preventive controls: use IAM roles instead of access keys for workloads running on AWS (EC2, Lambda, ECS) — roles don't have long-lived credentials to steal. For access keys that must exist, enable MFA for all operations, rotate keys automatically every 90 days, scan repositories for leaked credentials with tools like git-secrets or GitHub's credential scanning. Enable GuardDuty's credential-based findings to detect usage of credentials from unexpected locations.