A new security study highlights a troubling escalation path in Windows 11: USB PnP Auto-Install. The researchers describe how the normal Plug and Play (PnP) device-install workflow—meant to load legitimate vendor drivers—can be abused so an unprivileged user ends up executing code with SYSTEM privileges, provided several conditions are met.
What makes the report especially important is that the attack logic is not limited to having a physical USB device connected. In a second scenario, they outline a remote approach using Remote Desktop when USB redirection features are enabled. The study emphasizes that this is not a universal exposure and depends heavily on configuration.
Why Windows Plug and Play becomes an attack surface
Windows Plug and Play is designed to make device setup seamless. When a device appears, the system receives hardware identifiers and compatible IDs. It then uses those identifiers to locate a matching driver package and run vendor-provided installation components.
According to the researchers, this “find a driver, then run installation pieces” sequence can become a chain reaction. The core idea is to treat the PnP auto-install path as a privileged execution route and then redirect the installed components toward attacker-controlled outcomes.
Chaining USB PnP Auto-Install to SYSTEM locally
The physical attack path in the study begins with emulating a specific USB device so Windows selects the corresponding vendor driver and installation workflow. In their demonstration, the emulation is used to trigger installation of a vendor service that runs with SYSTEM-level access.
The researchers report several steps in the chain:
- They emulate a device so Windows installs a service executable that exposes a capability to interact with DNS settings (a “SetDNS” primitive).
- They then use that DNS control to redirect where the next-stage components will fetch resources.
- Next, they emulate a card reader model so a co-installer retrieves additional configuration files from a server over plaintext HTTP, and they derive local filenames from URL path segments.
- Finally, a path traversal weakness allows them to place a DLL into System32. When the emulated device is reconnected, Windows loads the planted DLL, resulting in SYSTEM code execution.
The demonstration was performed on a fully updated Windows 11 machine. The researchers caution against assuming the same behavior automatically applies to every Windows 11 version, because the work depends on the exact conditions and components involved.
Remote Desktop variant: the same flow over synthetic USB traffic
Beyond the physical scenario, the study describes a remote variant that can trigger the same PnP auto-install logic without attaching real hardware. The researchers explain that this requires Remote Desktop support features to be configured for Plug and Play or for low-level USB redirection.
In the remote path, the attacker replaces the physical device with synthetic USB traffic delivered through Remote Desktop. Their Python client forges a USB identity and presents a “phantom” device so Windows follows the redirected device-installation route.
They note Microsoft documentation and behavior: remote low-level USB redirection uses the same driver-installation process as a physical Windows computer. However, Microsoft also states that such redirection is not allowed by default under Remote Desktop.
Once the redirected installation path is followed, the study claims the resulting vendor software can be abused further. Specifically, they describe a DLL search-order hijack technique leveraging a user-writable installation directory to move execution into SYSTEM code paths.
What must be true for the attack to work
A key theme in the report is that this is not a generic “Windows is broken” claim. Instead, it is a conditional chain built from:
- Ability to present an emulated USB device to the target machine for the local scenario.
- Correct PnP behavior so Windows selects the intended vendor identifiers and compatible IDs and then runs the appropriate installation steps.
- Vendor package weaknesses that researchers can chain together (for example, issues enabling configuration retrieval, filename control, and path traversal), while the PnP mechanism provides the privileged execution surface.
- Remote configuration for the Remote Desktop scenario, because Microsoft says Remote Desktop Services does not allow supported Plug and Play and RemoteFX USB redirection by default.
In other words, the attack uses a legitimate installation workflow, but it pairs it with weak or exploitable behavior in signed third-party packages to achieve the final privilege escalation.
Why this matters: signed packages still aren’t risk-free
The study’s technical core is a reminder that digital signing alone does not prevent abuse if the trusted installation logic contains vulnerabilities. Here, the researchers rely on the fact that Windows can launch privileged installation components from vendor driver packages after selecting them via device identifiers.
Because the path begins as a normal device install, defenders can easily miss the early stage. The malicious outcome occurs only after multiple steps align: DNS redirection, configuration retrieval, filesystem influence, and DLL loading—followed by execution under SYSTEM.
Mitigations administrators can consider
Microsoft provides guidance and restrictions for device installation, and the study references these controls. Administrators can reduce exposure by restricting which devices are allowed to install based on identifiers and class information.
In particular, device-installation policies can be configured using criteria such as:
- hardware or compatible IDs
- device-instance IDs
- setup class
The researchers also highlight that on a Remote Desktop server, those policies may apply to redirected devices as well. That means well-tuned device restrictions can help limit what redirected PnP auto-install is allowed to do.
Separately, Microsoft’s stance on Remote Desktop USB redirection is that administrators who do not need the feature can leave it disabled. Since the remote route is configuration-dependent, tightening Remote Desktop device-forwarding settings can shrink the attack surface considerably.
Attribution and scope notes from the researchers
The report stresses responsible attribution. The researchers describe the mechanics of specific vendor chains they emulated and explain that these remain findings from the researchers. They advise that the details should be treated as researcher findings unless independent vendor-confirmed material demonstrates the same issues.
They also caution readers not to generalize the results across all Windows environments. Their demonstration was carried out on a fully updated Windows 11 system, and the chain relies on multiple components and behaviors that may vary with version and installed software.
Bottom line
USB PnP Auto-Install is intended to simplify device setup, but this study shows how the same mechanism can become a privilege escalation pathway. By emulating devices that trigger specific vendor driver installation behavior, researchers chained trusted installation steps into SYSTEM code execution. They further show that a Remote Desktop variant can follow a similar route when USB redirection features are enabled.
If your organization uses Remote Desktop, review USB redirection and Plug and Play-related settings. Also consider enforcing strict device installation policies so Windows is less likely to run arbitrary vendor installation flows for unexpected hardware identifiers.
Source: https://thehackernews.com/2026/08/researchers-turn-usb-auto-install-into.html
