The eradication phase is the part of incident response focused on removing the attacker’s presence from the environment after containment. It goes beyond stopping active behavior and includes deleting malicious files, removing tools, and clearing residual components so the compromise cannot be easily reactivated.
Expanded Definition
Eradication phase means the work that removes an attacker’s foothold after containment has stopped active spread. In incident response, that includes deleting malicious binaries, removing persistence mechanisms, clearing scheduled tasks or services, revoking abused access paths, and checking for hidden backdoors or staged tools that could restore access.
The boundary that matters is simple: containment limits the blast radius, while eradication removes the cause of the compromise. A team can isolate a host and still fail if a persistence mechanism, implanted account, or dormant loader remains in place. Guidance is consistent on this point, although the exact sequence varies by environment and incident severity. For a process-level reference, NIST’s incident handling guidance is useful because it treats eradication as a distinct post-containment activity within the broader response lifecycle.
Eradication is not the same as recovery. Recovery restores service and trust after the environment has been cleaned. If eradication is incomplete, recovery only returns systems to a compromised state.
Examples and Use Cases
- Removing ransomware executables, registry persistence, and any shadow copies or reintroduced payloads before rebuilding affected endpoints.
- Deleting web shells from a compromised application server and verifying that attacker-created scripts, cron jobs, or startup entries are gone.
- Revoking stolen credentials, API keys, or tokens that were used to maintain access, then replacing them where the environment still needs the capability.
- Cleaning up malicious mailbox rules or forwarding settings after an email compromise so the attacker cannot continue siphoning messages.
- Scanning adjacent systems for the same tooling or persistence pattern when the original entry point may have been reused across the environment.
The practical trade-off is speed versus confidence. Fast removal reduces dwell time, but partial cleanup can leave the organisation exposed to re-entry, especially when the attacker used multiple persistence methods or a living-off-the-land approach that blends into normal administration.
Security Implications
Eradication failures usually show up as re-compromise, repeated alerts on the same host, or attacker activity that resumes after containment is lifted. The main security problem is not simply that malware remains, but that the attacker’s operating conditions remain: an intact backdoor, a surviving account, a token that was never revoked, or a management channel that was not reset.
That makes eradication a trust-restoration task as much as a removal task. If responders delete obvious files but miss scheduled tasks, remote management agents, injected services, or cloud-access keys, the environment may look clean while still being controllable by the adversary. In identity-heavy environments, the most durable residue is often not a binary but a credential or role assignment that continues to authorize access.
Practitioners should treat unexplained recurrence of the same indicators as evidence that eradication was incomplete, not merely that detection was noisy. If the compromise can be reactivated without fresh exploitation, the incident response effort has not actually finished.
Domain and Governance Relevance
Eradication matters because it is the control point where an organisation decides whether it is removing artefacts or removing attacker capability. That decision has governance consequences: the response owner, infrastructure team, identity team, and application owner often each hold part of the cleanup scope, and gaps between them are where remnants survive.
In identity and NHI-heavy environments, eradication often extends beyond hosts into service accounts, API keys, certificates, automation tokens, and delegated access. A compromised non-human identity can persist even after the affected system is rebuilt, so the cleanup scope must match the access model, not just the endpoint. For readers working in identity security, the OWASP Non-Human Identity Top 10 is a useful companion reference because it frames machine-credential exposure and lifecycle control as part of the same trust problem.
The governance question is therefore not only “Was the malware removed?” but “Was every mechanism that sustained access identified, owned, and eliminated before recovery began?”
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST IR 8596, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST IR 8596 | ER — Eradication | Eradication phase is a direct match to incident eradication guidance. |
| Recommendation — Remove attacker artefacts and persistence mechanisms before moving to recovery. | ||
| CIS Controls v8 | 6 — Access Control Management | Revoking abused accounts and tokens is central when eradication touches access paths. |
| 8 — Audit Log Management | Logs help confirm whether malicious persistence or re-entry remains after cleanup. | |
| Recommendation — Revoke compromised accounts, keys, and tokens that sustained unauthorized access. Review logs to validate that attacker activity and persistence have been eliminated. | ||
| NIST CSF 2.0 | RS.MI — Mitigation | Eradication is the mitigation step that removes the incident cause after containment. |
| Recommendation — Apply mitigation actions that remove malicious code, accounts, and persistence paths. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Eradication in identity-heavy incidents often requires removing abused machine credentials. |
| Recommendation — Rotate or revoke exposed machine secrets and credentials that enabled reactivation. | ||
Related resources from NHI Mgmt Group
- How should security teams phase out password-based authentication without disrupting operations?
- How should security teams phase out SMS OTP without breaking access?
- When should teams move from target-phase controls to advanced OT Zero Trust controls?
- How should organisations phase an identity governance programme to reduce risk?
