Your EDR is running. Your antivirus is updated. Your security stack looks solid — right up until the moment an attacker loads a three-year-old graphics card driver, reaches directly into the Windows kernel, and turns everything off before your tools can react.

That is BYOVD. And in March 2026, researchers confirmed that 54 separate EDR killer tools now use this technique, collectively abusing 35 different signed, legitimate drivers.

TL;DR

  • BYOVD abuses legitimate but vulnerable Windows drivers to gain kernel-level access
  • Attackers use this access to kill EDR/AV tools before deploying ransomware or rootkits
  • Real-world users: Lazarus Group, RansomHub, BlackByte, Scattered Spider, Akira
  • Detection relies on Sysmon Event ID 6 (driver load monitoring)
  • Key mitigations: HVCI, WDAC with Microsoft’s Vulnerable Driver Blocklist

Why the Kernel Changes Everything

To understand BYOVD, you need to understand one thing: in Windows, not all code runs with the same level of trust.

User-mode applications — your browser, your terminal, your malware scanner’s UI — run in a restricted layer. They cannot directly access hardware, memory belonging to other processes, or core OS structures. If malware lives only in user mode, your EDR can see it, flag it, and kill it.

The kernel is different. It is the innermost layer of the operating system. Code running in the kernel can read and write any memory, terminate any process, and disable any security feature — including the EDR that is supposed to catch it. Kernel code runs as ring 0, the highest privilege level on x86 hardware.

Microsoft knows this, which is why since Windows Vista, all kernel-mode drivers must be digitally signed by Microsoft. Unsigned drivers simply won’t load on modern 64-bit Windows systems.

This is where BYOVD comes in.

The Attack: Signed, Legitimate, and Dangerous

BYOVD (Bring Your Own Vulnerable Driver) works like this:

  1. Attacker finds a legitimate driver — one that was signed by Microsoft or a trusted vendor, but contains a known vulnerability that allows arbitrary memory writes or direct kernel access.
  2. Attacker drops the driver onto the target system. It is signed, so Windows loads it without complaint.
  3. Attacker exploits the vulnerability in the driver to execute their own code at kernel level.
  4. From the kernel, attacker terminates security processes, disables monitoring, or installs a rootkit.
  5. Attacker deploys their actual payload — ransomware, a backdoor, credential dumper — into a now-blind environment.

Think of it like hiring a locksmith. The locksmith is legitimate (signed certificate, verified identity), but once they open the door, who walks through next is entirely up to whoever hired them.

The driver itself does not need to be malicious. It just needs to have a vulnerability the attacker can exploit. Many of the abused drivers come from legitimate software: graphics utilities, CPU tuning tools, forensic software, even antivirus products.

Real-World Examples

Lazarus Group — FUDModule Rootkit

North Korea’s Lazarus Group is the most technically advanced BYOVD operator on record. Their FUDModule rootkit is specifically designed to disable kernel-level security monitoring.

In their earlier campaigns, Lazarus abused a Dell hardware driver (dbutil_2_3.sys) — a perfectly legitimate driver shipped with Dell firmware update tools — to reach the kernel. When that technique was burned, they escalated:

  • CVE-2024-21338: A zero-day in appid.sys, the Windows AppLocker driver — a Microsoft-signed component of Windows itself. Lazarus used this to bypass even BYOVD-hardened environments.
  • CVE-2024-38193: A zero-day in AFD.sys (Windows Ancillary Function Driver for WinSock) to install an updated FUDModule that could specifically disable CrowdStrike Falcon, Windows Defender, AhnLab V3, and HitmanPro.

The progression from “abuse someone else’s old driver” to “exploit a zero-day in a Windows built-in driver” shows how BYOVD techniques evolve when defenders close off the easier paths.

RansomHub — EDRKillShifter

The RansomHub ransomware-as-a-service group developed a dedicated tool called EDRKillShifter specifically to weaponize vulnerable drivers against EDR products. The tool is modular, supports multiple driver payloads, and has been observed in use by eight different ransomware groups — making it effectively a shared BYOVD-as-a-service infrastructure for the criminal ecosystem.

