Eradication is the phase of incident response in which defenders remove every component of an attack from the environment: malicious code, attacker accounts, persistence mechanisms, stolen credentials and the vulnerabilities that allowed entry. It follows containment, which stops the damage from spreading, and precedes recovery, which returns systems to normal operation.
In cybersecurity frameworks such as NIST SP 800-61 the phase is usually written as “containment, eradication and recovery”, because the three steps overlap in practice. The distinction still matters: containment buys time, while eradication aims to make sure the adversary cannot simply return once systems are reconnected.
What eradication removes from an environment
Eradication targets the full attacker footprint, not only the file that triggered the first alert. A typical intrusion leaves several layers: an initial access vector, one or more persistence mechanisms, harvested credentials, lateral movement tools and sometimes staged data waiting for exfiltration. Removing only the visible malware leaves the rest in place.
The scope of eradication is defined by the investigation. Digital forensics and the list of indicators of compromise (IOCs) collected during triage determine which hosts, accounts and network paths are affected. An incomplete scope is the most common reason an attacker reappears days or weeks later.
The following table lists the main artifact categories and the typical eradication action for each.
| Artifact category | Typical examples | Eradication action |
|---|---|---|
| Malicious code | Droppers, implants, web shells | Delete, quarantine or reimage the host |
| Persistence mechanisms | Scheduled tasks, services, registry run keys, cron jobs | Remove entries and verify they do not return |
| Attacker accounts | New local admins, rogue cloud identities | Disable, then delete after evidence capture |
| Compromised credentials | Stolen passwords, tokens, Kerberos tickets | Reset passwords, revoke tokens and sessions |
| Exploited vulnerability | Unpatched VPN appliance, exposed service | Patch, reconfigure or decommission |
| Configuration changes | Disabled logging, weakened firewall rules | Restore hardened baseline settings |
How eradication fits between containment and recovery
Eradication sits in the middle of the incident response lifecycle and depends on the steps around it. Containment must be stable before eradication starts, otherwise the attacker can observe the cleanup and move to new footholds. Recovery must wait until eradication is verified, otherwise restored systems are reinfected.
The table below compares the three neighboring phases by goal and typical actions, which helps teams avoid treating them as one undifferentiated step.
| Phase | Primary goal | Typical actions | Done when |
|---|---|---|---|
| Containment | Stop the spread | Isolate hosts, block IOCs, disable accounts | No further spread observed |
| Eradication | Remove the adversary | Clean or rebuild hosts, reset credentials, patch | No attacker presence remains |
| Recovery | Restore operations | Restore data, reconnect systems, monitor | Business runs normally |
Timing is a deliberate choice. Many teams prefer a coordinated eradication event, in which all credential resets, host rebuilds and blocks happen within a short window, often a few hours. Piecemeal cleanup warns a skilled adversary and gives them time to deploy backup access.
Eradication methods and when each applies
The choice of method balances confidence of removal against downtime and effort. Cleaning a host in place is fast but leaves doubt; rebuilding from a trusted image is slower but gives a known-good state.
| Method | Confidence | Downtime | Suitable for |
|---|---|---|---|
| In-place cleanup | Low to moderate | Minutes to hours | Commodity malware with well-understood behavior |
| Reimaging from golden image | High | Hours | Workstations and stateless servers |
| Full rebuild | Very high | Days | Domain controllers, deeply compromised servers |
| Credential and trust reset | High for identity | Hours to days | Active Directory or cloud identity compromise |
| Firmware reflash or hardware swap | Very high | Days | Suspected firmware or bootkit persistence |
Identity compromise deserves special attention. When an attacker has obtained domain administrator rights, eradication typically includes resetting the KRBTGT account password twice, rotating service account secrets and reviewing trust relationships. In cloud environments, it includes revoking refresh tokens, removing rogue OAuth application consents and auditing federation settings.
Verifying that eradication succeeded
Eradication is complete only when verification evidence shows that the attacker is gone. Verification combines targeted scans for known IOCs, threat hunting for related behavior and heightened monitoring of previously affected assets.
- Rescan all scoped hosts with updated detection rules built from the incident IOCs.
- Hunt for related techniques, not just exact hashes, because attackers recompile tools.
- Review authentication logs for use of reset credentials or unexpected new accounts.
- Monitor egress traffic for beaconing to known or similar command-and-control infrastructure.
- Keep enhanced monitoring in place for a defined period, commonly 30 to 90 days.
A security operations center usually owns this monitoring period. If any indicator reappears, the team returns to containment and widens the scope, which is a normal outcome rather than a failure of the process.
Common eradication mistakes
Most failed eradications share a small set of causes. The table links each symptom to its usual cause and the corrective practice.
| Symptom | Likely cause | Corrective practice |
|---|---|---|
| Attacker returns within days | Missed persistence mechanism | Broaden forensic scope before cleanup |
| Reinfection after restore | Backups contained the implant | Scan backups and restore from a clean point |
| Attacker logs in with valid accounts | Incomplete credential reset | Reset all privileged and service credentials |
| Evidence unavailable for legal case | Hosts wiped too early | Image disks and preserve chain of custody first |
| Same exploit used again | Root cause not fixed | Patch or remove the entry point before reconnecting |
Evidence preservation and eradication pull in opposite directions. Wiping a server destroys artifacts that may be needed for chain of custody, insurance claims or regulatory reporting. The usual rule is to capture forensic images first, then clean or rebuild.
The idea in brief
Imagine finding a burglar in a building. First you lock the doors so the burglar cannot reach other rooms; that is containment. Eradication is the next step: searching every room, removing the burglar, changing all the locks and fixing the broken window used to get in.
If you only remove the burglar but leave a copied key behind, they come back. That is why eradication is about removing every way back in, not just the most obvious intruder.
A practical scenario
A mid-sized logistics company detects ransomware staging on a file server. Containment isolates 14 affected servers and blocks two command-and-control domains. Forensic analysis then reveals that the attacker entered through an unpatched remote access appliance, created two hidden domain administrator accounts and installed a scheduled task on 40 workstations.
The response team plans a single coordinated eradication window on a Saturday night. Within six hours it patches the appliance, deletes the rogue accounts, resets the KRBTGT password twice, rotates all service account secrets, reimages the 40 workstations and rebuilds two servers from trusted images after capturing disk images for evidence.
Enhanced monitoring continues for 60 days. One workstation missed during reimaging attempts to beacon in week two; the alert triggers a quick rebuild. After that, no indicators reappear, and the company completes recovery without a second intrusion.