Threat Eradication Methods

The central decision in host-level eradication is whether to reimage the system or to clean it manually. Both approaches can be appropriate; the choice depends on the nature of the compromise, the operational constraints, and how much confidence the team needs that the system is clean.

Reimaging is the preferred method for any system where the attacker had administrator or root-level access. At that privilege level, the attacker can modify the operating system kernel, install rootkits that hide processes and files from standard security tools, and alter the firmware of attached hardware. No scanning tool can reliably detect every possible modification at these levels. A reimage from a known-good, offline image eliminates the uncertainty. The process involves wiping the disk, restoring the clean operating system, reinstalling or migrating applications, and applying all current patches before the system is reconnected to the network.

Manual malware removal is appropriate when reimaging is not operationally feasible, when the compromise is limited (such as a commodity malware infection on a non-privileged system with no evidence of lateral movement), or when the forensic investigation must remain active on a live system. Manual removal involves identifying all malicious files, processes, registry entries, scheduled tasks, and services using a combination of antivirus scanning with updated signatures, memory forensics tools, and manual inspection of common persistence locations. Each identified artefact is removed and its removal confirmed. The risk is residual presence: a sophisticated attacker may hide artefacts in locations that scanning tools miss, so manual removal requires a higher degree of investigator expertise and carries more residual uncertainty than a reimage.

Persistence mechanisms are the primary reason incidents recur after an incomplete eradication. If the malware is removed but a single persistence mechanism remains, the attacker can re-establish access within minutes of recovery. Finding all persistence mechanisms requires both automated scanning against known IoCs and systematic manual inspection of every location where persistence can be achieved.

On Windows systems, the most common persistence locations include: scheduled tasks (visible via the Task Scheduler or the schtasks command), registry Run and RunOnce keys in both HKLM and HKCU hives, installed services (especially those with unusual names or paths to temporary directories), startup folder entries in both user and all-users profiles, Windows Management Instrumentation (WMI) event subscriptions (a more advanced technique that survives reboots and is invisible in standard task views), and DLL search order hijacking in application directories.

