CoursesAWS security engineeringGuardrails, IR & forensics

Incident response & forensics

Contain, revoke sessions, preserve, hunt persistence.

Expert35 min · lesson 15 of 15

Cloud incident response is a race between the attacker and your ability to contain, understand, and evict them — run on infrastructure that is all API calls and short-lived credentials. The winning move is a rehearsed runbook that contains the threat without destroying the evidence you need to understand it.

Contain and preserve, in order

The instinct to terminate a compromised instance is usually wrong: termination wipes memory and can discard the disk. Instead quarantine it — swap to a security group that blocks all traffic, detach from load balancers and Auto Scaling — then snapshot the volume (and capture memory if you can) before any destructive action. Crucially, revoking the leaked key is not enough: already-issued STS session credentials remain valid until they expire, so you must also invalidate active sessions.

isolate, revoke sessions, then preserve
# 1. Quarantine: a security group that allows nothing in or out.
aws ec2 modify-instance-attribute --instance-id i-0abc --groups sg-quarantine
# 2. Detach from serving.
aws autoscaling detach-instances --instance-ids i-0abc \
--auto-scaling-group-name web-asg --should-decrement-desired-capacity
# 3. Revoke ACTIVE role sessions (a key deactivation alone leaves them valid):
aws iam put-role-policy --role-name app-role --policy-name revoke-old \
--policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Deny","Action":"*","Resource":"*","Condition":{"DateLessThan":{"aws:TokenIssueTime":"2026-07-06T00:00:00Z"}}}]}'
# 4. THEN preserve — snapshot before anything destructive.
aws ec2 create-snapshot --volume-id vol-0abc --description "IR-8891 evidence"

Investigate, hunt persistence, recover

With the threat contained, reconstruct everything the compromised identity did from CloudTrail (Amazon Detective visualizes the behavior graph to speed this up), then hunt for persistence — a competent attacker plants a second way in. Look for new IAM users or access keys, altered role trust policies, new roles, resources spun up in unusual regions, and disabled logging. Rotate what was exposed, remove the footholds, rebuild clean, and only then reconnect. Rehearse the whole sequence as a drill so the first real run is not during an incident.

AWS incident response phases
stop the bleeding
contain
quarantine SG, detach, revoke sessions
preserve
snapshot before destroying
understand
investigate
CloudTrail + Detective
hunt persistence
new keys, trust edits, odd regions
restore
eradicate + rotate
remove footholds, rotate secrets
recover
rebuild clean, then reconnect
Contain first, preserve second, understand third. Skipping persistence-hunting is how attackers walk back in an hour later.
Deactivating the key is not revoking the session
Turning off an access key does not invalidate STS session tokens already minted from it — those stay valid until expiry. Attach a token-issue-time Deny (AWSRevokeOlderSessions pattern) to cut active sessions, and terminate only after you have snapshotted the evidence.