An exploitation chain that leverages a legitimate Windows mechanism

On August 11, 2026, security researchers revealed at DEF CON 34 a technique dubbed "Plug And Pwn: Weaponizing Windows PnP Auto-Install," demonstrating how the Windows Plug and Play (PnP) subsystem — designed to automatically install drivers when a device is connected — can be turned into a privilege escalation vector up to the SYSTEM level, the highest on Windows.

Researchers Alejandro Hernando (known by the alias 0xedh) and Borja Martínez (borjmz), both security researchers and red teamers, presented this research at the DEF CON 34 conference held in Las Vegas. This was their second appearance at DEF CON, following their talk "Kill Chain Reloaded" presented at edition 33.

The exploitation was demonstrated on a fully up-to-date Windows 11, making it a particularly notable finding. As highlighted by The Hacker News article, however, the result should not be generalized to untested versions of Windows.

How the Windows PnP mechanism works

To understand the attack, one must first comprehend how Windows installs drivers. According to the official Microsoft documentation, when a device is connected, Windows retrieves its hardware IDs and compatible IDs — identification strings provided by the manufacturer — and compares them to the available driver packages in the driver store, at the locations specified by the DevicePath registry key, or via Windows Update.

The system assigns a "rank" to each matching package: the lower the rank, the better the match. Windows then installs the driver with the lowest rank. This fully automated process requires no user intervention — it is precisely this automation that the researchers exploited.

The physical exploitation chain: Sierra Wireless, Sony FeliCa, and path traversal

The physical attack chain relies on the emulation of specific USB devices, using a tool developed by the researchers to simulate arbitrary devices. Here are the detailed steps:

  1. Emulation of a Sierra Wireless device: The researchers emulate a Sierra Wireless device, prompting Windows to install SwiService.exe, a service running at the SYSTEM level. This service exposes a SetDNS primitive that allows for DNS redirection.

  2. Emulation of a Sony FeliCa reader: Next, the researchers emulate a Sony FeliCa card reader. The co-installer for this device retrieves configuration files via plaintext HTTP (unencrypted) and derives local file names from URL paths.

  3. Path traversal to System32: The researchers discovered a path traversal vulnerability in this co-installer, enabling them to place a malicious DLL directly into the System32 folder.

  4. Loading the planted DLL: By reconnecting the Sierra Wireless device, Windows loads the planted DLL — which executes with SYSTEM privileges.

This chain illustrates an abuse of a legitimate privileged installation path, combined with weaknesses in third-party signed software packages. As noted by The Hacker News, the specific exploitation mechanisms related to Sierra, Sony, and Intel remain findings attributed to the researchers and should remain so until the concerned manufacturers independently confirm them.

The remote variant via RDP: a ghost Intel RealSense

The remote variant of the attack is particularly interesting: it replaces the physical device with synthetic USB traffic transmitted via the RDP (Remote Desktop Protocol).

The researchers developed a Python client that forges a USB identity and presents a ghost Intel RealSense device to the target machine. Windows then follows the redirected device installation path and installs the RealSense software.

The exploitation then occurs through a DLL search order hijacking (CRYPTBASE.dll) from a user-writable installation directory, giving the low-privileged authenticated user SYSTEM-level code execution.

Microsoft confirms in its documentation that low-level redirected USB devices use the same driver installation process as a physical Windows machine. However, the company specifies that RDP services do not allow by default Plug and Play redirection or USB RemoteFX redirection. Low-level USB redirection requires that Plug and Play redirection be enabled beforehand.

Prerequisites and precautions

It is crucial to note that this attack has significant prerequisites:

  • For the physical chain: the attacker must be able to present an emulated USB device to the target machine. This implies direct physical access or the ability to inject a malicious USB device.

  • For the remote variant: USB redirection must be explicitly enabled in the RDP configuration — which is not the case by default. Administrators who do not require this feature can leave it disabled.

Mitigation measures according to Microsoft

Microsoft offers several documented defense mechanisms in its guide to managing device installations via group policies:

  • Restricting device installation: Administrators can allow or block devices by hardware ID, compatible ID, device instance ID, or setup class. These policies can also affect redirected devices on a Remote Desktop server.

  • Device whitelists/blacklists: It is possible to create precise allow/block lists, allowing for example only a limited set of approved USB keys while blocking all other USB devices.

  • Disabling USB RDP redirection: For environments that do not need it, simply leaving USB redirection disabled (default configuration) eliminates the remote attack vector.

The context of the researchers and their previous work

This research is part of a lineage of work by both researchers. Alejandro Hernando, active on GitHub under the alias 0xedh, is notably recognized for his research on a path traversal in mstsc.exe (the Windows RDP client), the exploitation of firmware in Hichip P2P cameras, or the bypassing of protections on Schneider PLCs. Borja Martínez (borjmz) has collaborated with him on several of these projects, including the talk "Kill Chain Reloaded" presented at DEF CON 33 in 2025.

Their common approach is to exploit legitimate operating system mechanisms — here the PnP auto-installation — in combination with vulnerabilities in third-party signed software, rather than directly targeting the Windows kernel.

A lesson on the ecosystem of signed drivers

What makes this research particularly concerning is that it does not rely on a single flaw in Windows, but on the chain of multiple weaknesses in the signed driver ecosystem:

  • A SYSTEM service exposing a DNS modification primitive (SetDNS)
  • A co-installer retrieving configuration files over unencrypted HTTP
  • A path traversal vulnerability allowing writing to System32
  • A DLL search-order hijacking vulnerability in a user-writable directory

Each of these weaknesses individually might seem minor, but their combination produces a complete exploitation chain leading to SYSTEM. This serves as a reminder that the security of Windows not only depends on the operating system itself but also on the security quality of the drivers and software that manufacturers publish and that Windows installs automatically — often without any user interaction.

The research will be presented in detail at DEF CON 34, and the tools developed by the researchers are expected to be released later, allowing the security community to reproduce and delve deeper into these findings.