BYOVD Attacks and EDR Evasion: Why Your Endpoint Security May Not Be Enough

Your EDR is active. Your antivirus is updated. Your security team gets alerts. So why are ransomware groups still getting through and why are they doing it faster and more quietly than ever?

The answer may lie in a technique called Bring Your Own Vulnerable Driver (BYOVD), and it is fundamentally undermining one of the most trusted layers of enterprise defense.

What Is BYOVD and Why Does It Work?

BYOVD is an attack technique in which a malicious actor introduces a legitimate, digitally signed, but vulnerable software driver onto a target system. Because the driver is signed and trusted by the operating system, it bypasses scrutiny. The attacker then exploits flaws in that driver to reach the Windows kernel, the highest privilege level in the OS. From there, they can do something far more dangerous than exfiltrate data or drop a payload: they can disable your EDR.

This is what makes BYOVD so effective and so frustrating to defend against. Modern endpoint security tools, like EDR and XDR largely rely on kernel-level visibility to operate. If an attacker can reach the kernel first and terminate those processes, your security tooling goes dark before the ransomware ever executes.

The technique isn’t new. The Lazarus Group used it as early as 2021; the Cuba and RobbinHood ransomware gangs adopted it shortly after. But what is interesting is how BYOVD attacks have evolved.

The Reynolds Ransomware: A Dangerous Evolution

The most significant recent development in BYOVD is the emergence of Reynolds, a new ransomware family disclosed in February 2026. You may have seen Nathan Anderson’s blog last month alerting IT teams to Reynolds, which doesn’t just use BYOVD; it embeds it directly inside the ransomware payload. Let’s take a deeper dive here.

In traditional BYOVD-assisted ransomware attacks, the evasion component is a separate tool deployed as a precursor step. E.g. kill the EDR first and then drop the ransomware. Reynolds collapses these into a single operation. Upon execution, the malware drops a vulnerable NsecSoft NSecKrnl driver (CVE-2025-68947), uses it to terminate security software processes, and then proceeds to encrypt the victim’s files, all in one bundled payload.

This is a huge leap forward for several reasons:

It’s quieter. No separate driver file dropping to disk means fewer detection opportunities before encryption begins.

It’s faster and more streamlined. By combining evasion and encryption, defenders have no window to interrupt the attack chain. Barracuda’s 2026 threat data showed that the fastest observed ransomware cases in 2025 took just three hours from initial breach to encryption. Reynolds compresses that window further.

It’s more easily packaged. Bundling defense evasion into the payload makes ransomware attacks easier to carry out, lowering the barrier for affiliates and making Reynolds a more attractive offering in the ransomware-as-a-service (RaaS) ecosystem.

This isn’t an isolated case. Just prior to Reynolds’ disclosure, in a separate incident, attackers weaponized a driver for the EnCase digital forensics suite, turning it into a defense-evasion mechanism.

BYOVD is Quickly Becoming the Dominant Defense Evasion Strategy

The use of impairment tools has increased markedly over the past two years directly in response to EDR vendors improving their ability to detect pre-ransomware threats. It’s the classic arms race. The better defenders got at spotting the precursors, the more attackers invested in techniques to blind those detectors before deploying their payload.

The EDR killer toolbelt has matured accordingly. Readily available tools include:

• TrueSightKiller: Leverages the vulnerable “truesight” driver
• AuKill (BurntCigar/Poortry): Used by LockBit and shares code with the open source Backstab tool
• GhostDriver: Publicly available, widely used across ransomware groups
• Warp AVKiller: Uses a vulnerable Avira anti-rootkit driver
• Gmer: A rootkit scanner repurposed to kill security processes
• EDRKillShifter: Introduced by RansomHub in 2024; purpose-built to load and exploit vulnerable drivers

These tools are actively traded and sold on criminal forums. In 2023, a tool called Terminator, which claimed to bypass 23 different AV/EDR/XDR products, was publicly advertised on Russian cybercrime forums for anyone willing to pay.

Why Microsoft’s Defenses Have Gaps

The most direct structural defense against BYOVD in the Windows ecosystem is Microsoft’s Vulnerable Driver Blocklist, which prevents known-bad drivers from loading on Windows systems. But even this has limited effectiveness.

Microsoft’s blocklist is updated only once or twice per year, so a newly weaponized driver could be actively used in attacks for months before it’s effectively blocked in the wild. Microsoft must also weigh whether blocking a given driver could break legitimate systems. Blocking a signed driver has collateral consequences, particularly in healthcare, manufacturing, and other sectors running legacy infrastructure.

Windows also loads drivers during the boot process before network connections are established, preventing certificate revocation lists (CRLs) from being checked. This means that even revoked driver signatures may still successfully load in certain Windows configurations.

The net result is that the burden has largely fallen on EDR vendors to detect and mitigate BYOVD activity, despite it actually being the target of these attacks. These are not the makings of long-term success.

What Organizations Are Getting Wrong

“We have EDR, so we’re covered.” 

EDR is a critical control, but it is not impervious. If an attacker can reach the kernel before your EDR can flag the behavior, your EDR becomes a casual spectator. 

“Our drivers are patched.” 

BYOVD attackers don’t need to exploit your drivers. They bring their own. A fully patched environment is still vulnerable if an attacker can load a legitimately signed driver with known-exploitable flaws from elsewhere.

“We’d see the lateral movement before they got to deployment.” 

Sure, that was true when these attacks required separate multi-step operations. Reynolds changed that. Embedded payloads are specifically engineered to eliminate those observable steps.

“We’re not a big enough target.” 

Yes, you are. 

Practical Defenses That Actually Work

No single control or countermeasure eliminates BYOVD risk, but a layered approach can significantly raise the cost of a successful attack.

• Enable Hypervisor-Protected Code Integrity (HVCI). This Windows feature prevents unsigned or vulnerable drivers from loading at the kernel level. It is the most direct technical control available and should be enabled on modern hardware.
• Despite its potential flaws, Microsoft’s Vulnerable Driver Blocklist has a foundational role. The default blocklist is a starting point. Organizations should supplement it with community resources like the Living Off the Land Drivers (LOLDrivers) project, which tracks a broader set of known-vulnerable drivers.
• Monitor driver load events where practical. Windows Event ID 7045 (new service installed) and kernel driver load activity should be actively monitored in your SIEM. Unexpected driver loads should trigger immediate investigation.
• Test your EDR; don’t just trust it. Assessment exercises that specifically target kernel-level evasion techniques will reveal whether your EDR stack and response processes can actually catch BYOVD activity before it’s too late.
• Don’t rely on detection alone. Behavioral controls, network segmentation, privilege management, and robust incident response planning are critical backstops for when (not if) detection fails.
• This isn’t just another malware story. It’s a signal about where threat trends are heading. Attackers are actively investing in techniques that neutralize security controls and tooling that organizations have heavily invested in to protect their assets. This attack vector is widespread, commoditized, and rapidly maturing.

The organizations best positioned to survive this evolution are not the ones with the most security products. They’re the ones who regularly test those products against real attack techniques, understand what their stack actually catches, and build response capabilities that don’t depend entirely on tools that can be silenced before the alarm sounds.

I hope you’ll take a look at other blogs in our Security Recommendations series, and, if you’d like to be alerted to new blogs like this in our monthly cybersecurity newsletter, you can sign up here.