Una tecnica di privilege escalation chiamata PhantomRPC sta attirando attenzione perché sfrutta un meccanismo centrale di Windows che pochi osservano davvero: la comunicazione tra processi tramite RPC (Remote Procedure Call). Non si tratta di un bug classico: quello scoperto dai ricercatori di Kaspersky nei giorni scorsi è più sottile e, proprio per questo, interessante. Un servizio locale già compromesso può sfruttare il modo in cui Windows gestisce le chiamate RPC per ottenere privilegi SYSTEM, cioè il livello più alto disponibile su una macchina.
RPC esiste in Windows da decenni ed è alla base di moltissime interazioni interne tra componenti del sistema operativo: ogni volta che un servizio, un’applicazione o una utility di sistema devono chiedere qualcosa a un altro processo, c’è una buona probabilità che sotto il cofano venga usato proprio RPC. Il risultato è un’enorme superficie di attacco distribuita in tutto il sistema, spesso invisibile anche a chi lavora quotidianamente con Windows.
La ricerca pubblicata da Kaspersky mostra che questo meccanismo può essere sfruttato in modo affidabile per scalare privilegi. I test sono stati condotti su Windows Server 2022 e Windows Server 2025 aggiornati, ma il comportamento osservato suggerisce che il problema non sia limitato alle singole versioni di Windows ma sia molto più esteso.
Cos’è RPC, spiegato senza formalismi
Quando due processi Windows comunicano reciprocamente, spesso uno deve chiedere all’altro di eseguire una funzione. RPC è il meccanismo che consente a un processo di chiamare codice presente in un altro processo, come se fosse una funzione locale. Il sistema traduce la richiesta, la invia attraverso un canale apposito e restituisce il risultato.
La cosa interessante è che RPC non è un singolo protocollo: può usare più sistemi di trasporto come rete TCP, named pipe SMB o comunicazione locale tramite ALPC (Advanced Local Procedure Call). Quest’ultimo è molto usato all’interno della stessa macchina perché è veloce ed efficiente: quando un’applicazione o un servizio chiama una certa API, sotto il cofano può partire una richiesta RPC verso un servizio di sistema.
Il processo client prepara una richiesta con alcune informazioni chiave: un identificatore di interfaccia, chiamato UUID, un endpoint (una sorta di indirizzo) e un numero che identifica la funzione da eseguire. Il server RPC espone quell’interfaccia e resta in ascolto; quando riceve la richiesta, esegue la funzione e restituisce il risultato. Fin qui, nulla di sorprendente.
Il dettaglio importante è un altro: il server può temporaneamente assumere l’identità del client grazie all’impersonificazione. Se il client lo consente e il server ha il privilegio giusto, può agire come il client: quel privilegio si chiama SeImpersonatePrivilege.
La falla PhantomRPC, in pratica
PhantomRPC non sfrutta un bug classico: non c’è buffer overflow, non c’è corruzione della memoria. Come anticipato in apertura, il problema è più articolato: Windows non verifica in modo robusto che il server RPC con cui il client si collega sia davvero quello legittimo.
Se il server RPC vero non è disponibile, un processo malevolo può crearne uno falso con lo stesso UUID e lo stesso endpoint. A quel punto, quando il client tenta la connessione, finisce per parlare con l’attaccante. Se la chiamata RPC usa un livello di impersonificazione alto, il server falso può assumere l’identità del client.
Tradotto: un servizio compromesso può diventare SYSTEM e acquisire così il ventaglio di privilegi in assoluto più elevato sul sistema in uso.
Un esempio concreto: gpupdate e Desktop remoto
Uno degli esempi più illuminanti riguarda il comando gpupdate che, com’è noto, permette di aggiornare le policy di gruppo impostate dall’amministratore in Windows.
Quando un amministratore esegue gpupdate /force, il servizio Group Policy, che opera con privilegi elevati come account SYSTEM prova a comunicare tramite RPC con il servizio Desktop remoto. Se quest’ultimo non risulta in esecuzione, la comunicazione fallisce come previsto.
Tuttavia, un attaccante può intervenire prima: avvia un server RPC malevolo che si finge il servizio Desktop remoto legittimo. A quel punto accade qualcosa di critico: il servizio di sistema si connette al server controllato dall’attaccante, che riesce così a assumere l’identità di SYSTEM, ottenendo privilegi massimi sul sistema. L’escalation dei privilegi è quindi completata. Il problema è che, dal punto di vista del sistema operativo, il comportamento è corretto: non è progettato per riconoscere un servizio contraffatto in questo scenario.
Per questo motivo Microsoft ha classificato il problema alla base di PhantomRPC come di gravità “moderata”. Dal punto di vista formale ha senso: serve già un certo livello di accesso e il privilegio di impersonificazione.
Dal punto di vista operativo, però, la valutazione cambia. In molte intrusioni reali, ottenere accesso a Network Service o Local Service è cosa relativamente comune. Non assegnare un CVE e non pensare a una patch perché è un comportamento by design, forse, è un po’ troppo.
Altri scenari: Edge, servizi di sistema e utility
La ricerca mostra diversi ulteriori casi interessanti. Microsoft Edge, all’avvio, può generare chiamate RPC verso servizi non attivi: se un amministratore apre il browser, l’attaccante può intercettare quella chiamata.
Ancora più interessante il servizio diagnostico di Windows, che gira come SYSTEM e invia richieste RPC periodiche senza alcuna interazione. In pratica, per l’aggressore basta aspettare affinché un attacco che porti all’acquisizione dei massimi privilegi vada effettivamente in porto.
Ci sono poi utilità come ipconfig o w32tm che tentano connessioni RPC a endpoint prevedibili o addirittura inesistenti: se un malintenzionato interviene con le tempistiche giuste, il gioco è fatto.
I ricercatori di Kaspersky hanno sviluppato proof of concept funzionanti: non hanno pubblicato exploit completi pronti all’uso, ma il materiale disponibile è sufficiente per chi ha competenze offensive per replicare la tecnica.
E, a nostro avviso, PhantomRPC è veramente molto interessante per chi studia la sicurezza: non rompe le regole del sistema, le usa esattamente per come sono state progettate.