EDR Killers in 2026: The most common ways attackers neutralize endpoint security

Publish date: 21 February 2026
Category: Threat Intelligence / Defense Evasion / Endpoint Security
Tags: EDR, XDR, ransomware, defense evasion, BYOVD, Windows drivers, tamper protection, detection engineering

Executive summary

“EDR killers” are purpose-built tools (or modular capabilities inside broader intrusion toolkits) designed to degrade, blind, or fully disable endpoint security controls right before high-impact actions like credential dumping, lateral movement, data theft, and ransomware deployment.

What’s changed over the past ~24 months is not the idea of killing security software — it’s the reliability and repeatability. Many modern EDR products harden their user-mode services, protect their processes, and gate uninstall/disable actions behind tamper protection. In response, attackers increasingly move below user mode with kernel-assisted tampering, most commonly via Bring Your Own Vulnerable Driver (BYOVD): loading a legitimate, signed (or once-signed) driver and abusing it to gain the privileges needed to terminate protected processes or undermine telemetry. This pattern has been repeatedly documented in ransomware intrusions and “affiliate tooling” ecosystems. (elastic.co)

This post breaks down the most commonly used EDR-killer methods, what they look like in real intrusions, and practical mitigation and detection you can implement without relying on a single control.

Key takeaways

BYOVD is the dominant, highest-success approach because it shifts the fight into kernel space, where many self-protection features are easier to bypass. (elastic.co)
Recent incident reporting shows attackers abusing drivers that are legitimate but old/revoked/expired (and still loadable) to terminate security tooling at scale. (Huntress)
The best outcomes come from stacking controls: driver load hardening (blocklists/HVCI/WDAC) + privilege hygiene + EDR tamper protection + aggressive detection for “security-tool interference” behaviors. (Microsoft Learn)
Treat EDR-killer activity as an incident milestone: if an adversary is trying to blind you, assume they are minutes away from data theft or ransomware.

What is an “EDR killer”?

An EDR killer is any technique or tool whose intent is to impair defenses by:

terminating EDR/AV/XDR processes and services
unloading or abusing drivers
disabling telemetry sources (e.g., event logging)
corrupting agent configs, components, or update channels
forcing the agent into a degraded mode (safe mode / diagnostic mode / suspended state)

In MITRE ATT&CK terms, this aligns primarily to Impair Defenses, especially Disable or Modify Tools (T1562.001). (attack.mitre.org)

Defensive framing: this article is written for detection/mitigation. It deliberately avoids step-by-step “how to” instructions for disabling specific products.

Why EDR killers are so common in ransomware intrusions now

Three forces are converging:

Affiliate economics: ransomware crews want “near-certain” execution. If the encryptor fails due to EDR intervention, the affiliate loses time and access. Tooling that reliably disables endpoint controls increases conversion.
Self-protection raised the bar: many agents now resist ordinary service stops and process kills. That pushes attackers toward kernel-assisted methods.
Driver trust is a chronic weak point: Windows ecosystems are vast; vulnerable drivers are plentiful; blocklists and revocation handling are imperfect, and attackers exploit the gaps. (Microsoft Learn)

The most commonly used methods (what attackers actually do)

1) Kernel-mode tampering via BYOVD (most prevalent)

Pattern: attacker (already admin) loads a legitimate but vulnerable kernel driver and abuses it to gain capabilities such as terminating protected processes, disabling callbacks, or manipulating kernel objects.

Documented examples include tooling like AuKill (abusing an older Process Explorer driver) and multiple ransomware families abusing known vulnerable drivers. (SOPHOS)
BYOVD is a long-running technique, but reporting shows it is increasingly mainstream in ransomware operations. (elastic.co)

Why it works: kernel access can bypass user-mode protections and many agent self-defense mechanisms.

Defender focus: stop (or at least alert hard on) unexpected driver loads, especially from user-writable locations and/or involving known-abused drivers.

2) “Signed-but-still-dangerous” drivers (revoked/expired/stolen cert edge cases)

A notable and very current trend is attackers using drivers that appear “legitimate” to trust controls — even when the associated certificate has long since expired or been revoked.

