Summary
- Researchers demonstrated several chains that use emulated USB devices to trigger automatic installation of vulnerable signed vendor components.
- Some attacks worked without a logged-in user, while another used RDP USB redirection without physical access to the target.
- The research describes a broader trusted-installation problem rather than one newly disclosed Windows vulnerability.
Security researchers have demonstrated a series of attack chains that abuse Windows Plug and Play to make the operating system install trusted vendor components which can then be used to obtain SYSTEM-level privileges.
The research, presented under the name Plug and Pwn, targets the automatic device-installation process in Microsoft Windows rather than relying on a single new operating-system vulnerability.
When Windows detects supported hardware, Plug and Play can locate and install associated drivers, services, co-installers, and vendor applications. Those components may execute with high privileges because device installation is a system function.
Researchers Alejandro Hernando and Borja Martínez demonstrated that software capable of emulating USB hardware can present Windows with chosen device identities, causing the operating system to retrieve signed packages associated with those devices.
The attack then relies on weaknesses or unsafe behaviour inside the vendor components that Windows has installed. In one demonstration, the researchers impersonated multiple devices in sequence, combining behaviour in Sierra Wireless and Sony FeliCa packages to alter DNS resolution, redirect an insecure download, place a malicious file on the host, and ultimately execute code as SYSTEM.
The researchers said the chain was demonstrated against a fully updated Windows 11 machine with no user logged in. The significance is not that the malicious peripheral itself arrives with a conventional exploit, but that it can induce Windows to fetch trusted software which provides the exploitable path.
A second approach removes the need for physical USB hardware. The researchers used USB redirection through Remote Desktop Protocol to present fabricated device descriptors to a remote Windows host. Windows treated the emulated hardware as a legitimate redirected device and installed matching vendor software.
That demonstration used an Intel RealSense package containing a component that could be abused for DLL hijacking and privilege escalation. It requires RDP USB redirection to be enabled, so it does not represent an arbitrary remote attack against every Windows system.
The distinction is important because the research combines operating-system trust decisions, hardware identity, signed vendor packages, and weaknesses in third-party components. Removing any one part of an individual chain may stop that demonstration while leaving the wider installation model intact.
Signed software is normally treated as a positive trust signal. Plug and Pwn demonstrates the limits of that assumption where Windows is authorised to retrieve a legitimate package automatically but the package itself exposes privileged behaviour that can be manipulated after installation.
The same architecture complicates vulnerability ownership. Some weaknesses reside in individual vendor packages, while other parts of the attack depend on Windows automatically matching hardware identifiers and executing installation components with SYSTEM privileges. The researchers said not all scenarios have been reported as individual new vulnerabilities because some become dangerous only when several legitimate behaviours are chained together.
Peripheral control has traditionally concentrated on preventing unknown storage devices, keyboards, or other USB equipment from interacting with sensitive machines. This work broadens the question to include what trusted software a device can cause the operating system to install automatically.
The researchers also found that disabling Windows co-installers disrupts some of the demonstrated chains but does not remove every route because driver staging, INF processing, Plug and Play enumeration, and installed services remain available through other parts of the device-installation process.
The result is less a conventional patch story than a product-trust problem. Hardware identity, signed drivers, automated installation, remote device redirection, and third-party software collectively form an execution chain that can cross privilege boundaries even when each component is behaving largely as designed.
