Rapporto di Convalida Proof of Concept RoguePlanet per Microsoft Defender

Scopo e ambito del rapporto

Questo rapporto riguarda la convalida del Proof of Concept RoguePlanet descritto pubblicamente e relativo a Microsoft Defender. La tecnica descritta è stata presentata dai media il 10 giugno 2026 come una escalation di privilegi locale (LPE), in cui un utente locale può ottenere privilegi NT AUTHORITY\SYSTEM. Le descrizioni pubbliche indicavano che il meccanismo utilizza funzioni impiegate da Microsoft Defender durante la gestione o la scansione di un file.

Lo scopo del test era determinare se l'exploit potesse essere preparato ed eseguito in un ambiente di laboratorio controllato, e osservare come i meccanismi di protezione di Microsoft Defender si comportano su un sistema Windows 11 aggiornato. Il rapporto copre l'ambiente di test, lo stato degli aggiornamenti, la configurazione di Microsoft Defender, la preparazione dell'ambiente di compilazione, il risultato della compilazione, la risposta di Defender e le raccomandazioni per la riduzione del rischio.

Il test è stato orientato alla ricerca ed è stato eseguito localmente su una workstation di test dedicata. I risultati devono essere interpretati come una valutazione del comportamento di un artefatto specifico e di una configurazione ambientale specifica, non come una piena conferma della resistenza a tutte le possibili varianti di questa tecnica.

Fonti citate nel materiale analizzato:

• Articolo:

  https://thehackernews.com/2026/06/microsoft-defender-rogueplanet-zero-day.html

• Repository PoC pubblico:

  https://github.com/MSNightmare/RoguePlanet/tree/main

• Fonte dell'installer MSYS2:

  https://github.com/msys2/msys2-installer/releases/tag/nightly-x86_64

• Fonte di Visual Studio:

  https://visualstudio.microsoft.com/insiders/?rwnlp=pl

Ambiente di test

Il PoC è stato eseguito su una workstation client operante al di fuori di un dominio Active Directory, nel gruppo di lavoro WORKGROUP. Il sistema operativo installato sulla workstation era Microsoft Windows 11 Home, versione 25H2, architettura a 64 bit.

Il giorno in cui è stato eseguito il PoC, il sistema aveva installato gli aggiornamenti di sicurezza di giugno 2026, nonché aggiornamenti precedenti di maggio e aprile 2026. Ciò significa che il test è stato eseguito su un sistema Windows 11 25H2 aggiornato, build 26200, dopo l'installazione delle ultime patch di sicurezza disponibili alla data del test.

Configurazione di Microsoft Defender

Microsoft Defender Antivirus era attivo sulla workstation utilizzata per il test ed era in esecuzione in modalità normale. Il servizio di protezione era in esecuzione e abilitato, e la protezione antivirus, antispyware, il monitoraggio del comportamento e la protezione in tempo reale erano attivi.

Il giorno del test, le firme di Microsoft Defender erano aggiornate. Le firme antivirus, antispyware e NIS erano state aggiornate il 10.06.2026 alle 13:27:32.

L'ultima scansione rapida è stata eseguita il 08.06.2026 tra le 15:00:36 e le 15:01:58, utilizzando la versione delle firme 1.451.323.0. Una scansione completa non era stata eseguita in precedenza o la sua cronologia non era disponibile, come indicato dal valore FullScanAge di 4294967295 e dall'assenza di orari di inizio e fine della scansione completa.

Preparazione dell'ambiente di compilazione

Il primo tentativo di compilare il codice dal repository GitHub si è concluso con un errore causato dalla mancanza dell'header winternl.h. Il messaggio indicava che il sistema non disponeva del set completo di intestazioni Windows SDK richieste dal codice analizzato.

Figura 1. Errore di header winternl.h mancante durante il primo tentativo di compilazione.

Il codice faceva riferimento anche ad altri header relativi all'API Windows e all'API NT, tra cui windows.h, Psapi.h, ntstatus.h, virtdisk.h, shlwapi.h, taskschd.h e bcrypt.h. Per questo motivo, è stato necessario preparare un ambiente di compilazione più completo e installare i componenti SDK appropriati.

Figura 2. Frammento dell'elenco degli header richiesti dal codice analizzato.

Tentativo di utilizzo di MSYS2/MinGW-w64

Inizialmente, MSYS2/MinGW-w64 è stato utilizzato per preparare l'ambiente di compilazione. Questo ambiente fornisce strumenti GNU per Windows, inclusi i compilatori gcc e g++. I pacchetti in MSYS2 sono gestiti tramite pacman, che svolge un ruolo simile ad apt sui sistemi Linux o a winget su Windows.

