PhantomRPC: la falla RPC di Windows che Microsoft non correggerà

Ogni versione di Windows in circolazione - dai server aziendali ai desktop domestici - ospita una vulnerabilità nel sottosistema RPC che consente a un attaccante con un appiglio minimo di scalare i privilegi fino a SYSTEM. Si chiama PhantomRPC, è stata presentata alla conferenza Black Hat Asia il 24 aprile 2026 dal ricercatore di Kaspersky Haidar Kabibo, e Microsoft ha deciso di non correggerla. Nessuna patch, nessun CVE, caso chiuso.

Un difetto di architettura, non un semplice bug

PhantomRPC non è una corruzione di memoria né un errore logico in un singolo componente. Il problema sta nel modo in cui il runtime RPC di Windows - la libreria rpcrt4.dll - gestisce le connessioni verso server RPC non disponibili. Quando un servizio legittimo è spento o disabilitato, Windows permette a chiunque di registrare un server RPC sullo stesso endpoint senza alcuna verifica di autenticità. Se un processo con privilegi elevati tenta una chiamata verso quel servizio assente, finisce dritto nelle mani del server fasullo.

Il meccanismo cardine è l'API RpcImpersonateClient: il server fittizio la invoca per assumere il contesto di sicurezza del client privilegiato appena connesso. In termini pratici, un attaccante che controlla un processo con il privilegio SeImpersonatePrivilege - assegnato per impostazione predefinita agli account Network Service e Local Service - può impersonare un processo SYSTEM o Administrator. Il salto è da un account di servizio a bassa priorità al controllo totale della macchina.

Come ha scritto Kabibo nella documentazione tecnica pubblicata su Securelist: «Questo comportamento consente a qualsiasi processo di distribuire un server RPC che imita un servizio legittimo e ricevere tutte le chiamate RPC originariamente destinate al server autentico». Una frase che suona come una descrizione di progetto, non come un bollettino di sicurezza.

Cinque percorsi concreti di escalation

La ricerca documenta cinque vettori di attacco distinti. Nessuno è teorico: tutti sono stati dimostrati con prove di concetto pubblicamente disponibili.

1. gpupdate.exe - Eseguendo gpupdate /force, il servizio Group Policy Client (in esecuzione come SYSTEM) effettua una chiamata RPC verso TermService. Se quest'ultimo è disabilitato e un server fasullo ne occupa l'endpoint, l'attaccante intercetta la chiamata e ottiene accesso SYSTEM.
2. Microsoft Edge - L'avvio di msedge.exe genera una chiamata RPC verso TermService con un livello di impersonificazione elevato. L'escalation da Network Service ad Administrator avviene senza bisogno di alcuna coercizione esterna.
3. Servizio WDI - Il Diagnostic System Host (WdiSystemHost), in esecuzione come SYSTEM, interroga TermService ogni 5-15 minuti in modo automatico. Nessuna interazione dell'utente richiesta: l'attaccante si siede e aspetta.
4. ipconfig.exe e DHCP Client - L'esecuzione di ipconfig.exe innesca una chiamata RPC interna verso il servizio DHCP Client. Con il servizio DHCP disabilitato, un attaccante con privilegi Local Service scala ad Administrator.
5. w32tm.exe e Windows Time - L'eseguibile del servizio orario tenta per prima cosa di connettersi a una named pipe inesistente (\PIPE\W32TIME). Un attaccante può esporre questo endpoint senza disabilitare il servizio legittimo W32Time, impersonando qualsiasi utente privilegiato che esegua il binario.

Tre di questi percorsi - Edge, WDI e w32tm.exe - non richiedono che l'attaccante forzi alcuna azione da parte dell'utente o dell'amministratore. È sufficiente che il sistema funzioni normalmente.

Superficie d'attacco illimitata per definizione

L'aspetto più insidioso di PhantomRPC è proprio la sua natura "architetturale". Ogni nuovo processo, servizio o applicazione che dipende da RPC potrebbe introdurre un ulteriore percorso di escalation. I cinque vettori documentati sono quelli identificati da Kabibo, ma il numero potenziale è aperto. «Questa variabilità rende la vulnerabilità particolarmente importante per le aziende quando valutano la propria esposizione e le strategie di mitigazione», ha scritto il ricercatore.