A February 2026 intrusion write-up by Huntress describes attackers using compromised SonicWall SSLVPN credentials, then deploying an EDR killer that abused a revoked EnCase forensic driver to terminate security processes from kernel mode. (Huntress)
Follow-on coverage notes Windows still allowed that driver to load despite its revoked/expired status, enabling the attacker’s defense impairment step. (BleepingComputer)

Why it matters: many organizations assume “signed driver” ≈ “safe driver.” Reality: “signed” often just means “passed some trust gate at some point in time.”

3) Service/process termination & config tampering (user-mode, but still common)

When attackers have sufficient privileges and EDR is misconfigured (or tamper protection is off), they may still succeed with simpler approaches:

stopping services and scheduled tasks
deleting/modifying agent configuration files or registry keys
abusing legitimate uninstallers or management tooling
blocking agent updates or communication (host firewall rules, DNS tampering, proxy changes)

Official advisories (e.g., Cyber Security Agency of Singapore) have highlighted that these “pre-ransomware blinding” steps are a recurring theme and recommend ensuring tamper protection and privilege hygiene are in place. (Cyber Security Agency of Singapore)

Defender focus: treat unusual sequences of service stop attempts, repeated termination of security tooling, or “agent health drop” events as a high-severity escalation.

4) Telemetry suppression (logging/ETW/event pipeline interference)

EDR killers are often paired with efforts to reduce the defender’s visibility:

disabling or degrading Windows event logging
blocking security telemetry providers
manipulating audit policy settings

In ATT&CK, these behaviors sit under Impair Defenses (T1562) and related sub-techniques (e.g., disabling logging). (attack.mitre.org)

Defender focus: build “health and heartbeat” monitoring: if your expected logs vanish or drop sharply, alert on the absence itself (not just suspicious events).

5) “Living-off-the-land” suspension / safe mode edge cases

Some actor toolkits try to suspend EDR processes (rather than kill them), force endpoints into modes where protections are weaker, or exploit operational gaps (maintenance windows, reboot timing, safe mode assumptions). These vary widely by environment and product, but the practical defense is consistent: lock down privilege, monitor for abnormal mode changes, and alert on sustained “agent degraded” states.

Real-world tooling and campaigns defenders keep seeing

AuKill (BYOVD using Process Explorer driver)

Sophos reported AuKill as a defense evasion tool that abused an outdated driver associated with Microsoft’s Process Explorer utility to disable EDR processes prior to ransomware/backdoor deployment. (SOPHOS)

Terminator / Zemana-driver abuse

Sophos also documented continued abuse and variants of a tool commonly referred to as “Terminator,” leveraging Zemana drivers as part of the EDR-killer workflow, with activity persisting into late 2025. (SOPHOS)

EDRKillShifter / RansomHub affiliate ecosystem

Trend Micro and Sophos reporting describe how RansomHub-related activity incorporated EDRKillShifter to disable endpoint security as part of ransomware operations. (www.trendmicro.com)
ESET has also highlighted tooling linkages between ransomware groups through shared EDR-killer capabilities and affiliate ecosystems. (ESET)

2026 EnCase driver EDR killer (revoked driver still loadable)

The February 2026 intrusion reporting (Huntress and follow-on coverage) is a useful modern exemplar of how attackers operationalize driver abuse specifically to neutralize dozens of endpoint tools. (Huntress)

MITRE ATT&CK mapping (defender-oriented)

Primary:

Impair Defenses (T1562) — overarching category for defense degradation. (attack.mitre.org)
Disable or Modify Tools (T1562.001) — directly covers killing security processes/services and interfering with security tooling. (attack.mitre.org)

Common enablers you should expect to see nearby:

Exploitation for Privilege Escalation (T1068) — often the “why” behind BYOVD: using a vulnerable driver to reach kernel-level control. (attack.mitre.org)
Driver Load / Driver Misuse telemetry — monitor for suspicious driver loading and misuse patterns (ATT&CK data component framing). (attack.mitre.org)

Detection & hunting: what to watch for

High-signal telemetry (Windows)

Prioritize detections that fire on behavioral prerequisites, not vendor-specific artifacts:

New/rare kernel driver loads
- driver file written to user-writable locations (e.g., ProgramData, Temp, profile dirs)
- unusual driver service creation, especially outside standard deployment tooling
- loading drivers known to be abused (blocklist hits, threat intel lists)
Security-tool interference sequences
- repeated service stop attempts against security products
- bursts of process terminations aligned to common EDR process names
- “agent health” dropping across multiple endpoints around the same time
Trust-control anomalies
- drivers with revoked/expired signing situations still being accepted
- sudden changes to driver blocklist settings or memory integrity state
The “ransomware runway”
- EDR-killer execution shortly after credential access (admin escalation)
- lateral movement + EDR interference within the same short window

Practical hunting leads

Build a “Driver Load Baseline” per endpoint group (workstations vs. servers). Your best detections will often be “rare on this host” rather than “known bad everywhere.”
Correlate “driver load → security service disruption → bulk file operations / encryption precursors” as a multi-signal chain.

Mitigation: what actually reduces risk

1) Harden driver loading (reduce BYOVD viability)

Enable and enforce Microsoft’s vulnerable driver blocklist and related protections where feasible. Microsoft documents recommended driver block rules and notes enforcement ties to features like Memory Integrity (HVCI), Smart App Control, and S mode in supported environments. (Microsoft Learn)
Also be aware that some reporting critiques blocklist coverage/cadence and urges layered controls rather than assuming blocklists are sufficient alone. (Dark Reading)

Layering options (choose what matches your estate):

Memory Integrity / HVCI (where compatible)
Application control policies (e.g., WDAC/App Control for Business)
Restrict local admin; restrict ability to install/load drivers to tightly controlled workflows

2) Treat local admin as “near-kernel” access

Most EDR killer paths become dramatically easier once the attacker has admin. Your biggest wins often come from:

removing standing admin rights from users
using privileged access workstations / tiering
protecting credential material (LSASS hardening, credential guard where possible)
tightening RMM/remote tooling access and auditing

3) Turn on EDR tamper protection and monitor its health centrally

This sounds obvious, but it’s still one of the most common gaps highlighted in advisories and incident response. (Cyber Security Agency of Singapore)
Treat “tamper protection disabled” as a policy violation with ticketing, enforcement, and leadership visibility.

4) Add “absence of telemetry” monitoring

If attackers are trying to blind you, you must alert when:

expected security logs stop arriving
agent heartbeats drop
endpoint telemetry coverage dips below thresholds

5) Assume the endpoint can fall — and protect the blast radius

EDR killers are designed to win on the endpoint. Mitigate impact by ensuring:

immutable/offline backups
strong network segmentation
least privilege on file shares
rapid isolation capability (SOAR, NAC, EDR network containment, firewall blocks)

Incident response playbook (when you suspect EDR-killer activity)

Isolate fast (network containment) — assume ransomware staging is imminent.
Preserve evidence from adjacent telemetry sources (network, identity, virtualization, backups).
Hunt laterally for the same driver/service/process disruption pattern across the fleet.
Rebuild trust: consider endpoints affected by kernel-driver tampering as untrusted; validate from known-good media.
Close the entry point (VPN creds, edge appliance, exposed services) — several recent cases begin with perimeter access and quickly move into defense impairment. (Huntress)

Sources & further references

Sophos: AuKill EDR killer abusing Process Explorer driver (SOPHOS)
Sophos: Terminator tool and variants (Zemana driver abuse) (SOPHOS)
Trend Micro: RansomHub using EDRKillShifter (www.trendmicro.com)
ESET: RansomHub ecosystem + EDR killers (ESET)
Huntress: EnCase driver BYOVD EDR killer intrusion (Feb 2026) (Huntress)
Microsoft: recommended driver block rules / vulnerable driver blocklist (Microsoft Learn)
MITRE ATT&CK: Disable or Modify Tools (T1562.001) (attack.mitre.org)
MITRE ATT&CK: Driver Load / Driver Misuse data component (attack.mitre.org)
Cyber Security Agency of Singapore advisory on EDR killer tool (Cyber Security Agency of Singapore)

EDR Killers in 2026: The most common ways attackers neutralize endpoint security — and how to stop them

ByThreat Analyst