Figura 3. Completamento dell'installazione di MSYS2.

Usando pacman, è stata installata la toolchain MinGW-w64 GCC/G++, ovvero un insieme di strumenti che consente la compilazione di codice C/C++ per Windows. Il pacchetto include, tra gli altri componenti, il compilatore gcc, il compilatore C++ g++, il linker e gli header e le librerie necessari per creare applicazioni eseguibili nell'ambiente Windows. Lo scopo di questo tentativo era verificare se il codice potesse essere compilato utilizzando la toolchain aperta disponibile in MSYS2, senza utilizzare Visual Studio.

Figura 4. Installazione dei pacchetti MSYS2/MinGW-w64 tramite pacman.

Dopo l'installazione, è stato tentato di compilare il codice utilizzando g++. Il comando specificava direttamente il percorso del file sorgente e il percorso del file eseguibile risultante.

C:\msys64\mingw64\bin\g++.exe C:\Users\User\Downloads\RoguePlanet.cpp -o C:\Users\User\Desktop\roguePlanet.exe

Problema della modalità Unicode

Il primo segnale significativo di un problema della modalità Unicode sono stati i messaggi del compilatore riguardanti tipi di carattere incompatibili. I log contenevano errori che indicavano che non era possibile convertire valori di tipo const wchar_t* o wchar_t* in LPCSTR o LPSTR. Ciò significava che il codice stava passando stringhe wide-character alle funzioni API di Windows, mentre il compilatore stava selezionando varianti di funzione destinate alle tradizionali stringhe ANSI.

Nell'API di Windows, molte funzioni esistono in due varianti: ANSI, contrassegnata dal suffisso A, e Unicode, contrassegnata dal suffisso W. Ad esempio, CreateFile può essere mappato come CreateFileA o CreateFileW, e RegOpenKeyEx come RegOpenKeyExA o RegOpenKeyExW. La variante A si aspetta parametri di tipo char* o LPCSTR, mentre la variante W si aspetta parametri di tipo wchar_t* o LPCWSTR.

Nel caso analizzato, il codice utilizzava letterali nella forma L"..." e buffer di tipo wchar_t. Allo stesso tempo, i messaggi di errore indicavano che il compilatore selezionava funzioni come GetModuleHandleA, RegOpenKeyExA, RegQueryValueExA, GetWindowsDirectoryA, CreateFileA e wsprintfA. Questa era un'indicazione diretta che il codice era stato scritto pensando alla modalità Unicode, ma il comando di compilazione non definiva UNICODE e _UNICODE.

La modalità Unicode è stata quindi forzata aggiungendo le definizioni UNICODE e _UNICODE. Dopo questa modifica, le funzioni API di Windows senza suffisso esplicito dovrebbero essere mappate alle varianti con suffisso W, come CreateFileW, RegOpenKeyExW, GetModuleHandleW e GetWindowsDirectoryW. Il fatto che alcuni degli errori siano scomparsi dopo questa modifica ha confermato la correttezza della diagnosi.

C:\msys64\mingw64\bin\g++.exe C:\Users\User\Downloads\RoguePlanet.cpp -o C:\Users\User\Desktop\roguePlanet.exe -DUNICODE -D_UNICODE

Dopo aver risolto i problemi relativi a Unicode, tuttavia, sono rimasti errori che indicavano una compatibilità più profonda tra il codice e MinGW. Riguardavano, tra l'altro, definizioni duplicate delle strutture FILE_BASIC_INFORMATION e FILE_RENAME_INFORMATION, definite sia nel codice sorgente sia negli header di MinGW. Inoltre, la versione di FILE_RENAME_INFORMATION disponibile in MinGW differiva da quella prevista dal codice, inclusa l'assenza del campo Flags.

Ulteriori errori derivavano anche dall'approccio più restrittivo del compilatore g++ ai tipi, specialmente con flag enum e puntatori a funzione. Ciò riguardava, tra gli altri, i tipi VIRTUAL_DISK_ACCESS_MASK e ATTACH_VIRTUAL_DISK_FLAG, nonché il passaggio di puntatori a funzione come void*. Di conseguenza, MinGW è stato ritenuto non adatto alla compilazione di questo codice senza modifiche significative al codice sorgente.

5. Migrazione a MSVC e Windows SDK

A causa di problemi di compatibilità con MinGW, è stato preparato un ambiente MSVC e Windows SDK. Nel programma di installazione di Visual Studio è stato selezionato il carico di lavoro "Sviluppo desktop con C++" perché il codice analizzato era un'applicazione Windows nativa scritta in C/C++ e utilizzava direttamente l'API di Windows e i componenti di Windows SDK. Non si trattava di un progetto .NET, Python, Node.js o di un'applicazione web, quindi i componenti relativi a queste tecnologie non sono stati installati.

