Contain, then fix

Response runs in an order that protects evidence and limits damage at the same time. Get the order wrong and you either destroy the investigation or let the intruder watch you work.

The order: contain → eradicate → recover

Contain first: isolate the host from the network (but leave it powered on), revoke the compromised sessions and keys, block the attacker source at the perimeter. Goal: stop the bleeding without wiping anything. Containment actions should be reversible — you may be wrong about the scope, and irreversible actions on a wrong scope are a second incident.

Eradicate second: remove the cause once you know what it is — the guessed password (rotate it everywhere it was reused), the malware persistence (scheduled task, rogue key, web shell), the misconfiguration (open bucket, default credential). Eradication without identification is whack-a-mole: the intruder returns through the door you never found.

Recover third: restore from known-good media, force password resets in the blast radius, and watch closely before declaring normal. Normal is declared by monitoring agreement (clean logs for a full cycle), not by feeling.

Two mistakes that define failed responses

Wiping the machine before imaging it destroys the evidence you need to answer how far it went — scope questions (did they reach the database?) become unanswerable, and unanswerable scope means notifying everyone about everything. And skipping containment to jump to fixes lets an active intruder watch you work: rotated credentials get re-stolen, rebuilt hosts get re-entered.

Slow is smooth: contain, understand, eradicate, recover, then write the timeline while it is fresh. The post-incident review asks what the timeline shows, and timelines written a week later are fiction.

Key takeaways

• Contain (reversible) → eradicate (the actual cause) → recover (monitored return to normal).
• Never wipe before imaging; never fix before containing.
• Write the timeline immediately — delayed timelines are fiction.