Why is deleting the implant from the one server that alerted not eradication?
answer
- one file is not the foothold
- the alert marks where you had eyes
- persistence elsewhere, credentials, the way in
- containment stops damage, eradication removes return
basics
~20 sBecause eradication targets the intruder's whole foothold, not one file. They may hold persistence on other hosts, valid credentials taken from yours, and the same unfixed way in. Deleting an implant removes an artefact, not their access.
solid answer
~50 sAn alert tells you a rule matched records from a sensor on one host. It does not measure the estate, so the alerting server is where you had visibility, not the boundary of the intrusion. Deleting the implant leaves at least four things intact: persistence planted on other hosts, such as an added `authorized_keys` entry, an undeclared systemd timer or a package hook; credential material harvested from the box; the initial access vector that let them in; and any configuration they changed. Eradication is a fleet-scoped statement — every known persistence mechanism swept everywhere it could live, the entry route closed, and the access they hold invalidated. Containment stops the damage happening now; eradication removes the means of return. Removing one file is neither, and doing it before you have scoped the intrusion can also cost you the evidence that would have told you where else to look.
go deeper
Be ready to name the phases and say plainly that eradication is about the adversary's ability to return, not about one file. Have the four survivors ready: persistence elsewhere, credentials, the entry vector, changed configuration.
Explain why an alert is evidence about your coverage rather than about the estate, and list concrete persistence mechanisms a sweep would have to cover on a Linux fleet and on a Windows host.
Show how you would turn the single alert into a scoped sweep: which mechanisms, which hosts, what you do about hosts with no telemetry, and what you would need before you would call the fleet eradicated.
Own the framing others will push back on — that an intrusion does not end when the service is healthy, and that closing on the alerting host alone converts a solved incident into a repeat one that costs far more.
## The phases, and which one you are actually in The NIST SP 800-61 arc runs detection and analysis, then containment, then eradication, then recovery. Two of those words get used interchangeably in interviews and they are not the same thing. **Containment** stops the harm that is happening right now — cutting a host off the network, disabling an account, blocking an egress destination. It buys time and it stops the bleeding, but the adversary's ability to come back is untouched. **Eradication** removes that ability: every persistence mechanism they planted, the credentials and keys they can still use, and the way they got in. It is a statement about the whole estate, not about one machine. Deleting a malicious file from one server sits below both. It is artefact removal. ## What the alert actually proved This is the direction-of-evidence point that a junior answer usually gets wrong. An alert firing means: a detection rule matched records produced by a sensor that was installed, healthy and reporting on that host, for behaviour someone had already thought to write a rule for. It proves a rule fired. It does not prove that host is the only one affected, and the absence of alerts on the other servers proves nothing at all about them — on a fleet where a third of the hosts run no endpoint sensor, silence from those hosts is the expected output whether they are clean or not. So the alerting server is best read as *where you happened to have eyes*, and the intrusion's real footprint has to be established by sweeping, not by counting alerts. ## The four things that survive the delete 1. **Persistence on other hosts.** An intruder with credentials and a scripted deployment does not plant one mechanism on one box. On a Linux fleet the classic spread is an extra key in `~/.ssh/authorized_keys` for root or a service account (`T1098.004`), a systemd `.timer` unit paired with a `.service` unit that runs on a schedule (`T1053.006`), an entry in `/etc/cron.d` (`T1053.003`), and a drop-in under `/etc/apt/apt.conf.d/` whose `DPkg::Post-Invoke` line executes on every package operation. On the Windows jump host the equivalent is a WMI event subscription — a filter, a consumer and a binding registered in the CIM repository (`T1546.003`) — which is not a file at all. 2. **Credentials.** Anything they read off the host — SSH private keys, an agent token, a database password in a config file, a cloud instance credential — remains valid after the implant is gone. Deleting a file does not revoke anything. 3. **The initial access vector.** If the unpatched service, exposed management port or stolen key that let them in is still there, the same route works tomorrow and you get to do this again with a new implant. 4. **Configuration changes.** A new local account, a relaxed `sshd` setting, a firewall exception, or — worst case — a change committed into the configuration-management repository, which will be re-applied to every host you rebuild. ## What 'done' would look like instead Eradication is called done against criteria, not against a feeling. In outline, that means: every mechanism you know they used has been searched for across every host in scope, not only those that alerted; hosts you could not search are accounted for rather than assumed clean; the entry vector is closed and the closure verified; the access they hold has been invalidated; and there is a defined watch for re-entry with named tripwires. Those are the deliverables that let an incident lead say the intruder has no path back. ## Why the mistake is so common It is the reliability instinct applied to a security problem. In an outage, when the bad thing stops and the service is healthy, you are finished. In an intrusion, the bad thing stopping may only mean the adversary saw you coming, went quiet, or moved to the foothold you have not found. A clean host is a result about a host. Eradication is a result about an adversary.
- The alert fired on one host in a 300-server fleet. Why can't you infer the intrusion stops there?Because an alert is a function of your coverage, not of the adversary's footprint. It fired where a sensor was installed and healthy and where a rule already modelled that behaviour. A third of this fleet has no endpoint agent at all, so those hosts would look identical whether or not they were touched. Scope comes from sweeping every host for the mechanisms you know they use, not from the alert count.
- Give the difference between containment and eradication in one sentence each.Containment stops the damage and access that is happening right now — isolating the host, disabling the account, blocking the egress — while accepting that the adversary could still return. Eradication removes the means of return: the persistence they planted wherever it lives, the credentials and keys they can still present, and the entry vector that admitted them in the first place.
- Is there a case for not deleting the implant immediately?Yes. The implant is often your best description of what to sweep for — the mechanism it uses, the paths it writes, the destination it talks to. Deleting it before that is extracted can leave you sweeping for a shape you no longer know, and on a live intrusion the sudden disappearance of their tooling is also a signal to the person watching.
saying these in an interview costs you the question
- Calls the incident over once the malicious file is deleted
- Treats the alerting host as the full scope of the intrusion
- Reads no alerts on other hosts as evidence those hosts are clean
- Uses containment and eradication as if they were the same phase
- Wipes the host before anyone recorded what was on it