Plug and Pwn trasforma Windows PnP in un percorso remoto verso SYSTEM

🛡️ Executive Summary

• Plug and Pwn concatena componenti Sierra Wireless e Sony per ottenere code execution SYSTEM su Windows 11 semplicemente emulando dispositivi USB.
• NoPlug & Pwn usa USB redirection via RDP per creare periferiche fantasma e installare automaticamente driver privilegiati senza hardware fisicamente collegato.
• Wacom e un vecchio componente Atheros mostrano come pacchetti firmati e ancora distribuibili possano comporsi in una privilege escalation fino a SYSTEM.

Windows Plug and Play può trasformare l’identità dichiarata da una periferica in un percorso automatico per scaricare da Microsoft software del produttore ed eseguirne componenti con privilegi NT AUTHORITY\SYSTEM, anche senza una richiesta UAC e, in determinate configurazioni, senza alcun dispositivo fisicamente collegato. È il risultato di Plug and Pwn, ricerca di Alejandro Hernando e Borja Martínez presentata a DEF CON 34. I due ricercatori non descrivono una singola vulnerabilità universale di Windows, ma mostrano come il normale processo PnP possa diventare il collante tra bug e comportamenti insicuri presenti in pacchetti firmati di vendor differenti. La catena più estrema parte da una periferica USB emulata e termina con una shell SYSTEM; una seconda variante passa invece attraverso RDP USB redirection, trasformando un normale utente remoto in un vettore capace di innescare lo stesso percorso privilegiato.

Windows scarica software privilegiato in base all’identità USB

Il presupposto tecnico di Plug and Pwn è il normale funzionamento di Windows PnP. Quando una nuova periferica viene enumerata, Windows ricava dai descrittori USB valori come VID, PID, classe e interfacce, costruisce gli hardware ID e cerca un pacchetto compatibile nel Driver Store o attraverso Windows Update. Se il pacchetto può essere installato automaticamente, il Device Installation Service, eseguito come SYSTEM, scarica il CAB, lo inserisce nel Driver Store e avvia il processo di installazione.

La ricerca originale Plug and Pwn sottolinea il punto centrale: controllare i descrittori della periferica significa controllare quale identità hardware Windows tenta di risolvere, mentre eventuali co-installer, servizi e programmi di supporto forniti dal vendor entrano successivamente in un percorso privilegiato. Non significa che qualsiasi driver disponibile attraverso Windows Update sia sfruttabile, né che ogni pacchetto restituito dalle API Windows Update venga automaticamente installato. I ricercatori distinguono esplicitamente la discovery dal reale percorso Server Side Resolve utilizzato dal PnP. Il problema emerge quando un pacchetto effettivamente auto-installabile contiene una primitiva di sicurezza riutilizzabile dall’attaccante.

Sierra Wireless permette di modificare il DNS come SYSTEM

La prima catena utilizza un dispositivo Sierra Wireless EM7340 emulato con FaceDancer. L’installazione porta sul sistema SwiService.exe, servizio SYSTEM che espone una named pipe configurata con permessi di lettura e scrittura per Everyone. Qualsiasi utente locale e, secondo i ricercatori, anche un utente di dominio capace di raggiungere la pipe via SMB può invocare la funzione SetDNS. La primitiva non permette l’esecuzione arbitraria di shell command perché il servizio utilizza netsh con parametri in parte ricavati dal sistema, ma permette comunque di impostare a piacimento il DNS predefinito della macchina. Da sola è una debolezza con impatto limitato. Plug and Pwn la utilizza però come primo anello di una composizione: l’attaccante configura un resolver che inoltra normalmente il traffico verso Google DNS ma dirotta esclusivamente i domini necessari alla fase successiva. È proprio questa logica compositiva a distinguere la ricerca dalle classiche privilege escalation basate su un singolo bug, come quelle mostrate durante Pwn2Own Berlin 2026 contro Windows 11.

Sony FeliCa trasforma il DNS hijacking in una scrittura SYSTEM

Dopo aver ottenuto il controllo della risoluzione DNS, i ricercatori emulano una periferica Sony FeliCa. Il relativo pacchetto contiene un co-installer firmato, felica_coinst.dll, eseguito come SYSTEM durante l’installazione. Il componente scarica file di configurazione aggiuntivi utilizzando HTTP in chiaro e considera affidabile ciò che riceve dal server remoto. Controllando il DNS attraverso il componente Sierra, i ricercatori riescono quindi a impersonare l’infrastruttura dalla quale il software Sony recupera le proprie risorse. Il parser che determina il nome del file locale cerca soltanto l’ultimo / nell’URL e non filtra correttamente backslash e sequenze di traversal. Il risultato è una arbitrary file write come SYSTEM, utilizzabile per collocare una DLL controllata direttamente in System32. Nessuna delle due debolezze deve necessariamente apparire critica considerata isolatamente: Sierra concede la modifica del DNS e Sony una scrittura privilegiata condizionata al controllo della risposta HTTP. Insieme eliminano le rispettive precondizioni.

