Threat Intel
EDR Killers: How Attackers Exploit Drivers to Disable Endpoint Detection
ESET researchers analyzed nearly 90 EDR‑killer tools used in ransomware campaigns, revealing that attackers routinely deploy vulnerable drivers or driverless tactics to suspend or block EDR software before launching encryption. The study shows driver reuse across unrelated toolsets and highlights the pitfalls of attributing attacks solely by driver signatures. Defenders should monitor driver installation, block unauthorized driver loads, and enforce EDR integrity checks.
What Happened
In recent ransomware operations, adversaries use a class of tools—termed EDR killers—to neutralize endpoint detection before encrypting data. ESET’s telemetry shows almost 90 distinct EDR‑killer variants in the wild, many of which rely on the Bring Your Own Vulnerable Driver (BYOVD) technique, while others use legitimate anti‑rootkit binaries or driverless methods to block EDR communication.
Impact on Defenders
These tools create a predictable, short window during which the EDR is disabled, allowing the encryptor to run with minimal resistance. Because the same driver can appear in unrelated toolchains and a single tool can switch drivers, relying on driver signatures for attribution or detection is unreliable. Attackers can also suspend EDR processes without loading a driver, making traditional driver‑based defenses ineffective.
What to Do
- Implement strict driver‑whitelisting and enforce signed‑driver policies on all endpoints.
- Deploy monitoring that flags unexpected driver loads or driverless process suspensions.
- Use EDR integrity checks that detect tampering with the EDR process or its communication channels.
- Maintain up‑to‑date kernel‑mode patches to close known driver vulnerabilities.
- Correlate driver activity with network anomalies to detect early EDR disruption attempts.
Key Takeaways
Adversaries prefer a short, reliable disruption phase over continuous payload modification. Driver reuse across toolsets can mislead attribution, so defenders should focus on behavior rather than driver identity.
Related vulnerabilities
BTR Reforged: Turning a Signed Windows Defender Driver into a Kernel‑Level Attack Engine
Checkpoint Research has shown that Microsoft’s own BTR.sys – the Boot‑Time Removal driver used by Windows Defender – can be hijacked to perform arbitrary file and registry operations from Ring 0. By reverse‑engineering the driver’s encrypted transaction format and building a tool called BTR_CLI, researchers demonstrated a kernel‑mode operation primitive that bypasses EDR/AV without exploiting a vulnerability. The study exposes how trusted signed components can become powerful attack tools, urging defenders to scrutinize remediation drivers and implement stricter driver‑loading controls.
Read briefing
Threat Actors Target Security Tools: Disabling AV/EDR via Vulnerable Drivers, Tampering, and Malicious Firewall Rules
Recent intelligence shows attackers are actively disabling endpoint protection by exploiting vulnerable drivers, tampering with system components, and injecting malicious firewall rules. Defenders should audit driver integrity, enforce signed‑driver policies, monitor firewall changes, and apply the latest patches to mitigate these tactics.
Read briefing
Hacker Summer Camp 2026: Key Takeaways for First‑Time Defenders
The 2026 Hacker Summer Camp, featuring DEF CON, Black Hat, and BSides, highlighted evolving attacker tactics. Defenders should audit endpoint visibility, email security, and identity hardening, leveraging Huntress Platform One and Athena Engine for proactive detection. Key actions include reviewing Managed EDR and ITDR configurations and updating threat‑intel feeds.
Read briefing
Signed PUP Exploits Update Mechanism to Deploy AV Killers with SYSTEM Privileges
Huntress identified a malware campaign that leverages a signed potentially unwanted program (PUP) to install antivirus‑killers with SYSTEM rights. The operation abuses the software’s update channel, allowing attackers to gain full control over endpoints. Defenders should audit signed binaries, monitor privileged process creation, and enforce least‑privilege update mechanisms.
Read briefing