Eradication, Recovery and Lessons Learned
What is it?
The closing phases turn a contained incident into a resolved one. Eradication removes the attacker completely — every foothold and persistence mechanism across the whole scoped set of hosts, not just the one process you first saw. Recovery restores affected systems and validates they are clean and functioning, watching for re-infection. Lessons learned is the post-incident review that converts the whole episode into durable improvement: new detections, hardening, and a written report for stakeholders.
Why it matters
Most repeat incidents are the first incident, badly closed. Eradicate only what you saw and the attacker returns through the foothold you missed. Recover without validation and you hand back a still-compromised system. Skip lessons learned and the same gap is exploited again next quarter. These phases are where an incident either becomes a permanent improvement or a recurring nightmare — and the written report is how the organisation actually learns.
Where you see it
Eradication removes persistence (run keys, scheduled tasks, services, accounts) and rebuilds where needed, guided by the scope and the IOCs. Recovery restores from known-good backups, resets credentials, and monitors for return. Lessons learned produces the post-incident report, feeds new detections to detection engineering (Module 7) and new hunt hypotheses (Module 8), and drives hardening.
What normal looks like
Clean closure: eradication removes every foothold across all scoped hosts; recovery restores from known-good state, resets exposed credentials, validates the systems, and monitors for re-infection before declaring done; and a lessons-learned review produces a report, new detections, and hardening actions with owners. The incident makes the organisation measurably harder to hit the same way again.
What suspicious looks like
Broken closure: eradicating only the first-seen process while other persistence and other hosts remain; restoring from backup without resetting exposed credentials or validating (so the attacker walks back in); declaring victory with no monitoring for re-infection; or closing with no report and no improvements, so nothing was learned and the next identical intrusion is not caught any faster.
How analysts investigate
Eradicate against the scope and IOCs, not against a single host — remove every persistence mechanism on every affected asset, resetting exposed credentials. Recover from known-good state, validate each system is clean and functioning, and monitor for re-infection before closing. Then run the review: write the report, hand new detections to detection engineering, seed new hunts, and assign hardening actions with owners.
Common beginner mistakes
- Eradicating only the first foothold you found and missing the rest across the scope.
- Restoring without resetting exposed credentials or validating, so the attacker returns.
- Closing with no report and no improvements, so the organisation learns nothing.
What you will be able to do
- Eradicate every foothold across the full scope, not just one host.
- Recover with credential reset, validation and re-infection monitoring.
- Run a lessons-learned review that produces a report and improvements.
Containment bought you time; now you make the incident permanent — permanently gone, and permanently learned from. Eradication is scope-driven: you already scoped the intrusion, so you remove every foothold on every affected host, not just the process that first tripped the hunt. Recovery is verified, not hopeful: restore from known-good, reset what was exposed, and watch for the attacker walking back in. And lessons learned is what makes it all worth it — the report and the improvements that stop the next one.
| Phase | Done right | Done wrong (repeat incident) |
|---|---|---|
| Eradicate | Remove all footholds across the whole scope | Kill one process; miss the rest |
| Recover | Restore known-good, reset creds, validate, monitor | Restore blindly; attacker walks back in |
| Lessons learned | Report + new detections + hardening | Close silently; learn nothing |
Worked example — is the incident ready to close?
The team killed the malicious process on FIN-WS-12 and restored it from backup. Someone proposes closing the incident. Before reading on, decide: is it ready? The answer: no, on several counts. Eradication was one host, but scoping found the same run-key persistence on three more — those are untouched, so the attacker still has footholds. Recovery restored FIN-WS-12 but the exposed domain credentials were never reset, so the attacker can log straight back in, and no one is monitoring for re-infection. And there is no report and no new detection, so if this exact technique returns next month it is caught no faster than the first time. To close properly: eradicate across all four hosts, reset the exposed credentials, validate and monitor, then write the report and hand the technique to detection engineering. 'The process is dead' is the middle of closure, not the end.
Recap
- Eradicate against the scope — every foothold on every affected host, not just one.
- Recover with credential reset, validation and re-infection monitoring — not blind restore.
- Lessons learned turns the incident into detections, hunts, hardening and a report.
Sign in to save your progress on the server.