Figura 5. Carico di lavoro e componenti di Visual Studio selezionati per applicazioni C++ desktop.

Il componente più importante era MSVC v143, il compilatore Microsoft C/C++ destinato alla creazione di applicazioni C/C++ per Windows. È stato selezionato perché il precedente tentativo di compilazione con MinGW/G++ aveva causato errori di compatibilità relativi a header, tipi e strutture API NT. Il codice utilizzava meccanismi specifici di Windows, quindi l'ambiente più compatibile era il compilatore Microsoft insieme alle librerie fornite dal Windows SDK.

È stato installato anche Windows 11 SDK. Questo componente contiene gli header e le librerie necessari per utilizzare le funzioni di sistema di Windows, tra cui windows.h, winternl.h, winreg.h, processthreadsapi.h, virtdisk.h e le librerie di importazione .lib utilizzate durante il collegamento. Inoltre, gli strumenti CMake per C++ sono stati mantenuti come componente ausiliario, utile durante l'analisi di progetti più complessi.

Dopo l'installazione, è stato utilizzato il prompt dei comandi x64 Native Tools Command Prompt for VS Insiders, una CLI con i percorsi corretti impostati per il compilatore cl.exe, Windows SDK e le librerie del linker.

Figura 6. Avvio del prompt dei comandi x64 Native Tools Command Prompt for VS Insiders.

6. Compilazione con MSVC

Dopo il passaggio a MSVC, il codice ha compiuto progressi significativi nel processo di compilazione. Il primo comando restituiva ancora errori relativi al mapping delle funzioni API di Windows alle varianti ANSI, quindi è stato necessario aggiungere le definizioni UNICODE e _UNICODE anche durante la compilazione con MSVC.

cl /EHsc RoguePlanet.cpp -o rogue.exe

Figura 7. Tentativo di compilazione con MSVC senza piena configurazione Unicode e di collegamento.

Dopo aver aggiunto gli switch Unicode, il codice è stato elaborato ulteriormente e gli errori di compatibilità di header e tipo sono stati sostituiti da errori del linker LNK2019. Ciò significava che il compilatore era già in grado di creare un file oggetto, mentre il linker non aveva ancora ricevuto tutte le librerie di importazione richieste dalle funzioni API di Windows utilizzate.

cl /EHsc /DUNICODE /D_UNICODE RoguePlanet.cpp /Fe:rogue.exe

Figura 8. Errori del linker LNK2019 per le funzioni API di Windows.

Gli errori del linker riguardavano funzioni come CreateProcessAsUserW, OpenProcessToken, AdjustTokenPrivileges, DuplicateTokenEx, GetTokenInformation, LookupPrivilegeValueW, RegOpenKeyExW e RegQueryValueExW. Queste funzioni sono correlate a token di sicurezza, privilegi, avvio di processi in un contesto utente specifico e lettura del registro di sistema. L'header dichiara solo che la funzione esiste, ma il linker deve ricevere la libreria di importazione corretta che indica dove si trovano le implementazioni di tali funzioni.

Per risolvere gli errori del linker, è stata aggiunta la libreria advapi32.lib. Si tratta di una libreria di importazione Windows che fornisce, tra l'altro, funzioni relative a token di sicurezza, privilegi, account utente e registro di sistema. Dopo averla aggiunta alla fase di collegamento, il linker è stato in grado di risolvere i simboli esterni precedentemente non risolti e creare il file eseguibile.

cl /EHsc /DUNICODE /D_UNICODE RoguePlanet.cpp /Fe:rogue.exe /link advapi32.lib

Figura 9. Risultato del comando di compilazione corretto.

Figura 10. Risultato del comando riuscito.

Figura 11. File rogue.exe creato nella directory di lavoro ~\Downloads\\

Risposta di Microsoft Defender e risultato dell'esecuzione

Durante la validazione, il file eseguibile creato è stato immediatamente rilevato da Microsoft Defender come Trojan:Win64/RoguePlanet.DA!MTB con livello di gravità "Grave". Il sistema proponeva le azioni di protezione standard, come lo spostamento del file in quarantena o la sua eliminazione.

Figura 12. Messaggio di Windows che informa che il file è stato bloccato come virus o software potenzialmente indesiderato.

Figura 13. Rilevamento di Microsoft Defender: Trojan:Win64/RoguePlanet.DA!MTB.

