Published 25 March 2026

BYOVD (Bring-Your-Own Vulnerable Driver): The Latest EDR-Killer Strategy

Endpoint Detection and Response (EDR) products are the most significant obstacle in the attacker's path on a modern Windows endpoint. They hook user-mode and kernel-mode APIs, monitor process creation, inspect memory operations, and report to centralized consoles. Attackers know this. And in 2026, the most effective strategy for neutralizing EDR is not to evade it — it is to kill it.

BYOVD — Bring Your Own Vulnerable Driver — is a technique where the attacker loads a legitimately signed but vulnerable kernel driver onto the target system and exploits a known vulnerability in that driver to gain kernel-level access. From there, they can terminate EDR processes, unload EDR kernel callbacks, and operate with full freedom on the endpoint. The driver is signed by a legitimate vendor, so Windows accepts it without complaint.

What Changed Recently

BYOVD has been discussed in security research since at least 2018, but 2025–26 saw it go fully mainstream:

LOLDrivers project — The community-maintained LOLDrivers database catalogs hundreds of vulnerable signed drivers. This database made it trivial for attackers to find a driver suitable for their needs.
Ransomware adoption — Multiple ransomware families now include BYOVD as a standard pre-encryption step. AuKill, Poortry, and Terminator are well-documented tools that disable EDR using vulnerable drivers.
Commodity availability — BYOVD tools are sold on criminal forums with customer support. The barrier to entry is effectively zero for any attacker who can afford the asking price.
Microsoft driver blocklist adoption remains incomplete — While Microsoft publishes a recommended driver blocklist, enforcement through HVCI or WDAC requires configuration that many organizations have not completed.

Why Signed Drivers Are the Perfect Attack Vector

Windows kernel driver loading requires a valid Authenticode signature from a trusted certificate authority. This is a security feature — it prevents arbitrary code from running in kernel mode. But it creates a paradox: any legitimately signed driver, regardless of its bugs, is accepted. A driver signed by a legitimate vendor in 2018 that contains an arbitrary read/write vulnerability will load on a 2026 system unless it is explicitly blocklisted.

The attacker does not need to create or sign their own driver. They bring a known vulnerable driver, load it, exploit the vulnerability, and gain kernel access. The entire process uses legitimate Windows driver loading mechanisms.

How BYOVD Works at a Conceptual Level

Driver selection — The attacker selects a signed vulnerable driver from a database like LOLDrivers. Common choices include drivers from hardware vendors, gaming anti-cheat systems, and utilities with known kernel vulnerabilities.
Driver deployment — The signed driver file is dropped to disk and loaded using sc create and sc start, or through direct calls to NtLoadDriver.
Vulnerability exploitation — The attacker communicates with the loaded driver through its IOCTL interface, exploiting a vulnerability such as arbitrary physical/virtual memory read/write, MSR access, or direct process manipulation.
EDR neutralization — Using kernel-level access, the attacker:
- Terminates EDR processes by directly manipulating process structures
- Removes kernel callbacks that EDR uses to intercept system activity
- Patches or removes ETW (Event Tracing for Windows) providers
- Modifies the Protected Process Light (PPL) attribute on EDR processes to make them terminable
Payload execution — With EDR disabled, the attacker executes their payload (ransomware, exfiltration tools, lateral movement) without endpoint-level detection.

Common Vulnerable Driver Categories

| Driver Type | Example | Vulnerability | |---|---|---| | Hardware diagnostic tools | Intel, AMD utilities | Arbitrary physical memory read/write | | Gaming anti-cheat | Old anti-cheat driver versions | Arbitrary virtual memory read/write | | System utilities | Process Explorer older versions | Direct kernel object manipulation | | GPU/Display drivers | Various vendor tools | MSR read/write, memory mapping | | Virtualization utilities | VirtualBox older host drivers | Arbitrary kernel memory access |

Where Defenders Can Observe It

Pre-Attack Indicators

Driver file drop — The vulnerable driver must be written to disk before loading. File creation monitoring for known vulnerable driver hashes (available from LOLDrivers) provides early detection.
Service creation — Loading a driver typically creates a kernel service. Sysmon Event ID 6 (Driver Loaded) and Event ID 13 (Registry value set) for service creation keys are key telemetry.
IOCTL communication — After the driver loads, the attacker's user-mode tool sends IOCTLs to the driver. Device object creation and handle acquisition are observable through kernel-level monitoring.

Active Attack Indicators

EDR process termination — If your EDR agent suddenly stops sending telemetry, that is a critical indicator. Centralized monitoring that alerts on agent silence is essential.
Kernel callback removal — ETW providers going offline or kernel callbacks being unregistered. This is detectable from the EDR kernel component if it has self-protection.
Process protection changes — PPL attributes being modified on security processes.

Post-Attack Indicators

EDR gaps in timeline — A gap in endpoint telemetry followed by evidence of malicious activity (ransomware encryption, data exfiltration) strongly suggests EDR was disabled during the gap.
Vulnerable driver artifacts — The driver file on disk, service registry entries, and event log entries for driver loading.

Common Detection Blind Spots

No driver loading monitoring — Many organizations do not collect Sysmon Event ID 6 or equivalent driver load telemetry.
Hash-only detection — Checking driver hashes against a static blocklist misses newly discovered vulnerable drivers and renamed/repacked versions.
EDR self-protection limitations — Some EDR products do not adequately protect their own kernel components against driver-level attacks.
HVCI not enforced — Hypervisor-Protected Code Integrity with the Microsoft vulnerable driver blocklist is the most effective prevention, but many organizations have not enabled it.

Practical Hardening and Monitoring Guidance

For System Administrators

Enable HVCI and the Microsoft driver blocklist — This is the highest-impact preventive control. HVCI uses virtualization-based security to enforce code integrity at the hypervisor level, and the driver blocklist prevents known vulnerable drivers from loading.
Deploy WDAC with driver restrictions — Windows Defender Application Control can enforce allow-only driver policies, which prevent any unsigned or unapproved driver from loading.
Audit driver loading — Enable Sysmon with driver load logging and forward events to your SIEM. Alert on drivers that are not part of your baseline.
Monitor EDR health — Implement centralized monitoring that detects when endpoints stop reporting. An endpoint that goes silent is potentially compromised.

For Detection Engineering Teams

Ingest the LOLDrivers blocklist — Use the community-maintained database as a detection source. Alert on any file creation matching known vulnerable driver hashes.
Build behavioral detections — Beyond hash matching, detect the pattern: file drop → service creation → driver load → EDR process termination. This sequence is characteristic of BYOVD attacks regardless of which specific driver is used.
Monitor service creation for drivers — New kernel-mode service creation outside of normal patching or software installation windows is suspicious.
Detect ETW tampering — Monitor for ETW provider status changes and session modifications. Loss of ETW visibility often indicates kernel-level interference.

Lab Validation

In a controlled lab, validating your detection coverage for BYOVD requires understanding the full attack chain. The Veil Framework helps generate the payloads that an attacker would execute after disabling EDR. Testing this chain end-to-end — from driver loading through payload execution — validates that your defenses catch the attack at multiple points.

The Veil-Evasion module is relevant for understanding what an attacker does after EDR is disabled, while the detection strategies described in the process injection article and root CA abuse article address related post-exploitation techniques.

BYOVD (Bring Your Own Vulnerable Driver): The Latest EDR-Killer Strategy