Full Report
1 Introduction This article provides a technical analysis of how many Windows kernel mode drivers can be interacted with from user mode without the hardware they were developed for. This work was motivated by driver-oriented vulnerability research and the need to evaluate the exploitability of individual findings, which frequently affect code whose reachability is hardware-gated. The
Analysis Summary
# Vulnerability: Hardware-Gated Driver Attack Surface Bypass (BYOVD Research)
## CVE Details
* **CVE ID:** N/A (General Technical Analysis/Methodology)
* **CVSS Score:** N/A
* **CWE:** CWE-684 (Incorrect Provision of Specified Functionality), CWE-284 (Improper Access Control)
## Affected Systems
* **Products:** Windows Kernel Mode Drivers (specifically PnP and non-PnP drivers).
* **Versions:** Demonstrated on Windows 11 23H2 (Build 10.0.22631.3007).
* **Configurations:** Systems where vulnerable drivers are installed or can be loaded (Bring Your Own Vulnerable Driver - BYOVD), even if the associated physical hardware is absent.
## Vulnerability Description
The research addresses a common misconception in vulnerability research: that a driver is only exploitable if the physical hardware it manages is present on the system. The analysis focuses on "hardware-gated" reachability, where code paths containing vulnerabilities are thought to be protected by the absence of a device.
The study identifies that many drivers create **Device Objects**—the primary attack vector from userland—unconditionally upon loading (in the `DriverEntry` function) or through software-simulated device nodes. This allows an attacker to interact with the driver via I/O Request Packets (IRPs) even without the physical hardware, effectively opening the attack surface for kernel-level exploitation, such as arbitrary memory read/write or code execution.
## Exploitation
* **Status:** PoC patterns available; technique widely used in "BYOVD" (Bring Your Own Vulnerable Driver) attacks by ransomware groups (e.g., Qilin) and APTs.
* **Complexity:** Medium (Requires knowledge of Windows Device Objects and IRP handling).
* **Attack Vector:** Local (Requires the ability to load a driver or interact with an existing device object).
## Impact
* **Confidentiality:** High (Arbitrary kernel memory read).
* **Integrity:** High (Arbitrary kernel memory write; ability to disable EDR/security components).
* **Availability:** High (System crashes or resource exhaustion).
## Remediation
### Patches
* As this is a methodology/architectural analysis, remediation involves patching specific vulnerable drivers identified via this method.
* Microsoft maintains a **Windows Driver Blocklist** to prevent known vulnerable drivers from loading.
### Workarounds
* **Driver Signature Enforcement (DSE):** Ensure DSE is active to prevent the loading of unsigned, malicious drivers.
* **VBS/HVCI:** Enable Virtualization-Based Security and Hypervisor-Protected Code Integrity to mitigate kernel-mode exploits.
* **Microsoft Vulnerable Driver Blocklist:** Ensure the blocklist is being updated and enforced via Windows Defender or MDM policies.
## Detection
* **Indicators of Compromise:**
* Loading of known-vulnerable or "stale" drivers not matching the system's hardware profile.
* Unusual `DeviceIoControl` calls to undocumented or obscure device objects.
* **Detection methods and tools:**
* Monitoring for `System Event ID 6` (Driver Loaded) in Sysmon.
* Using tools like **WinObj** or **DeviceTree** to inspect device objects created by drivers without backing hardware.
* EDR alerts for "Living off the Land" driver usage.
## References
* Atos Cyber Shield - Anatomy of Access: Windows Device Objects: hxxps[://]atos[.]net/en/lp/cybershield/anatomy-of-access-windows-device-objects-from-a-security-perspective
* NDSS Symposium - Driver Research: hxxps[://]www[.]ndss-symposium[.]org/wp-content/uploads/2026-s1491-paper[.]pdf
* Sophos - Terminator Tool/BYOVD: hxxps[://]www[.]sophos[.]com/en-us/blog/itll-be-back-attackers-still-abusing-terminator-tool-and-variants