Una seconda emulazione Sierra carica la DLL e apre la shell SYSTEM

La catena fisica si conclude emulando nuovamente il dispositivo Sierra. Il relativo servizio finisce per caricare la DLL precedentemente depositata in System32, ottenendo arbitrary code execution come NT AUTHORITY\SYSTEM prima ancora che un utente effettui il login. L’intera dimostrazione richiede circa cinque minuti su un sistema Windows 11 aggiornato e parte da una macchina Linux con FaceDancer capace di impersonare le periferiche richieste.

La rilevanza non consiste quindi nel fatto che una USB esegua magicamente codice: i descrittori controllati permettono all’attaccante di indurre Windows a recuperare software firmato realmente associato a determinati hardware ID, mentre vulnerabilità logiche presenti nei pacchetti installati vengono concatenate fino al SYSTEM. Il percorso ricorda il problema più ampio della fiducia nei componenti privilegiati già evidenziato dalle privilege escalation Windows corrette nel Patch Tuesday di giugno 2026, ma qui il software vulnerabile può arrivare sul computer proprio attraverso il normale processo di installazione driver.

NoPlug and Pwn elimina completamente il requisito dell’USB fisica

La seconda dimostrazione cambia radicalmente il modello di minaccia. NoPlug & Pwn sfrutta RDP USB redirection, funzione progettata per permettere a una periferica collegata al computer locale di essere resa disponibile all’interno di una sessione remota. Sul server RDP, però, il nodo PnP viene costruito utilizzando i descrittori inviati dal client.

I ricercatori mostrano che non deve necessariamente esistere un dispositivo reale dall’altra parte: un client RDP modificato può semplicemente dichiarare l’hardware che vuole presentare. La funzione è controllata da Group Policy e non risulta quindi universalmente sfruttabile: la redirection PnP deve essere abilitata, situazione plausibile soprattutto in ambienti VDI che la utilizzano deliberatamente. Quando il gate è aperto, però, un normale utente dotato di accesso RDP può aprire il canale URBDRC, inviare il messaggio ADD_DEVICE e creare sul server una periferica fantasma con VID e PID arbitrari. Windows procede quindi esattamente come se l’hardware fosse realmente collegato.

Intel RealSense porta da un account RDP standard a SYSTEM

Per dimostrare la tecnica remota, Hernando e Martínez utilizzano l’identità di una videocamera Intel RealSense. Windows scarica da Windows Update il relativo driver firmato Microsoft e durante l’installazione il co-installer deposita un eseguibile in una directory scrivibile dall’utente. Quel programma cerca una DLL nella propria cartella prima di controllare System32, creando una classica condizione di DLL hijacking. L’utente standard colloca quindi una CRYPTBASE.dll malevola in C:\Intel\RSDCM e innesca da remoto l’installazione della periferica fantasma. Il processo privilegiato carica la DLL dalla directory controllabile e il PoC dimostra l’esecuzione SYSTEM senza collegare alcun dispositivo al server. Il requisito resta importante: serve già un account autorizzato a collegarsi via RDP e l’ambiente deve consentire la redirection USB/PnP. Non è quindi una RCE pre-authentication su qualsiasi Windows esposto. È invece una local privilege escalation resa remotamente attivabile in VDI e server configurati per accettare quel tipo di periferica, scenario particolarmente rilevante per ambienti nei quali RDP è già parte dell’operatività quotidiana.

PNP simulate mostra cosa accade dentro il percorso privilegiato

Per analizzare sistematicamente questa superficie i ricercatori hanno creato PNP simulate, strumento che riproduce da user mode la parte rilevante del processo di installazione senza richiedere continuamente hardware emulato. Il programma crea un device info set, assegna gli hardware ID USB, registra il dispositivo attraverso le Setup DI API, interroga Windows Update e ascolta le notifiche Plug and Play. In modalità normale effettua soltanto discovery e rimuove successivamente il devnode; con il flag di installazione richiama CM_Setup_DevNode con CM_SETUP_DEVNODE_READY, entrando nel reale processo asincrono gestito da PnP e dal Device Installation Service SYSTEM. L’analisi con WinDbg ha permesso ai ricercatori di distinguere i pacchetti semplicemente presenti nel catalogo da quelli che Windows risolve e installa realmente in automatico. La distinzione evita una conclusione eccessiva: Windows Update contiene numerosi driver vecchi o manuali, ma soltanto una parte è raggiungibile attraverso il percorso automatico sfruttato dalla ricerca.

Wacom contiene un percorso che apre una shell interattiva SYSTEM

