Are They Really Gone? The Eradication Question Nobody Answers Well
The incident has been contained. The entry point is patched. The compromised account is disabled. The C2 domain is blocked. Everyone is exhausted, and someone in leadership has asked twice whether this is over. The instinct is to say yes.
It is probably not over.
Containment and eradication are different operations, and confusing them is one of the most reliable ways to turn a manageable incident into a repeat incident. Containing an attacker means you have cut off the path you know about. Eradicating them means you are confident they have no path left. The distance between those two things is where persistence mechanisms live, and most post-incident environments have at least one.
What Persistent Access Actually Looks Like
Attackers who operate with any level of sophistication do not run on a single foothold. They assume they will be detected eventually. The job, from their perspective, is to build enough redundancy that detection of one access path does not end the engagement.
Web shells are a classic example: a small script dropped on a web-facing server that provides command execution through what looks like ordinary web traffic. Patch the initial vulnerability, miss the web shell, and the entry vector is gone while the attacker is still there, just coming in through the front door.
Scheduled tasks and autorun persistence are similar. An attacker who spends any meaningful time in a Windows environment will establish at least one form of scheduled execution. The account they used may be disabled. The malware sample may be quarantined. The scheduled task that re-runs the dropper is still there, waiting for the next reboot or time window.
Credential theft complicates things further. If the attacker had access for more than a few hours, they have credentials. Not just the one you disabled. Credentials harvested from memory, from files, from browser storage, from anything they touched. Those credentials are now in someone else's hands. Rotating the account you know was compromised does not address the credentials you do not know about.
Lateral movement means the scope of "compromised" is almost always larger than what you initially identify. The first compromised host was not the last stop. The path that led to the sensitive data was not a single hop. Knowing that a user's workstation was the entry point tells you where it started, not the full route or every destination.
The False Certainty of a Clean Scan
The forensic scan came back clean. The endpoint tool is not showing active threats. The SIEM is quiet. This is reassuring, and it is not the same as confirmation.
Detection tools are built against known patterns. An attacker using custom tooling, living-off-the-land techniques (standard system utilities doing attacker work), or novel persistence methods can be present in an environment that a scanner will report as clean. Absence of detection is not presence of cleanliness. A defender who has been in the field long enough has a healthy relationship with this distinction.
Threat hunting during the eradication phase is different from waiting for alerts. Hunting is active and hypothesis-driven: if the attacker had access to system X for three days, what would they have done, and what evidence would that leave? You work backwards from what you know about their behavior and look for the traces of activity you might not have flagged, rather than waiting for the next alert to fire.
What a Real Eradication Checklist Looks Like
The question at the end of eradication is not "did we fix the finding?" It is "do we have evidence-based confidence that the attacker has no remaining foothold?" That is a harder standard, and meeting it requires specific work.
Account audit across the environment, not just the accounts you know were used. If a credential harvester ran for any period of time, assume all accounts the compromised system could reach are potentially stolen. Reset them. Check for accounts created during the incident window. Check for accounts with newly added privileged group membership that has no business explanation.
Artifact hunting on every host reachable from the known compromise, not just the hosts where you observed attacker activity directly. Web shells, scheduled tasks, new services, modified startup entries, unusual parent processes. This is tedious on large environments. It is the work.
Certificate and token invalidation where applicable. OAuth tokens, API keys, SSH authorized keys, anything that provides durable access separate from password-based authentication should be audited for anything issued or added during the incident window.
Network traffic review for communication patterns matching known attacker infrastructure, even if it is not in your existing blocklist. Generic cloud infrastructure commonly used for command and control, recently registered domains, unusual data volumes to external destinations.
A defined close criteria: a specific list of things that must be confirmed before the incident is officially closed, agreed to by the team before the pressure to be done peaks. Not "the CISO thinks it is done" but "here is the checklist and here are the results against each item."
The Temptation to Just Call It
The pressure to close an incident is real. Leadership wants certainty. Engineers want to stop sleeping near their laptops. The business wants normal operations. All of this is legitimate pressure, and it conspires against the careful verification work that actually earns the "closed" status.
The organizations that handle this well have a phrase for it: closed with confidence versus closed with hope. Closed with hope is what happens when you fix what you found, run a quick scan, and declare victory because the pressure to be done exceeded the evidence for being done. Closed with confidence is when you have worked through a defined eradication checklist and can point to specific evidence for each item on it.
Closed with hope is also how you explain to the board, six weeks later, why you are in the same incident again.
The incident is not over because you want it to be. It is over when you have done the work that earns the confidence. Build that standard before the exhausted team is looking for permission to go home, so the answer is a process and not a mood.