Ciò significa che i meccanismi di rilevamento di Defender hanno identificato l'artefatto preparato come dannoso o potenzialmente pericoloso prima che potesse essere eseguito con successo. Dal punto di vista della protezione degli endpoint, questo è un risultato positivo, perché il blocco è avvenuto nella fase del file eseguibile e non solo dopo aver osservato gli effetti dell'esecuzione del programma.

Dopo aver disabilitato temporaneamente la protezione in tempo reale, il file è stato eseguito. L'osservazione del test indica che dopo la seconda esecuzione è stato possibile ottenere una console in esecuzione con privilegi SYSTEM. Questo risultato conferma che la protezione attiva di Defender era importante per bloccare l'artefatto testato.

Figura 14. Esecuzione del programma nell'ambiente di test dopo la disabilitazione della protezione in tempo reale.

Figura 15. Console in esecuzione nel contesto di sistema nell'ambiente di test.

Valutazione del rischio

Il rilevamento di un file specifico da parte di Microsoft Defender non significa che il rischio della vulnerabilità sia stato completamente eliminato. Defender ha rilevato un artefatto PoC noto o simile, mentre una versione modificata del codice, una compilazione diversa, una struttura del file cambiata o un altro caricatore potrebbero comportarsi in modo diverso rispetto al rilevamento basato su firma o euristico. Il risultato del test deve essere considerato come conferma dell'efficacia del livello di protezione attuale contro l'artefatto testato, non come prova che ogni possibile variazione della tecnica verrà bloccata.

Allo stesso tempo, il risultato del test indica che con la protezione in tempo reale attiva e le firme aggiornate, Defender ha bloccato con successo l'artefatto creato. Il rischio di sfruttamento pratico aumenta significativamente quando un utente è in grado di disabilitare la protezione in tempo reale, aggiungere un'esclusione, consentire una minaccia rilevata o modificare localmente la configurazione di protezione.

In pratica, ciò significa che una mitigazione efficace non dovrebbe basarsi esclusivamente sulla presenza di Defender stesso, ma anche sull'imposizione centralizzata della sua configurazione e sul blocco delle modifiche locali apportate dagli utenti.

9. Raccomandazioni

L'imposizione centralizzata della configurazione di Microsoft Defender tramite criteri di sicurezza è fondamentale. Gli utenti locali non dovrebbero essere in grado di disabilitare la protezione in tempo reale, aggiungere esclusioni, consentire minacce rilevate o modificare le impostazioni di protezione. In un modello di questo tipo, l'utente non dovrebbe essere in grado di bypassare il rilevamento in modo indipendente selezionando un'opzione come "Consenti sul dispositivo" o disabilitando temporaneamente la protezione.

• Imporre centralmente la protezione in tempo reale, la protezione basata sul cloud e l'invio automatico di campioni;

• Bloccare agli utenti la gestione delle esclusioni e delle azioni per i rilevamenti;

• Monitorare gli eventi di Defender relativi a rilevamenti, quarantena, tentativi di consentire minacce e modifiche alla configurazione della protezione;

• Trattare il rilevamento Trojan:Win64/RoguePlanet.DA!MTB come un evento di sicurezza che richiede analisi;

• Considerare meccanismi aggiuntivi che limitano l'esecuzione di file eseguibili non autorizzati, come l'allow-listing delle applicazioni, WDAC o AppLocker, in base alle capacità dell'ambiente.

Conclusioni finali

Il test ha confermato che la preparazione dell'artefatto richiedeva un ambiente compatibile con la toolchain nativa di Microsoft. Il tentativo di compilazione con MinGW/G++ ha rivelato problemi di compatibilità con gli header e le strutture dell'API NT, mentre il passaggio a MSVC e Windows SDK ha permesso al processo di raggiungere la fase di collegamento e infine di creare il file eseguibile dopo l'aggiunta della libreria di importazione corretta.

Microsoft Defender in esecuzione in modalità normale, con firme aggiornate e protezione in tempo reale abilitata, ha rilevato il file creato come Trojan:Win64/RoguePlanet.DA!MTB e ne ha bloccato l'esecuzione. Questo è un risultato positivo del test dal punto di vista della protezione degli endpoint.

Allo stesso tempo, la disabilitazione della protezione in tempo reale ha permesso l'esecuzione dell'artefatto e ha portato all'ottenimento di una console con privilegi SYSTEM. La conclusione pratica è chiara: la configurazione di Defender dovrebbe essere imposta centralmente e gli utenti non dovrebbero essere in grado di indebolire localmente la protezione, aggiungere esclusioni o consentire minacce rilevate.