Spoofed PnP nodes make Windows drivers reachable from userland

Researchers demonstrated that attackers with userland access and administrative privileges can cause Windows to invoke kernel drivers’ AddDevice (EvtDriverDeviceAdd) routines without the original hardware present. The technique creates software-emulated Plug and Play device nodes and forces the system to bind a driver package for those nodes, causing the PnP manager to call AddDevice.

AddDevice is not executed during DriverEntry. The PnP manager calls AddDevice only when it discovers a device node and decides a particular driver should own or filter that node. When AddDevice runs, the driver typically creates a functional device object (FDO), attaches to the device stack, initializes fields in the device extension, and sometimes creates named control device objects (CDOs) that accept user handles.

The researchers used two userland methods. One used SetupAPI calls and devcon.exe to create a fake device info set, set spoofed hardware IDs, register the device with the PnP manager, and call UpdateDriverForPlugAndPlayDevicesW to bind an INF-defined driver. The other used the SoftwareDevice API and SwDeviceCreate to create a software device directly. In both cases the kernel creates a physical device object (PDO) owned by either \Driver\PnpManager or \Driver\SoftwareDevice; when the driver installs successfully the PnP manager invokes AddDevice with a pointer to that PDO. The team detected newly created named device objects by listing \Device before and after deployment and by attempting to read security descriptors (SDDL) to confirm userland access.

Not all deployments produce userland-accessible devices. PDOs created by PnPManager or SoftwareDevice often have default device objects that do not handle IRP_MJ_CREATE, which prevents user processes from opening handles. A successful deployment requires that the installed driver or an upper filter accept IRP_MJ_CREATE; when that happens the stack will handle create requests and permit userland interaction. The researchers reported devcon-based, PnP-style deployments produced nearly twice as many newly accessible device objects as simple sc.exe kernel-service loads, which run DriverEntry but do not invoke AddDevice.

When AddDevice runs and the driver attaches device objects, code paths that depend on device-extension initialization become reachable. Many drivers set per-device state in AddDevice and later dispatch routines use those fields to select execution paths. Vulnerabilities behind those fields, CDOs or IOCTL handlers can be exercised from userland after PnP initialization completes. The research also examined direct hardware access routines, including memory-mapped I/O, PCI configuration access, DMA and interrupts, and showed arbitrary physical memory writes are possible in some unconditional implementations. Hardware-gated routines remain reachable on machines where device checks pass.

The work described a method to make filter drivers accessible called filter restacking. Researchers added a filter to a class’s UpperFilters registry entry (for example the Disk class) and mounted a virtual disk. PnP then built a device stack where the filter sat above a functional device object that accepts creates, allowing filters intended for other hardware classes to run on the accessible stack.

Practical barriers include that devcon is not bundled with Windows, UpdateDriverForPlugAndPlayDevices enforces INF/catalog signing checks, and many driver installations fail because INF dependencies are missing. The researchers used WinDbg to inspect driver objects and set breakpoints on AddDevice and IRP handlers, and used PowerShell scripts to enumerate device objects and SDDL entries. The results show administrative userland alone can cause many drivers to become reachable without physical hardware.