Eradication Validation Checklist
The complete pre-recovery gate — the 30-point checklist that every host and the environment must pass before recovery begins. Structured to catch the most commonly missed re-entry paths.
An organization declared eradication complete and began recovery after a ransomware incident. Fourteen days later, the same ransomware group encrypted their environment again. Post-incident analysis showed two things: a service account password was rotated but the old credentials were still valid on a second domain the IR team didn't know existed, and a web shell on a legacy IIS server wasn't found because the server wasn't in the asset inventory. This chapter is the structured gate that prevents those scenarios — applied before declaring eradication complete, not after re-compromise.
Per-Host Eradication Checklist
Apply this to every host in the confirmed blast radius (including "accessed but clean" hosts).
Per-Host Eradication Gate ═══════════════════════════════════════════════════════════════════ HOST: ________________ DATE: ________ ANALYST: ________________ MALWARE AND TOOLING ☐ EDR full scan completed — no detections ☐ All attacker-dropped files identified and removed (hash documented) ☐ All decoded payloads from obfuscated scripts reviewed and removed ☐ Memory forensics completed (if warranted) — no injected code found PERSISTENCE (see Ch10 checklist items) ☐ Registry run keys — audited, nothing suspicious ☐ Scheduled tasks — all non-Microsoft tasks reviewed and cleared ☐ Services — all non-standard services reviewed and cleared ☐ WMI subscriptions — all three object types enumerated, nothing malicious ☐ Startup folders — all user and system startup paths clear ☐ DLL hijacking locations — no unsigned/unexpected DLLs in search paths ☐ COM object hijacking — HKCU\SOFTWARE\Classes\CLSID — nothing unexpected CREDENTIALS ☐ All accounts that authenticated to this host rotated ☐ All local admin account passwords changed ☐ SAM database integrity — no new local accounts added ☐ Service account passwords rotated (if applicable to this host) LOGS AND TELEMETRY ☐ Event logs collected and preserved before any clearing ☐ Log collection/forwarding still functioning (confirm events reaching SIEM) ☐ No suspicious gaps in event log (Event 1102 — log cleared, or time gap) NETWORK ☐ No unexpected outbound connections to known C2 infrastructure ☐ No unexpected listening ports (Compare: netstat -anob vs known baseline) SIGN-OFF Analyst: ________________ Reviewer: ________________
Environment-Level Eradication Gate
In addition to per-host validation, the environment as a whole must clear these checks before recovery begins.
| # | Check | Method | Pass criteria |
|---|---|---|---|
| 1 | All compromised accounts disabled and/or reset | AD audit — list of all known-compromised accounts vs reset log | Every identified account in reset log; none still enabled with old password |
| 2 | krbtgt reset (double) | Check krbtgt last password change date — must be two separate changes >10h apart post-compromise | Both resets documented with timestamps |
| 3 | All Azure AD/Entra refresh tokens revoked | Verify revoke command ran; check for active sessions in Entra ID portal | No active sessions for compromised accounts in portal |
| 4 | Secondary compromise scope closed | DC log analysis complete; all destination hosts examined | No hosts that received authenticated connections from compromised accounts remain unexamined |
| 5 | Initial access vector patched or mitigated | Confirm the patch or configuration change that closes the entry point | Patch applied or WAF rule/network block deployed and verified |
| 6 | All web servers in blast radius checked for web shells | File modification audit on all web roots since compromise date | No suspicious files found, or all suspicious files reviewed and removed |
| 7 | 48-hour post-eradication monitoring window complete | SIEM hunt, EDR alerts review, new account creation, auth anomalies | No attacker activity indicators during monitoring window |
| 8 | All on-premises DNS sinkhole and firewall blocks documented | Firewall rule audit, DNS zone list | Blocks in place and documented for future reference |
| 9 | Backup integrity verified | Restore test from the last clean backup to confirm backups are usable and pre-date the compromise | At least one clean backup available that predates the estimated compromise date |
| 10 | Legal hold confirmed | Legal counsel sign-off that all evidence retention requirements are met | Written confirmation from legal/GC |
The Reimage vs. Remediate Decision
For confirmed compromised hosts, the choice between cleaning in place versus full reimage is a risk decision, not a technical one.
| Factor | Favor reimage | Favor remediate in place |
|---|---|---|
| Dwell time | > 30 days — attacker had extensive time to hide mechanisms | < 7 days — limited time to establish deep persistence |
| Attacker sophistication | Confirmed nation-state or advanced APT — assume unknown persistence | Known commodity tool (Cobalt Strike CS default, no custom implants) |
| Privilege level accessed | SYSTEM or Domain Admin — entire system is untrusted | Unprivileged user account — limited what they could install |
| Confidence in persistence hunt | Low — limited visibility or gaps in EDR telemetry | High — full EDR coverage, no telemetry gaps |
| Business criticality | Less important than security confidence | High-criticality system where downtime cost exceeds risk |
For any host that a sophisticated attacker had SYSTEM or Domain Admin access to for more than a week, the only defensible eradication is a full reimage from a known-good baseline. "We found and removed all the persistence" is a statement of confidence that depends entirely on the completeness of your hunting, your EDR visibility, and your knowledge of every possible persistence technique. Against a sophisticated adversary, those three things will never be 100%. A reimaged host from a clean baseline requires none of that confidence — it's definitively clean. The business cost of reimaging is real, but it must be weighed against the risk of re-compromise from an undetected mechanism on a "remediated" host.
Eradication Report Structure
Before entering recovery, produce an eradication report that documents what was done. This becomes the formal record that the environment is ready for recovery.
Eradication Report Structure
═══════════════════════════════════════════════════════════════════
1. SCOPE SUMMARY
Total hosts confirmed compromised: N
Total hosts in blast radius (including "accessed"): N
Dwell time (estimated): [date range]
2. PER-HOST ACTIONS
For each host: action taken (remediate/reimage), persistence found
and removed, credentials rotated, EDR scan result
3. ENVIRONMENT-LEVEL ACTIONS
Accounts reset: [list with timestamps]
krbtgt resets: [date/time of each reset]
Token revocations: [date/time]
Firewall/DNS blocks deployed: [list]
Initial access vector remediation: [CVE/config change + verification]
4. EVIDENCE PRESERVED
Memory images: [list with hashes]
Disk images: [list with hashes]
Log exports: [list]
Chain of custody log: [location]
5. GAPS AND LIMITATIONS
What you couldn't fully verify (log gaps, EDR coverage gaps,
hosts not accessible during IR)
6. SIGN-OFFS
IR Lead, CISO, Legal Counsel
Date eradication declared complete: _______________
Q & A
Q: You complete the eradication checklist but there's one host you couldn't access — a remote office machine that's been offline since the incident started. Do you proceed to recovery?
No — not without first determining what access that host had during the incident window. Check DC logs and firewall/NetFlow for any activity from that host's IP or any authentication using accounts compromised in the incident during the dwell period. If the host had no activity during the incident window, document it as "offline during incident — no evidence of compromise — must be scanned and cleared before returning to production." Recovery can proceed for the rest of the environment, but that specific host must be quarantined when it returns online, scanned, and cleared before being allowed back onto the corporate network. Add it to a "pending return" list in the eradication report.
Q: Legal says the eradication report is discoverable in litigation. How detailed should it be?
This is a question for outside counsel, not for the IR team. The IR team should write the eradication report factually and accurately — that's always correct regardless of litigation. The question of whether to produce it under attorney-client privilege (by having the report produced at counsel's direction) is a legal strategy question. If this incident is likely to result in litigation or regulatory scrutiny, the IR team lead should confirm with outside counsel before finalizing the report format. A common arrangement: the IR firm is retained by outside counsel, so the investigation report is privileged; an internal "operational" summary contains only remediation steps without findings — which is what gets shared with recovery teams.