BlackByte Ransomware — RTCore64.sys

BlackByte ransomware operators abused RTCore64.sys, a driver bundled with MSI Afterburner (a popular GPU overclocking utility used by gamers worldwide). The driver has legitimate memory read/write functionality for hardware access — which attackers repurpose to patch security product memory and terminate EDR processes.

Scattered Spider — Intel Network Adapter Driver

The Scattered Spider threat group (responsible for high-profile attacks on MGM Resorts and Caesars Entertainment) was observed loading an old, revoked Intel network adapter driver to disable security software. The driver was long since pulled from active use, but Windows still accepted it because it carried a valid Microsoft signature from the time it was issued.

Terminator — Zemana Anti-Malware Driver

A tool called Terminator, advertised on cybercriminal forums by a threat actor known as Spyboy, exploited zamguard64.sys — a driver from Zemana Anti-Malware, an antivirus product. The irony of an antivirus driver being weaponized to kill other antivirus tools was not lost on the security community. Terminator claimed the ability to terminate any AV, XDR, or EDR product on the market.

Akira Ransomware — CPU Tuning Tool

Akira ransomware was observed loading the driver from a CPU tuning utility to disable Microsoft Defender before deploying encryption. This case highlighted a growing trend: attackers are specifically hunting for drivers in enthusiast and gaming software, where the driver’s memory-access capabilities are legitimate features, not bugs.

Avast Anti-Rootkit Driver (aswArPot.sys)

In a campaign documented in late 2024, attackers dropped aswArPot.sys — a legitimate component of Avast antivirus — and exploited it to terminate security processes. This case was notable because the driver has legitimate process-termination capabilities built in, reducing the exploit complexity required.

The Numbers Problem

As of March 2026, the scope of the BYOVD problem is significant:

MetricNumber
EDR killer tools using BYOVD54
Distinct vulnerable drivers abused35
Drivers on Microsoft’s blocklistFraction of known-bad drivers
Ransomware groups using BYOVDMultiple major groups

The gap between “known vulnerable drivers” and “drivers on the blocklist” is where attackers operate. Community projects like loldrivers.io attempt to catalog all known-abused drivers, but the list grows continuously.

Detection: What to Look For

BYOVD is hard to catch after the fact — once your EDR is dead, it stops generating telemetry. The window for detection is during driver load, before the exploit runs.

Sysmon Event ID 6 — Driver Loaded

Sysmon’s Event ID 6 logs every kernel driver load, including the driver’s hash, path, and whether it is signed. This is your primary detection surface.

<!-- Sysmon config: log all driver loads, flag suspicious ones -->
<DriverLoad onmatch="include">
  <Hashes condition="contains">SHA256</Hashes>
</DriverLoad>

Cross-reference loaded driver hashes against the loldrivers.io database or your SIEM’s threat intel feeds. Anomalous driver loads from %TEMP%, %AppData%, or any user-writable directory are immediate red flags — legitimate drivers are installed to %SystemRoot%\System32\drivers.

Windows Event IDs 3023 / 3033

When WDAC (Windows Defender Application Control) blocks a driver, it logs Event ID 3033 (block) or 3023 (audit mode, would have blocked). Monitoring these in your SIEM tells you when someone tried to load a blocked driver — which is worth investigating even if the block succeeded.

Behavioral Indicators

Look for this sequence in your telemetry:

  1. A process (often with a random name) drops a .sys file to disk
  2. A service is created to load that .sys file
  3. Shortly after, security processes (e.g., MsMpEng.exe, CSFalconService.exe, SentinelAgent.exe) terminate unexpectedly
  4. Ransomware or lateral movement begins

The gap between step 2 and step 3 is typically measured in seconds. Automated alerting on unexpected security process termination is critical.

Sigma Rule (Driver Load from Unusual Path)

