Unveiling Hidden Attack Vectors: A Technical Analysis of Windows Kernel Driver Exploitability Without Dedicated Hardware

A recent technical analysis by the Atos Threat Research Center has shed new light on the exploitability of Windows kernel-mode drivers, revealing that many vulnerabilities previously considered hardware-gated can, in fact, be triggered and exploited from user mode without the presence of the specific physical hardware they were designed for. This groundbreaking research significantly broadens the perceived attack surface for "Bring Your Own Vulnerable Driver" (BYOVD) attacks, urging a critical reassessment of driver security postures.

The Rising Tide of BYOVD Attacks

BYOVD attacks have become a formidable tactic in the arsenal of sophisticated threat actors, including ransomware groups and state-sponsored entities. These attacks leverage legitimate, albeit vulnerable, kernel-mode drivers to gain elevated privileges, disable security solutions like Endpoint Detection and Response (EDR) systems, and establish persistent footholds within compromised environments. The appeal of BYOVD lies in its ability to bypass user-mode security mechanisms, operating directly within the Windows kernel, a highly privileged and often tamper-resistant layer.

Traditionally, a key criterion for assessing a driver vulnerability’s suitability for BYOVD attacks has been its independence from rare system conditions, particularly the presence of specific hardware. Many drivers are designed to interact only with their corresponding physical devices, leading to the assumption that their vulnerabilities would be inaccessible without that hardware. However, this new research challenges that assumption, demonstrating practical methodologies for bypassing these hardware dependencies.

Technical Foundations: Understanding Device Objects and PnP

The Windows operating system manages hardware and software interactions through a sophisticated Plug and Play (PnP) architecture, which relies heavily on "device objects." These kernel-mode structures represent devices, and they are the primary conduits through which user-mode applications and other kernel components interact with drivers via I/O Request Packets (IRPs). The analysis focuses on how these device objects are created and maintained, identifying critical junctures where an attacker can influence driver initialization.

Drivers can create device objects in a few primary ways:

1. Unconditional Creation: Some legacy or non-PnP drivers create their device objects directly during their DriverEntry function, which executes immediately upon driver loading. These drivers are the easiest to interact with, requiring only basic service creation and startup commands (sc.exe). The loldrivers.io repository, a well-known catalog of vulnerable drivers, features many such examples whose deployment matches this straightforward pattern.
2. Conditional Creation (PnP-Driven): The majority of modern device drivers are PnP-compatible, meaning their device objects are created and managed by the PnP Manager. This process often occurs within specific PnP-related routines like AddDevice (or EvtDriverDeviceAdd in WDF drivers) and the IRP_MJ_PNP handler. These routines are responsible for creating Functional Device Objects (FDOs) and Filter Device Objects, initializing internal variables, and setting up I/O queues. Crucially, these routines are not automatically invoked upon driver load; the PnP Manager calls them only when it discovers a new device node and determines that the driver should control or filter it.

The research highlights two main obstacles to attacking a driver via its device object without the correct hardware: either the device object is never created, or the driver’s internal state prevents the vulnerable code path from being reached despite the device object’s existence. Both scenarios are common when a device driver is deployed on a system lacking its corresponding physical hardware.

Bypassing Hardware Gating: Methodologies from Userland

The core innovation of this research lies in detailing userland-only techniques (requiring administrative privileges) to overcome these hardware-gating mechanisms, effectively making previously inaccessible vulnerabilities reachable. These techniques do not rely on physical access, hypervisor access, disabled driver signature enforcement, or kernel-mode debugging.

1. Simple sc.exe Deployment: For drivers that unconditionally create device objects in DriverEntry, a simple sc.exe command to create and start the service is often sufficient. Tools like PowerShell scripts can then enumerate device objects to detect newly created, userland-accessible CDOs (Control Device Objects). While effective for a subset of drivers, this method falls short for PnP-compatible drivers. Initial tests showed that this method results in a smaller number of detected device objects compared to methods that involve PnP interaction.

   

2. Software-Emulated Devices with Spoofed Hardware IDs: This technique targets PnP-compatible drivers by tricking the PnP Manager into invoking their AddDevice routines. It involves:

   

   • Identifying Hardware IDs: Extracting hardware IDs from the driver’s INF (Information) file, which links the driver to specific hardware.
   • Driver Staging: Using pnputil.exe to deploy the driver package to the Windows Driver Store.
   • Device Emulation: Employing devcon.exe (a WDK utility) or SetupAPI / Software Device API calls to create a new software-emulated device node with a spoofed hardware ID that matches the driver’s INF file. This action prompts the PnP Manager to install the staged driver for the emulated device.
   • Increased Reachability: Preliminary experiments using this approach yielded nearly twice as many new device objects created and detected compared to simple sc.exe deployments. This confirms its efficacy in making a broader range of PnP drivers accessible for vulnerability testing. The detected device objects include both named CDOs and FDOs attached to the software-emulated PDOs.

3. Filter Restacking for Enhanced Access: Filter drivers, designed to sit above or below other device objects in a "device stack," typically forward IRPs rather than directly handling IRP_MJ_CREATE requests. This means that placing a filter driver directly on a software-emulated PDO (which often rejects IRP_MJ_CREATE via nt!IopInvalidDeviceRequest) will not make it accessible. To circumvent this, the research proposes "filter restacking":

   

   • Create a software-emulated device.
   • Install a standard driver (e.g., a disk driver) on it, one that does support IRP_MJ_CREATE.
   • Modify the registry entries (UpperFilters or LowerFilters) for this device or its class to load the target filter driver on top of (or below) the standard driver.
   • This technique allows interaction with filter drivers for diverse device classes (disk, Bluetooth, mouse, keyboard, audio) even when their intended hardware is absent. For example, a gaming mouse filter driver was successfully loaded and interacted with atop a disk stack.

4. Forced Driver Replacement via Registry Manipulation: This advanced method completely bypasses the INF file mechanism, which primarily serves as a trust boundary for installation rather than a security boundary for execution. By directly manipulating specific registry structures (under SYSTEMCurrentControlSetEnum<DEVICE_INSTANCE_ID> and SYSTEMCurrentControlSetControlClass<GUID><INSTANCE_INDEX>), an attacker can bind a deployed driver (via sc.exe) to an existing or newly created device node. Restarting the device then triggers the PnP Manager to load the forced driver. This allows for arbitrary driver assignment, even if the driver is "not digitally signed" in the Device Manager GUI, as the .sys file itself may still be signed and trusted by the kernel.

   

Limitations and Future Outlook

Despite these sophisticated bypass techniques, some hardware-gated code paths remain inaccessible from purely userland operations. Complex hardware interactions and probing, such as specific Memory-Mapped I/O (MMIO) checks tied to non-existent hardware chip IDs, often require custom kernel-mode components or hypervisor access to spoof effectively. These requirements typically fall outside the scope of a standard BYOVD scenario.

The research concludes that the landscape of BYOVD-viable drivers is much larger than previously acknowledged. As Microsoft continues to harden Windows driver security (e.g., by removing trust for cross-signed drivers) and AI-accelerated vulnerability research progresses, threat actors may increasingly turn their attention to drivers whose vulnerabilities are only seemingly hardware-dependent. This necessitates that defenders understand the forensic footprint associated with these advanced deployment and interaction techniques to better identify and mitigate BYOVD threats. The findings underscore the continuous need for robust vulnerability research, rigorous risk assessment, and proactive defense strategies in the evolving domain of kernel-mode driver security.