Ransomware groups have quietly rewritten their playbook. The old assumption that endpoint detection and response (EDR) tools would at least see an attack in progress, even if they couldn’t stop it in time no longer holds. In 2026, the first move in a growing share of ransomware intrusions isn’t encryption. It’s blinding the security stack itself.
This is the world of EDR killer malware: purpose-built tools designed to shut down antivirus and EDR agents from the inside, before the “real” attack ever fires. The technique enabling most of them has a name that’s rapidly becoming boardroom vocabulary for IT managers and MSSPs alike: BYOVD, or Bring Your Own Vulnerable Driver.
If you’re evaluating your current managed security provider’s ability to detect this class of attack, understanding how BYOVD works, and where it fits in the modern ransomware kill chain, is no longer optional.
What Is an EDR Killer?
An EDR killer is a small, focused piece of tooling with one job: terminate or blind security software running on an endpoint. It isn’t the ransomware payload itself; it’s the preparation stage. Research shared with The Hacker News found that dozens of these tools have converged on the same underlying method to accomplish that goal at the kernel level, where user-mode security agents have no visibility.
That research, conducted by ESET, catalogued 54 distinct EDR-killer tools abusing 35 different signed, legitimate Windows drivers to disable endpoint protection. The analysis found that 54 EDR killers leverage bring your own vulnerable driver techniques by abusing a total of 35 vulnerable drivers. The scale matters: ransomware-as-a-service affiliates need their encryptor builds to stay undetected, and ESET researcher Jakub Souček noted that constantly re-testing new builds against every EDR vendor is time-consuming, so instead, attackers simply switch the security software off before it ever gets a chance to look.
Breaking Down the BYOVD Technique
Here’s the core problem BYOVD exploits: Windows won’t load an unsigned kernel driver, and modern EDR agents are deliberately hardened against being killed from user space. So, attackers stopped trying to beat that protection head-on. Instead, they bring their own.
A BYOVD attack works roughly like this:
- Acquire a legitimately signed driver. This can be a driver from a hardware vendor, an old antivirus product, an anti-cheat system, or even forensic software, anything carrying a valid digital signature that Windows and security tools are predisposed to trust.
- Load the driver onto the target system. Because it’s signed, the OS accepts it without complaint, even though the vendor never intended it to be used this way.
- Exploit a known flaw in the driver. The vulnerability grants the attacker kernel-level code execution; the same privilege level the EDR agent itself relies on to protect the system.
- Terminate security processes from kernel mode. With kernel access, the attacker can kill EDR and antivirus processes outright, since kernel-mode code sits above what user-mode protections can stop.
As Picus Security frames it, a BYOVD attack is a privilege-escalation and defense-evasion technique where an adversary loads a legitimately signed but vulnerable kernel driver, then exploits its known flaws to run code at the kernel level and disable security tooling. This is precisely why the technique undermines a core assumption behind most disabled antivirus ransomware defenses: those defenses assume they’re being attacked from a lower privilege level, not from underneath the operating system.
The scale of the exposed attack surface compounds the problem. One analysis noted that 35 distinct abused drivers mean 35 separate vendor patching timelines, 35 separate Microsoft blocklist entries, and 35 separate detection signatures defenders must maintain, while attackers only need one working option to succeed.
Real-World Cases: BYOVD in Active Ransomware Campaigns
This isn’t theoretical. BYOVD-based EDR killers are now a standard pre-encryption step across major ransomware operations.
Qilin’s mass EDR disabling. In early April 2026, Cisco Talos published research showing the Qilin ransomware group had developed a BYOVD-based technique capable of disabling more than 300 different EDR products, not by evading them, but simply switching them off.
EDRKillShifter goes multi-gang. A single EDR-killer binary, originally built for the RansomHub operation, has since been adopted across multiple ransomware brands. Reporting has documented one custom EDR-killer binary in simultaneous use by at least eight separate ransomware gangs, including BlackSuit, Medusa, Qilin, and DragonForce, a sign that EDR-killing tooling is now shared, commoditized infrastructure rather than bespoke, gang-specific code.
The driver ships inside the ransomware itself. In February 2026, the Reynolds ransomware operation went a step further by bundling a vulnerable kernel driver directly inside the ransomware payload, eliminating the need for a separate EDR-killer deployment stage and shrinking the time from execution to full EDR blindness to seconds.
Compromised remote access, then a kill switch. In a case Huntress investigated in February 2026, attackers who gained initial access through compromised SonicWall SSLVPN credentials deployed an EDR killer abusing a legitimate Guidance Software (EnCase) forensic driver with a revoked certificate to terminate security processes from kernel mode, a textbook BYOVD chain that Huntress caught and disrupted before ransomware deployment. It’s a useful reminder that detection at the driver-load stage can still stop the attack before encryption begins.
Signed drivers designed to be trusted. Even gaming and anti-cheat drivers have been repurposed for this. Ransomware actors have been documented abusing an anti-cheat driver associated with a popular video game to disable antivirus software on infected machines, precisely because the driver carries a legitimate, trusted signature.
Why BYOVD Should Be Front-of-Mind When Vetting an MSSP
For IT managers evaluating a managed security services provider, BYOVD resistance is quickly becoming a practical litmus test, not a theoretical one. A few questions worth asking directly:
- Does the provider monitor kernel driver loads, not just process behavior? Sysmon Event ID 6 (driver load) logging, correlated against known-vulnerable-driver databases, is a baseline detection capability many legacy MSSP stacks still lack.
- Is Hypervisor-Protected Code Integrity (HVCI) enforced across endpoints? HVCI operates below the OS, at the hypervisor level, which means it can block unauthorized kernel memory writes even from an already-loaded vulnerable driver.
- Does the provider maintain independent, out-of-band telemetry? If EDR is the only signal source, an EDR killer removes your only visibility. A secondary detection layer that survives EDR termination is essential.
- How quickly does the provider update against emerging vulnerable-driver lists? Community-maintained projects like LOLDrivers.io track hundreds of known-abused drivers, and Microsoft’s own Vulnerable Driver Blocklist is updated periodically, an MSSP’s patch and policy cadence against these lists is a meaningful capability signal.
- Is there an alerting workflow specifically for unexpected AV/EDR termination? A host that suddenly loses security telemetry should trigger an immediate, high-priority investigation, not a quiet gap in the dashboard.
Mitigating BYOVD: What Actually Works
Security researchers converge on a fairly consistent hardening checklist:
- Enable HVCI (Memory Integrity) on all supported endpoints. This is currently considered the strongest available defense, since it blocks kernel memory tampering even when a vulnerable driver has already loaded.
- Deploy Windows Defender Application Control (WDAC) policies alongside the Microsoft Vulnerable Driver Blocklist, which is enabled by default on many Windows 11 22H2+ systems but should be explicitly verified, not assumed.
- Cross-reference loaded drivers against LOLDrivers.io, the community-maintained catalog of drivers known to be abused in the wild, which as of mid-2026 tracks well over 2,000 samples across hundreds of unique vulnerable drivers.
- Treat driver-load events as first-class telemetry, not a background log source, behavioral correlation of the download-to-service-start-to-process-termination chain can catch BYOVD activity before ransomware ever detonates.
- Assume signed does not mean safe. A valid signature only proves provenance, not current trustworthiness. Vendors periodically revoke certificates on drivers later found to be exploitable, and Windows doesn’t always reject a revoked certificate outright, as the EnCase driver case demonstrated.
Microsoft has also begun tightening trust for older cross-signed kernel drivers in newer Windows releases, which researchers expect to meaningfully shrink the BYOVD attack surface over time, though rollout and compatibility testing mean the change won’t close the gap immediately.
The Bottom Line
Ransomware operators have effectively added a new phase to the standard attack lifecycle: blind the defenses, then strike. BYOVD is the technique that makes that phase reliable, cheap, and increasingly commoditized across ransomware-as-a-service ecosystems. For organizations and the MSSPs that protect them, the practical takeaway is straightforward: EDR alone is no longer a sufficient control. Kernel-level visibility, HVCI enforcement, independent telemetry, and an incident response playbook that treats “my EDR just went quiet” as a five-alarm event are now baseline requirements, not advanced, optional add-ons.
Is Your MSSP Actually Reducing Risk or Just Watching Alerts?
Modern attacks move from initial access to ransomware deployment in hours, sometimes minutes. Most MSSP contracts sound the same on paper. This worksheet shows you how to tell the difference before an incident does it for you.
Sources:
- The Hacker News / ESET Research — 54 EDR Killers Use BYOVD to Exploit 35 Signed Vulnerable Drivers and Disable Security
- Huntress — They Got In Through SonicWall. Then They Tried to Kill
- Picus Security — What Is a BYOVD Attack? Bring Your Own Vulnerable Driver, Explained
- Cisco Talos research on Qilin ransomware, as reported by Burgi Technologies — BYOVD Ransomware: How Hackers Bypass EDR
- LOLDrivers.io — Living Off The Land Drivers Project
- NinjaOne — How to Enable or Disable Microsoft Vulnerable Driver Blocklist
- GBHackers — Ransomware Gangs Use BYOVD and EDR Killers to Disable Security Tools