title: Suspicious Kernel Driver Loaded from User-Writable Path
status: experimental
logsource:
  product: windows
  category: driver_load
detection:
  selection:
    ImageLoaded|contains:
      - '\AppData\'
      - '\Temp\'
      - '\ProgramData\'
      - '\Users\Public\'
  condition: selection
falsepositives:
  - Some legitimate installers temporarily stage drivers
level: high

Mitigation: How to Raise the Bar

No single control eliminates BYOVD risk, but layering these significantly increases attacker cost:

1. Enable HVCI (Hypervisor-Protected Code Integrity)

HVCI (also called Memory Integrity in Windows Security settings) uses hardware virtualization to enforce kernel code integrity. With HVCI enabled, even if a vulnerable driver loads, the attacker’s ability to modify kernel memory is significantly restricted.

Enable via Group Policy: Computer Configuration → Administrative Templates → System → Device Guard → Turn on Virtualization Based Security

Or via registry:

Terminal window
# Enable HVCI (Memory Integrity)
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" -Name "Enabled" -Value 1

Note: HVCI can cause compatibility issues with older drivers. Test in a staging environment first.

2. Enable the Microsoft Vulnerable Driver Blocklist

Microsoft maintains a Vulnerable Driver Blocklist as part of WDAC. When enabled, Windows refuses to load any driver on the list — regardless of its signature.

Terminal window
# Check if blocklist is enabled
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\CI\Config" -Name "VulnerableDriverBlocklistEnable"


# Enable vulnerable driver blocklist
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\CI\Config" -Name "VulnerableDriverBlocklistEnable" -Value 1

The blocklist is updated several times per year. Combine with WDAC policy deployment for enterprise-wide enforcement.

3. Deploy WDAC Policies

WDAC (Windows Defender Application Control) can enforce which drivers are allowed to load at a system-wide level. A well-configured WDAC policy can block entire categories of unknown drivers, not just the ones on the Microsoft blocklist.

This is particularly powerful for servers and high-value workstations where the set of legitimate drivers is well-defined.

4. Audit Loaded Drivers Regularly

Use loldrivers.io to cross-reference currently loaded drivers on your systems against the known-bad driver database:

Terminal window
# List all loaded kernel drivers with hashes
Get-WmiObject Win32_SystemDriver | Where-Object {$_.State -eq "Running"} |
  ForEach-Object {
    $path = $_.PathName -replace '"', ''
    if (Test-Path $path) {
      $hash = (Get-FileHash $path -Algorithm SHA256).Hash
      [PSCustomObject]@{ Name = $_.Name; Path = $path; SHA256 = $hash }
    }
  } | Export-Csv -Path "loaded_drivers.csv" -NoTypeInformation

Submit the resulting hashes to loldrivers.io or check against your threat intel platform.

5. Monitor and Alert on Security Process Termination

Configure your SIEM or EDR to alert immediately when security-related processes terminate unexpectedly. This won’t stop BYOVD, but it gives your SOC the best chance to respond before ransomware encrypts anything.

What You Can Do Today

PriorityAction
HighEnable HVCI (Memory Integrity) on all endpoints
HighEnable Microsoft Vulnerable Driver Blocklist
HighDeploy Sysmon with driver load logging (Event ID 6)
MediumCross-check loaded drivers against loldrivers.io
MediumAlert on unexpected termination of security processes
MediumDeploy WDAC policies on servers and high-value endpoints
LowReview installed software — remove GPU overclockers, CPU tuners from servers

Going Deeper: Windows API Abuse

BYOVD attacks rely on specific Windows kernel APIs to interact with processes, memory, and security features. Understanding which APIs are abused — and how defenders can detect their misuse — is a core skill for both red team operators and blue teamers building detection rules.

The Windows API Abuse Atlas by Dana Faye is an excellent reference that maps Windows API calls to attack techniques, MITRE ATT&CK coverage, and detection opportunities. If BYOVD and kernel-level evasion are in your threat model, it is worth bookmarking.

Sources