On Linux and Unix-based systems, common persistence locations include: cron jobs (both user and system crontabs, the /etc/cron.d and /etc/cron.daily directories), rc.local and systemd service unit files, SSH authorised_keys files (especially in root's home directory), modified .bashrc or .profile files that execute code on login, SUID/SGID binaries placed in unusual locations, and web shells deployed on any web-facing directory.

Web shells require specific attention because they persist on web servers at the application layer, below the operating system's standard persistence inspection points. Detecting web shells requires scanning web-accessible directories for scripts that accept arbitrary command input, checking file modification timestamps against the incident timeline, and comparing directory contents against a deployment manifest or version-control snapshot. Tools such as PHP-based shell scanners or YARA rules targeting web shell patterns can accelerate this scan, but manual inspection of flagged files is still necessary because legitimate applications occasionally use patterns that resemble web shells.

Account-based persistence is particularly damaging because valid credentials allow an attacker to authenticate through normal channels, bypassing many detection controls that focus on malware behaviour. Eradication must address both the attacker-created accounts and the legitimate accounts whose credentials were compromised.

Identifying rogue accounts requires comparing the current account list against a pre-incident baseline, reviewing account creation events in directory service logs (Active Directory event 4720 on Windows; auditd USER_MGMT events on Linux), checking for accounts added to privileged groups (Active Directory event 4728, 4732, 4756), and examining accounts with unusual naming patterns, creation timestamps matching the incident timeline, or login history inconsistent with their stated purpose.

The handling sequence for rogue accounts is: disable first, investigate second, delete third. Disabling immediately terminates access. Retaining the account while disabled preserves its attribute data, group memberships, and audit trail for forensic and legal purposes. Only after the investigation team confirms the account has no further evidentiary value should it be permanently deleted. In large enterprises, the HR, legal, and security teams may all need to sign off before deletion.

For compromised legitimate accounts, credential remediation is mandatory. All passwords for accounts with confirmed or suspected compromise must be changed. In environments using Kerberos authentication (standard in Active Directory domains), the KRBTGT account password should be reset twice in succession to invalidate all outstanding Kerberos tickets, including any Golden Tickets an attacker may have forged. Session tokens and application-specific API keys issued to compromised accounts must also be revoked. Multi-factor authentication (MFA) should be enrolled or verified for all privileged accounts before they are returned to service.

Attackers frequently modify system and network configurations to weaken defences, disable logging, open firewall ports, or create access paths that do not depend on malware. These configuration changes must be identified and reversed during eradication, or they persist as vulnerabilities even after all malicious code has been removed.

Common configuration changes made by attackers include: disabling or modifying host-based firewall rules to allow inbound connections, disabling or clearing audit logging (which also destroys evidence, making earlier log preservation critical), adding attacker-controlled SSH keys to privileged accounts, modifying sudoers files to grant elevated privileges to attacker-accessible accounts, changing registry security policies on Windows systems, installing attacker-controlled certificates in the trusted certificate stores, and disabling endpoint protection software or adding exclusions for attacker-controlled directories.

Identifying these changes requires a configuration baseline. Without a documented baseline representing the intended state of the system, it is difficult to distinguish an attacker's modification from a legitimate administrative change made before the incident. Organisations that do not maintain configuration baselines face significantly more work during eradication because they must reconstruct what the intended state was before they can verify that current state matches it. This is one of the strongest arguments for maintaining a configuration management database (CMDB) or automated configuration management system as part of forensic readiness.

Cloud environments introduce eradication challenges that differ from traditional on-premises incident response. Infrastructure as code and ephemeral compute instances change the model for both persistence and remediation. Attackers in cloud environments may establish persistence through IAM role abuse, Lambda function backdoors, EC2 instance profile manipulation, or by modifying infrastructure-as-code templates so that every new resource deployed carries a malicious configuration.

In public cloud platforms (AWS, Microsoft Azure, Google Cloud), eradication actions include: revoking all IAM access keys and session tokens associated with compromised identities, rotating service account keys, reviewing and removing attacker-added permissions and policy bindings, terminating compromised compute instances and replacing them from clean templates, auditing CloudTrail, Azure Monitor, or Cloud Audit Logs for all API calls made with attacker-controlled credentials to determine scope, and checking for attacker-created resources (S3 buckets configured for exfiltration, additional IAM users, outbound VPC peering connections).

In hybrid environments where on-premises Active Directory federates with cloud identity providers, an attacker who has compromised domain credentials may also have persistent cloud access through that federation. SAML token forgery (the Golden SAML attack pattern, similar in concept to Kerberos Golden Tickets) allows an attacker with access to ADFS signing certificates to forge authentication assertions for any cloud service provider. Eradication in this context includes rotating ADFS signing certificates and reviewing all federated application access logs for evidence of forged assertions.

Container and Kubernetes environments introduce their own persistence surface. Attackers may modify container images in a private registry, insert malicious init containers into existing deployments, create ClusterRoleBindings to grant persistent administrative access, or modify Kubernetes admission webhooks to intercept and modify resource creation. Eradication in these environments requires auditing the container registry for modified images, reviewing all Kubernetes RBAC bindings against their intended state, and inspecting admission webhook configurations.

Eradication is complete only when it can be verified, not merely assumed. Verification is a structured set of checks performed against every system that was in scope for eradication. The output of verification is the authorisation to move to recovery. Moving to recovery without a completed verification is a common cause of incident recurrence.

A verification checklist should address each category of eradication action. For malware removal: rescan all previously affected systems with updated antivirus and EDR signatures using the current IoC list, and confirm zero detections. For persistence mechanisms: run an automated tool (such as Autoruns on Windows, or an equivalent on Linux) against every affected system and review every entry against the known-good baseline. For accounts: confirm that all identified rogue accounts have been deleted and that all compromised accounts have had passwords and session tokens reset. For configuration changes: run a configuration compliance scan against the approved baseline and confirm that all identified deviations have been remediated. For the initial access vector: confirm that the exploited vulnerability has been patched or mitigated and that the patch is applied on every in-scope system.

Network-level verification provides an independent check. After eradication, monitored network traffic from previously affected systems should show no communication to any known attacker infrastructure (command-and-control IPs, domains, or patterns identified during the investigation). This is best confirmed through a period of enhanced monitoring with alerts on all IoC-related traffic before full recovery begins. The duration of this monitoring period depends on the dwell time of the original attacker: an incident where the attacker was present for weeks warrants more extended post-eradication monitoring than one contained within hours.