Eradication and recovery
🎯You'll be able to
Remove the cause of an incident, restore services safely, and watch closely for a return.
🏠The everyday picture
After termites are found, the owner removes the damaged wood, treats the cause, and checks the house again over the next months. Repainting the wall without treatment would hide the problem.
📘What it really is
- Find the root cause: how did they get in? In the kit's case, a guessed password with no second factor and no lockout.
-
Remove every foothold: reset passwords for affected accounts, revoke keys and tokens, remove added accounts and roles, and check for changed settings.
-
Fix the weakness: the CY4 lockout and MFA plan; the CY6 rules.
-
Recover from known-good sources: rebuild from clean images or restore from backups taken before the incident started, then apply patches before reconnecting.
-
Monitor closely for days or weeks afterwards: the same address, the same account, the same techniques.
- Decide when it's over: the incident lead closes it when the cause is fixed, services are normal and monitoring is quiet.
📝A worked example
Input: the S04 incident, contained.
Steps:
- Root cause: S04's password was guessed; the old login had no lockout or MFA.
- Eradicate: reset S04's password in person, check all role changes since 30 October, and confirm only expected admins remain.
- Recover and monitor: deploy the fixed login with lockout, require MFA for staff, and watch for logins from
203.0.113.77or new addresses for S04 for 30 days.
Expected output: a short recovery note with the root cause, the actions and the monitoring period.
🌍Where it's used
- Ransomware recovery rebuilds from clean backups after removing the attacker's access.
- Account takeover cases at banks reset credentials and add stronger checks.
- Cloud breaches rotate every key that might have been exposed.
📝Case scenario
A company restored its servers from backups after ransomware, but the backups were taken after the intruder's first entry. Two weeks later, the same group struck again through an account they had added. A restore from before the first entry, plus a review of accounts, would have stopped it.
🖱️Try it
List five things to check after a staff account was misused, besides resetting its password. Success: your list includes sessions, roles, other accounts from the same address, settings changes and new accounts.
⚠️Common mistakes
- Restoring without knowing the start date. Sign: backups from after the entry. Fix: set the start from the timeline first.
- Resetting one password. Sign: nothing else checked. Fix: remove every foothold.
- Stopping watching too soon. Sign: monitoring ends the next day. Fix: agree a monitoring period.
🛠️For your project
The playbook's recovery section names the root cause from your timeline and the controls from Projects 2 and 3 that fix it.
✅Quick check
Why must you know when an incident started before restoring from backup?
Show the answer
Backups taken after the start may contain the intruder's changes.
Name two footholds to remove besides the password.
Show the answer
Active sessions and roles or accounts the intruder added (also keys, tokens and changed settings).