What BYOVD Is
Bring Your Own Vulnerable Driver (BYOVD) is an attack technique where an attacker deliberately installs a legitimate — but outdated and exploitable — kernel driver onto a compromised Windows system. Because the driver is signed by a trusted hardware manufacturer, Windows loads it into the kernel without complaint. The attacker then exploits the driver’s known vulnerability to execute code at the kernel level, bypassing the user-mode security controls that protect EDR and endpoint protection software.
The technique has been known for several years, but its adoption by major ransomware groups operating at volume — Qilin (131 victims in March alone) and Warlock — marks a significant escalation. What was previously associated with sophisticated nation-state actors is now a standard capability of financial-crime ransomware operations.
The Technical Mechanism
According to analysis by Cisco Talos and Trend Micro, the Qilin implementation works through a malicious DLL named msimg32.dll. This DLL initiates a multi-stage infection chain that:
- Deploys two legitimate but vulnerable kernel drivers —
rwdrv.sys(a renamed version of ThrottleStop.sys, a hardware monitoring tool) andhlpdrv.sys - Uses
rwdrv.systo gain read/write access to physical memory at the kernel level - Uses
hlpdrv.systo enumerate and terminate processes associated with security software - Targets over 300 EDR drivers from virtually every security vendor in the market
The DLL is loaded via DLL search order hijacking — placed in a directory where a legitimate application will load it preferentially over the real Windows system DLL. This initial loading typically occurs after the attacker has achieved administrative access via stolen credentials.
In a documented January 2026 Qilin intrusion, the group used a loader disguised as a legitimate security executable, then used Group Policy deployment to push the BYOVD capability across the entire compromised domain — disabling EDR on every domain-joined workstation and server simultaneously before deploying the ransomware encryptor.
What This Means for Defenders
The security implication is stark: organisations whose ransomware defence relies primarily on EDR software should reassess their defensive posture. A technique that can disable 300+ EDR products from the kernel level fundamentally undermines endpoint-centric detection and response strategies.
Several defensive limitations become apparent:
- EDR alerts may not fire before being killed. If the BYOVD technique successfully terminates the EDR process before the ransomware payload runs, the EDR has no opportunity to detect, alert, or block the encryption activity.
- Tamper protection helps but is not absolute. Most modern EDR solutions include tamper protection that attempts to prevent their own processes from being killed. However, kernel-level attacks via signed drivers operate below the protection boundary.
- Managed detection and response (MDR) providers have a narrow window. If an MDR provider is notified of an EDR agent going offline, human response time may still be too slow to prevent encryption.
Defences That Remain Effective
The BYOVD technique does not render all defences obsolete, but it shifts the emphasis:
Network-level controls are not bypassed by endpoint BYOVD attacks. Anomalous SMB traffic during lateral movement, unusual volume of file system activity, and unexpected domain controller connections should be visible at network monitoring layers even when endpoint agents are disabled.
Kernel-level EDR protections (Protected Process Light, ELAM) and vendors’ kernel minifilter drivers are harder to terminate than user-mode processes. EDR vendors including CrowdStrike and SentinelOne have implemented or are implementing kernel-level anti-tampering that requires driver-level attacks to succeed — verify your EDR is configured to use these protections.
Driver blocklisting — Microsoft’s Vulnerable Driver Blocklist (updated via Windows Defender and Windows Update) — aims to block known-malicious driver versions from loading. The specific drivers used in Qilin’s BYOVD campaign should be added to the blocklist; ensure Windows Defender is current.
Privileged access controls — BYOVD requires administrative access to load a kernel driver. Organisations that enforce strict privilege separation and require jump host / PAM access for administrative operations limit the attacker’s ability to stage the BYOVD attack even after initial compromise.
Recommended Actions
-
Update the Microsoft Vulnerable Driver Blocklist. Ensure Windows Defender is current — Microsoft periodically updates the built-in blocklist for known-malicious drivers. Verify
rwdrv.sys(ThrottleStop.sys derivatives) is blocked via custom Defender rules or WDAC policies. -
Enable Windows Defender Application Control (WDAC) driver signing policies. WDAC can enforce that only explicitly allowed drivers are loaded, blocking the BYOVD technique at the kernel loading stage.
-
Verify your EDR’s tamper protection and kernel driver self-protection features are enabled. Consult your EDR vendor’s documentation on kernel-level protection capabilities and ensure they are active — many vendors require explicit configuration to enable maximum self-protection.
-
Implement network-based detection for pre-ransomware activity. Deploy or tune network detection for lateral movement indicators: unusual SMB tree connections, volume shadow copy deletion (vssadmin commands), mass file rename events at the network share level.
-
Restrict driver installation permissions. Only administrators should be able to install kernel drivers, and administrative operations should require PAM/jump host access with logging. This limits the attacker’s ability to stage BYOVD even after credential theft.