La ricerca individua anche primitive sfruttabili in modo compositivo senza la catena Sierra-Sony. Nel servizio Wacom WTabletServiceISD, eseguito come LocalSystem, i ricercatori hanno trovato un controllo su un valore binario del registro denominato PowerT. Quando contiene una specifica sequenza e AutoAdminLogon soddisfa le condizioni previste, il servizio raggiunge CreateProcessAsUserW e avvia CMD come SYSTEM sul desktop interattivo dell’utente. Gli autori evitano esplicitamente di definirlo una backdoor perché il codice potrebbe essere un residuo di debug, una funzione di supporto o altro comportamento interno mai progettato come superficie pubblica. Il problema, dal punto di vista offensivo, è comunque evidente: un utente standard non può normalmente scrivere nella chiave HKLM necessaria, ma il requisito può essere soddisfatto concatenando un secondo componente vulnerabile.

Un vecchio bug Atheros è ancora raggiungibile attraverso PnP

Quel secondo componente viene trovato in un pacchetto Atheros legato a una vulnerabilità del 2019. I ricercatori si aspettavano che il certificato o il pacchetto non fossero più utilizzabili, ma il software risultava ancora installabile attraverso il percorso PnP analizzato. Il servizio AtherosSVC, eseguito come LocalSystem, legge un file INI collocato in C:\ProgramData\Atheros e, dopo uno specifico service control code, esegue operazioni privilegiate sul registro basandosi sui parametri contenuti nel file controllabile dall’utente.

Non è possibile utilizzarlo direttamente per impostare i byte richiesti da Wacom, quindi i ricercatori aggiungono un ulteriore passaggio: Atheros crea nel registro un Print Monitor che punta a una DLL collocata in ProgramData. Al riavvio, lo Spooler SYSTEM carica quella DLL; il codice può finalmente scrivere correttamente PowerT e riavviare il servizio Wacom, che apre la shell SYSTEM. È una catena quasi interamente composta da funzionalità legittime, permessi troppo ampi e un bug già vecchio di anni.

Un driver firmato non equivale a un componente logicamente sicuro

Il punto centrale di Plug and Pwn è la differenza tra fiducia crittografica e sicurezza logica. Windows può verificare correttamente una firma, stabilire che un pacchetto provenga dal vendor previsto e distribuirlo attraverso Windows Update, senza che questo dimostri che ogni co-installer, servizio, flag di debug o parser al suo interno sia privo di comportamenti sfruttabili. I ricercatori mostrano inoltre che alcune primitive non vengono necessariamente considerate vulnerabilità gravi dai rispettivi produttori: considerate isolatamente possono richiedere condizioni difficili da raggiungere. PnP modifica proprio quelle condizioni, perché può portare automaticamente il componente vulnerabile sulla macchina e avviarlo nel contesto privilegiato previsto dal vendor. È un problema concettualmente vicino alle catene exploit dove più debolezze moderate producono un risultato critico, dinamica già visibile nelle vulnerabilità Windows che permettono escalation fino a SYSTEM e nelle più generali catene CVE, exploit e privilege escalation.

La superficie più delicata riguarda VDI e USB redirection

Per un’azienda, la variante più interessante non è necessariamente quella che richiede un dispositivo FaceDancer fisicamente vicino al PC. La dimostrazione RDP mostra che ambienti VDI, terminal server e workstation remote con USB redirection abilitata possono permettere a un normale utente di raggiungere il processo PnP senza hardware. Il sito della ricerca chiarisce che la funzione è protetta da una policy specifica e che non tutte le configurazioni la consentono; proprio per questo la mitigazione più immediata consiste nel verificare se Plug and Play device redirection sia realmente necessaria e disabilitarla quando non lo è. Negli ambienti nei quali RDP è un componente critico, la riduzione delle funzioni accessibili alla sessione standard diventa parte della segmentazione dei privilegi, principio importante anche negli attacchi in cui gruppi APT modificano le configurazioni RDP per mantenere movimento laterale e riutilizzare credenziali.

Plug and Pwn trasforma il catalogo driver in una superficie da riesaminare

Hernando e Martínez hanno pubblicato anche gli strumenti utilizzati nella ricerca, compresi lo script FaceDancer per emulare le periferiche, un client RDP Python capace di forgiare dispositivi USB, il sorgente di PNP simulate e i PoC dedicati a Wacom. Il valore difensivo del lavoro sta però soprattutto nella domanda che apre: quanti pacchetti legacy ancora risolvibili automaticamente da Windows contengono primitive privilegiate che non sono mai state analizzate pensando a un attaccante capace di scegliere arbitrariamente l’hardware ID? La ricerca non fornisce una risposta quantitativa e non dimostra che l’intero catalogo Windows Update sia vulnerabile. Dimostra però che il modello PnP consente di comporre bug di vendor differenti in modi che la valutazione isolata del singolo driver può non prevedere. Per Windows il problema non è quindi semplicemente “una USB malevola”, ma un confine di fiducia molto più ampio: l’identità dichiarata dalla periferica decide quale codice privilegiato viene portato sul sistema, e una periferica può essere persino soltanto una descrizione inviata attraverso una sessione RDP.