BYOVD and EDR Killers: How Ransomware Blinds Your Endpoint Security
Bring Your Own Vulnerable Driver (BYOVD) is the technique ransomware groups use to blind your EDR before encryption begins. The attack loads a legitimately signed but vulnerable Windows kernel driver, exploits it to gain Ring 0 (kernel-level) execution, and then directly terminates EDR processes, disables security callbacks, or corrupts the security product's communication channels. Because the attacking code runs at the kernel level, EDR user-space protections cannot stop it.
The reason signed drivers work is that Windows kernel code signing requirements ensure the operating system only loads drivers with a valid Microsoft signature. Attackers solve this by finding drivers that ARE legitimately signed but contain exploitable vulnerabilities: buffer overflows, arbitrary read/write primitives, or IOCTL handlers that can be abused to execute arbitrary kernel code. The driver is legitimate; its use is malicious.
How BYOVD Works: The Kernel-Level Attack Path
Understanding why BYOVD is effective requires understanding the Windows security model at the kernel level.
User space vs. kernel space
Windows separates execution into two privilege rings. User space (Ring 3) is where applications and security agents run. Kernel space (Ring 0) is where the operating system, hardware drivers, and kernel security products run. EDR agents operate primarily in user space, with kernel callbacks (ETW, PatchGuard, minifilters) providing visibility into kernel events. A security agent running at Ring 3 cannot directly protect itself from code running at Ring 0.
The BYOVD attack sequence
-
Driver delivery: The ransomware payload includes a vulnerable signed driver file (typically a
.sysfile). Common examples include older versions of Gigabyte, ASUS, or Intel utility drivers that contain exploitable IOCTL handlers. -
Driver installation: The malware uses
sc.exe,NtLoadDriver, or Windows Service Control Manager to install and start the vulnerable driver. Because the driver is legitimately signed, Windows Kernel Mode Code Signing (KMCS) and Secure Boot allow it to load. -
Vulnerability exploitation: The malware sends crafted IOCTLs (I/O Control Codes) to the vulnerable driver through a device object. Common exploitation classes include arbitrary kernel memory read/write primitives and function pointer overwrites.
-
EDR termination: With kernel-level arbitrary write capability, the attacker can: directly kill EDR processes by manipulating process structures, remove kernel callbacks that EDR agents registered for process creation/image load/registry monitoring notifications, or disable protected process light (PPL) protections that prevent user-space processes from being terminated.
-
Ransomware execution: With security products blinded or terminated, the ransomware payload runs without behavioral detection or blocking.
Most Abused Vulnerable Drivers in 2026
The LOLDrivers project (loldrivers.io) maintains an open database of known vulnerable signed drivers. The drivers most abused in 2025-2026 ransomware campaigns fall into recurring categories:
Anticheat and game utility drivers
mhyprot2.sys(miHoYo Genshin Impact anticheat): arbitrary kernel R/W, widely abused since 2022gmer.sys(GMER rootkit scanner): process termination capability abused against itselfProcExp152.sys(Process Explorer driver): abused by the KillAV tool to terminate protected processes
Hardware vendor utility drivers
RTCORE64.sys(MSI Afterburner): arbitrary kernel R/W, abused in multiple ransomware variantsIQVW64.sys(Intel Network Adapter Diagnostics): kernel memory mapping, frequently abusedkprocesshacker.sys(older Process Hacker versions): direct process handle abuse
AV/security product drivers
- Older versions of legitimate security drivers from vendors including Avast, Trend Micro, and Malwarebytes have appeared in EDR killer toolkits, exploiting the irony that security drivers require the highest privilege and are most impactful when abused
The common thread: these drivers were legitimately signed at the time of issuance, contain exploitable vulnerabilities that vendors have since patched, but older signed copies remain valid because Microsoft's kernel signing requirements do not retroactively revoke certificates for security vulnerabilities.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Primary Defenses: HVCI, WDAC, and the Vulnerable Driver Blocklist
Three Windows platform security features together address BYOVD at the root. Deploy all three for layered defense.
HVCI (Hypervisor-Protected Code Integrity / Memory Integrity)
HVCI uses Hyper-V virtualization to enforce kernel code integrity in a hardware-isolated environment. It ensures that only properly signed and validated code can execute in kernel mode. Critically, HVCI prevents write access to kernel executable memory from user space, breaking most BYOVD exploit chains that rely on writing shellcode to kernel memory. Enable via: Group Policy > Computer Configuration > Administrative Templates > System > Device Guard > Turn on Virtualization Based Security. Requires hardware support (Intel VT-x, AMD-V, IOMMU). Check hardware compatibility before broad rollout. Modern devices with Windows 11 have HVCI-capable hardware broadly.
Microsoft Vulnerable Driver Blocklist (WDAC)
Windows Defender Application Control (WDAC) includes a Microsoft-maintained list of known vulnerable drivers that should be blocked from loading. Updated via Windows Update and in the WDAC policy. Enable the vulnerable driver blocklist via: WDAC policy deployment with the 'Microsoft Recommended Driver Block Rules' (available as a policy XML from Microsoft documentation). For Windows 11 2022 Update and later, this blocklist is enforced automatically with HVCI enabled. For older systems, deploy the WDAC policy explicitly. Review the blocklist against your hardware vendors' drivers before enforcing to avoid blocking legitimate hardware management utilities.
WDAC Application Control Policy for Drivers
Beyond the vulnerable driver blocklist, deploy a broader WDAC policy that restricts which kernel drivers can load to those required for your environment. Use audit mode first (WDAC Audit Mode) to identify all drivers currently loading in your fleet, then build a policy that allows only known-good drivers. This is the most powerful defense but requires careful baselining to avoid breaking hardware functionality. The WDAC Wizard (Microsoft tool) simplifies policy creation. Pair with the LOLDrivers database to ensure known-bad drivers are explicitly denied.
Protected Process Light (PPL) for Security Products
Windows PPL allows security products to run as protected processes, preventing termination by lower-privilege processes. However, PPL operates at user space privilege and is bypassed by kernel-level BYOVD attacks. PPL provides meaningful protection against less sophisticated threats (malware without kernel access) but is not a substitute for HVCI. Verify your EDR vendor supports running as a PPL process. Microsoft Defender for Endpoint, CrowdStrike Falcon, and SentinelOne all support PPL operation.
Kernel ETW Provider Hardening
Some BYOVD attacks target ETW (Event Tracing for Windows) providers that EDR agents rely on for telemetry. Attackers patch the provider in kernel memory to stop telemetry from reaching the agent. Mitigations: use EDR products that use multiple redundant telemetry sources (ETW + minifilter callbacks + kernel callbacks) so that disabling one source does not completely blind the agent. Ask your EDR vendor specifically whether their telemetry is resilient to ETW tampering.
Detection: Identifying BYOVD Attempts Before EDR Is Killed
The challenge with BYOVD detection is that a successful attack terminates the detection tool. Detect early-stage indicators before the driver is exploited.
Monitor driver loading events
Windows Event ID 7045 (System log, Service Control Manager) fires when a new service (including a driver-as-service) is installed. Alert on any new kernel driver installation:
Event
| where EventID == 7045
| where RenderedDescription contains "kernel" or RenderedDescription contains ".sys"
| where TimeGenerated > ago(24h)
Cross-reference against LOLDrivers database
Build a hash blocklist from loldrivers.io and feed it into your EDR/SIEM as a custom IOC feed. Alert on any process attempting to load a file matching a known vulnerable driver hash, even before installation succeeds.
Alert on sc.exe or NtLoadDriver loading unsigned or unusual drivers
Legitimate enterprise software rarely installs new kernel drivers in production. Any sc create command referencing a .sys file outside of known software installation paths (C:\Windows\System32\drivers\, vendor-specific paths) should trigger an alert.
Monitor IOCTL call patterns to driver device objects
Advanced telemetry: some EDR products (CrowdStrike, Microsoft Defender for Endpoint) provide IOCTL-level visibility. Alert on unusual IOCTL codes sent to known-vulnerable driver device objects. The LOLDrivers project documents the specific IOCTL codes used in exploitation for each driver.
Vendor Hardening: What to Ask Your EDR Provider
Not all EDR products are equally resistant to BYOVD termination. Use these questions in your vendor evaluation or QBR with your current vendor:
1. Does your agent support Tamper Protection at the kernel level? Tamper Protection prevents configuration changes and process termination from user space. Kernel-level BYOVD bypasses user-space tamper protection. Ask specifically whether tamper protection is resilient to kernel-level attacks or only user-space attacks.
2. Do you maintain your own vulnerable driver blocklist? CrowdStrike, SentinelOne, Microsoft Defender for Endpoint, and Palo Alto Cortex XDR all maintain driver blocklists that can prevent known bad drivers from loading before WDAC policies are deployed. Verify your vendor's blocklist is updated and enabled.
3. Do you use kernel callbacks that survive driver unload? Some EDR implementations use kernel callbacks that can be de-registered by a kernel-level attacker. Ask whether your vendor uses alternative persistence mechanisms for critical callbacks.
4. What is your tested resilience against popular EDR killer toolkits? Ask your vendor whether they have tested against Terminator, Spyboy, and other public EDR killer tools. Request their internal test results or third-party validation data.
5. Do you integrate with Microsoft HVCI and WDAC? The most resilient EDR deployments operate on HVCI-enabled systems with WDAC policies in place. Ask your vendor whether they support and recommend HVCI, and whether their driver signing meets HVCI compatibility requirements.
The bottom line
BYOVD is the technique ransomware groups use specifically because it defeats the security tool your organization bought to detect ransomware. The defense is not a single control but a stack: HVCI to prevent arbitrary kernel code execution, the Microsoft vulnerable driver blocklist to block known-bad drivers from loading, WDAC application control policies to restrict all driver loading to an approved set, and early-stage detection on driver installation events before exploitation occurs. Ask your EDR vendor directly whether their product has been tested against BYOVD toolkits and what their kernel-level tamper protection architecture looks like. The organizations hardest hit by ransomware in 2026 had EDR deployed but did not have HVCI enabled or the vulnerable driver blocklist enforced: these are free platform controls that meaningfully raise the cost of a successful attack.
Frequently asked questions
What is BYOVD and why is it different from other malware techniques?
BYOVD (Bring Your Own Vulnerable Driver) exploits the fact that Windows requires kernel drivers to be legitimately signed by Microsoft. Attackers find drivers that ARE legitimately signed but contain security vulnerabilities, then load those drivers to gain kernel-level (Ring 0) execution. This is different from most malware, which runs in user space (Ring 3) and can be detected and blocked by EDR agents. Code running at Ring 0 can directly manipulate EDR processes, remove kernel callbacks that EDR relies on for visibility, and terminate security products in ways that user-space malware cannot.
Which ransomware groups are using BYOVD most actively in 2026?
Qilin (also tracked as AGENDA ransomware) and Warlock ransomware are the most active BYOVD users as of Q1-Q2 2026, with payloads that terminated 300+ security products in tested environments per April 2026 analysis. BlackCat/ALPHV (before its disruption), Akira (REDBIKE), and LockBit 3.0 variants have all used BYOVD. The technique has become mainstream rather than advanced: phishing-as-a-service platforms now include BYOVD capability as an add-on module.
What is HVCI and does enabling it break existing software?
HVCI (Hypervisor-Protected Code Integrity, also called Memory Integrity) uses hardware virtualization to enforce kernel code integrity. It prevents unsigned or tampered code from executing in the kernel. Enabling HVCI can break older hardware drivers that rely on deprecated unsigned code or self-modifying drivers. Before enabling, run the Windows Security app Hardware Security Center check on representative devices, and use HVCI audit mode to identify incompatible drivers. Most modern enterprise software (Windows 11 era drivers) is HVCI-compatible. Older hardware management utilities and some specialized industrial software may require updates.
Does the Microsoft Vulnerable Driver Blocklist update automatically?
Yes, for systems running Windows 11 2022 Update or later with HVCI enabled, the vulnerable driver blocklist is updated automatically via Windows Update. For older systems or environments where you need to manage updates manually, Microsoft publishes the block rules as a WDAC policy XML that you can deploy via Intune, Group Policy, or SCCM. Check the Microsoft documentation page for the current blocklist and update cadence. The LOLDrivers community project (loldrivers.io) often identifies vulnerable drivers before they appear in the official Microsoft blocklist.
Can BYOVD be detected before the EDR is killed?
Yes, if you are monitoring the right early-stage indicators. Windows Event ID 7045 fires when a new service (including a kernel driver) is installed. Alert on any new driver installations, especially .sys files dropped to unusual paths or not matching known software installation patterns. Cross-reference driver file hashes against the LOLDrivers database in your SIEM or EDR's custom IOC feed. The attack fails to terminate your EDR if you detect and block the driver installation step before exploitation. Many BYOVD attacks also require a reboot to load the driver, giving additional time between deployment and activation.
What is the LOLDrivers project and how do we use it?
LOLDrivers (loldrivers.io) is a community-maintained database of known vulnerable signed Windows drivers, similar to LOLBAS for binaries. Each entry includes the driver name, hash values, known vulnerable versions, exploitation method, and CVSS score. Use it by: (1) Downloading the database as JSON or CSV and loading hashes into your EDR's custom IOC blocklist for automated detection. (2) Cross-referencing against drivers currently installed in your environment (via Sysinternals Sigcheck or PowerShell Get-WmiObject Win32_SystemDriver). (3) Using it to inform your WDAC deny list for drivers you want to explicitly block. Integrate the feed into your threat intelligence platform for continuous monitoring as new entries are added.
My EDR vendor says they have tamper protection. Does that stop BYOVD?
Tamper protection typically protects against user-space attacks: it prevents processes running at Ring 3 from terminating the security agent, modifying its configuration, or uninstalling it without authorization. BYOVD operates at Ring 0 (kernel level), which is above the privilege level where user-space tamper protection operates. A BYOVD attack can bypass tamper protection by directly manipulating kernel data structures rather than going through the Windows API that tamper protection monitors. Ask your vendor specifically whether their tamper protection includes kernel-level defenses and whether it has been tested against BYOVD toolkits. The answer will vary significantly by vendor.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.
The Mythos Brief is free.
AI that finds 27-year-old zero-days. What it means for your security program.