“Not all drivers with relevant vulnerabilities have practical value from the BYOVD perspective due to conditional (usually hardware-dependent) reachability of vulnerable code paths.” That is the central stake: kernel-mode driver bugs can be weaponized to undermine tamper-resistant security controls — but only if the vulnerable code is reachable. The Atos Threat Research Center demonstrates how reachability can be changed from userland on Windows 11 23H2.
BYOVD attacks and the offensive value of kernel drivers
The report defines two criteria that make a driver attractive for Bring-Your-Own-Vulnerable-Driver (BYOVD) attacks: (1) exploitation must enable meaningful disruption of defenses (arbitrary kernel memory read/write, arbitrary code execution, or arbitrary resource abuse); and (2) exploitability should not depend on rare system conditions such as the presence of specific hardware. The author cites public BYOVD research and notes that hardware-gating — code paths that run only when particular hardware is present — has received less attention in prior reports.
Device objects: why AddDevice and IRP handlers matter
The analysis centers on device objects as the primary attack vector. Non‑PnP drivers often create device objects unconditionally in DriverEntry and are reachable after a simple sc.exe create/start. Most real-world drivers, however, rely on PnP: AddDevice (stored in DriverObject->DriverExtension->AddDevice) is invoked by the PnP manager only when a device node appears. The decompiled AddDevice example in the report shows IoCreateDevice, IoAttachDeviceToDeviceStack, device extension initialization, and optional creation of a named control device object (CDO). Because drivers initialize internal state in AddDevice and in IRP_MJ_PNP handlers, AddDevice invocation is generally required to reach vulnerable branches.
Software-emulated devices: devcon, SetupAPI, and SoftwareDevice
The report demonstrates two userland-only ways to trigger AddDevice without the physical hardware. First: stage the INF into the driver store (pnputil.exe /add-driver) and create a software-emulated device with devcon.exe install using a spoofed hardware ID (the INF’s Models section contains the matching IDs). This forces PnP to treat the emulated PDO as real and invoke AddDevice. Second: use the Software Device API (SwDeviceCreate) to create an emulated PDO directly; these PDOs are owned by \Driver\SoftwareDevice.
In testing on Windows 11 23H2 the author reports roughly twice as many named device objects discovered with the devcon approach versus simple sc.exe deployment. A concrete example: AwinicSmartKAmps.sys (hardware ID ACPI\AWDZ8399) was installed via the emulated-device flow; its service name AwinicChip appeared as a driver object, AddDevice was called, and IRP_MJ_CREATE dispatch routines were hit when userland opened handles.
Filter restacking, forced replacement, and registry binding techniques
- Filter restacking: for filter drivers that forward IRP rather than accepting IRP_MJ_CREATE, the author shows how to make them accessible by inserting them into class UpperFilters for an always‑available class (Disk Drive) and then mounting a VHD to create a stack. Example: a gaming-mouse filter GMLXDFltr was loaded on a disk stack and its IRP_MJ_CREATE was hit when a handle on \\.\PhysicalDrive was opened — illustrating how class filters can be repurposed.
- Forced driver replacement and registry binding: rather than rely on INF matching, the author demonstrates creating the device instance registry entries that tie a driver’s service name to a given device instance (SYSTEM\\CurrentControlSet\\Enum\\ and SYSTEM\\CurrentControlSet\\Control\\Class\\\\), then restarting the device. A tool run shows sc.exe create AwinicDriver and create_sd_bind_driver.exe producing a device bound to the driver and restarting the device; the resulting driver is reported as “not digitally signed” in Device Manager because no INF/CAT metadata was present. The report explicitly states INF files and their signatures are not a kernel security boundary — they are an installation feature.
What this means for technologists, defenders, and adversaries
- Technologists and security teams: audit driver code paths that are reachable only after AddDevice or specific PnP activity; monitor for the creation of software-emulated devices and unexpected changes to UpperFilters/LowerFilters registry keys.
- Defenders and incident responders: the author urges attention to the forensic footprint of the techniques demonstrated — devcon/SetupAPI/SoftwareDevice creations, registry bindings that mimic INF-driven installs, and forced restacking of filters — because these are userland actions that can make hardware-gated vulnerabilities exploitable.
- Adversaries and penetration testers: the report documents multiple userland-only workarounds (software-emulated PDOs, forced registry binding, filter restacking) that can convert hardware‑gated driver code into reachable attack surface without physical or hypervisor access.
In closing, the Atos researcher concludes that while many kernel vulnerabilities remain hardware-gated, a sizable portion can be made reachable from userland by creating emulated device nodes or manipulating driver binding. The paper warns defenders to watch for the specific deployment and registry techniques that lower the barrier to BYOVD-style abuse. Tests were conducted on Windows 11 23H2 and the research is credited to Julian Horoszkiewicz, Atos Threat Research Center.
Original story — Making Vulnerable Drivers Exploitable Without Hardware (The Hacker News)