I percorsi specifici variano da sistema a sistema in base al software installato, alle DLL coinvolte nella comunicazione RPC e alla disponibilità dei server RPC corrispondenti. C'è anche un paradosso concreto: un ambiente con servizi disabilitati per ragioni di hardening - pratica comune e raccomandata - potrebbe ampliare la superficie d'attacco anziché ridurla.

Kabibo ha specificato che PhantomRPC opera secondo un meccanismo fondamentalmente diverso rispetto alla nota famiglia di exploit Potato (RottenPotato, JuicyPotato, SweetPotato e varianti), pur condividendo il territorio dell'escalation dei privilegi locali tramite impersonificazione.

La risposta di Microsoft: severità moderata, niente patch

Kabibo ha segnalato la vulnerabilità al Microsoft Security Response Center il 19 settembre 2025, allegando un rapporto tecnico di dieci pagine. La risposta è arrivata venti giorni dopo. Microsoft ha classificato il problema come di severità moderata, argomentando che lo sfruttamento richiede SeImpersonatePrivilege - un privilegio che gli account di servizio possiedono già per impostazione predefinita.

La logica è circolare. Il privilegio SeImpersonatePrivilege è concesso a Network Service e Local Service perché questi account devono poter impersonare i client nell'ambito delle loro funzioni legittime. PhantomRPC trasforma quel privilegio di routine in un trampolino verso SYSTEM. Sostenere che l'escalation non sia grave perché il prerequisito è un privilegio comune equivale a dire che una serratura difettosa non è un problema perché la chiave è facile da trovare.

Risultato: nessun CVE assegnato, nessuna idoneità al programma di bug bounty. «Il caso è stato chiuso senza ulteriore tracciamento», ha scritto Kabibo.

Cosa si può fare (per ora)

In assenza di una correzione da parte di Microsoft, Kaspersky suggerisce tre strategie di mitigazione:

• Monitoraggio basato su ETW (Event Tracing for Windows) per identificare eccezioni RPC, in particolare i casi in cui i client tentano di connettersi a server non disponibili. È un approccio di rilevamento, non di prevenzione, ma consente almeno di individuare tentativi di sfruttamento.
• Abilitare i servizi legittimi corrispondenti agli endpoint RPC vulnerabili. Se TermService o DHCP Client sono attivi e rispondono, un server fasullo non può occuparne l'endpoint. Una contromisura efficace, ma che va bilanciata con le esigenze di hardening.
• Limitare la concessione di SeImpersonatePrivilege ai soli processi che ne hanno effettiva necessità. Assegnarlo a processi personalizzati o di terze parti è descritto come una pratica di sicurezza generalmente inadeguata.

Il quadro più ampio

Il sottosistema RPC di Windows è uno dei componenti più complessi dell'intero sistema operativo, e storicamente una fonte ricorrente di guai: vulnerabilità che hanno spaziato dall'escalation locale dei privilegi fino all'esecuzione di codice da remoto. PhantomRPC si inserisce in questa tradizione, ma con una caratteristica che la rende particolarmente scomoda: non è un bug da correggere con una patch puntuale, è un comportamento strutturale del runtime RPC.

Per chi opera in ambito red team o nella sicurezza offensiva, PhantomRPC è uno strumento post-exploitation di notevole versatilità. Per chi difende infrastrutture Windows - ovvero praticamente chiunque gestisca sistemi in ambienti aziendali - è un rischio concreto e attualmente privo di rimedio definitivo. La decisione di Microsoft di non emettere nemmeno un CVE complica ulteriormente le cose: senza un identificatore ufficiale, PhantomRPC rischia di scivolare tra le maglie dei programmi di vulnerability management aziendali, invisibile ai processi formali di gestione del rischio.

Le prove di concetto sono già in un repository pubblico, disponibili a chiunque sappia dove cercare. La finestra tra divulgazione e mitigazione è aperta, e al momento non sembra che qualcuno abbia fretta di chiuderla.

Fonti: securelist.com, cybersecuritynews.com, kaspersky.com