Scoperti due zero-day critici in Windows 11: così aggirano BitLocker e ottengono privilegi SYSTEM

Continua il braccio di ferro tra un ricercatore di sicurezza noto con lo pseudonimo Nightmare-Eclipse e Microsoft. Dopo le vulnerabilità BlueHammer e RedSun, lo stesso esperto se ne esce con altri due zero-day, battezzati YellowKey e GreenPlasma: sono problemi di sicurezza gravi con il primo che punta a bypassare BitLocker sfruttando componenti presenti nell’ambiente di recupero di Windows; il secondo descrive una tecnica di Local Privilege Escalation capace di ottenere privilegi SYSTEM su Windows 11 e Windows Server.

È palese che Nightmare-Eclipse abbia il dente avvelenato con Microsoft: le sue pubblicazioni su nuovi zero-day arrivano infatti, puntualmente, dopo il Patch Tuesday mensile dell’azienda di Redmond, giorno deputato al rilascio delle correzioni di sicurezza per tutti i sistemi supportati.

Il ricercatore ce l’ha, a suo dire, con le modalità con cui il Microsoft Security Response Center avrebbe in passato gestito le sue segnalazioni. Si è infatti più volte dichiarato “frustrato” dal processo di coordinated disclosure adottato da Microsoft. Da quello che emerge, il nodo principale riguarda tempi di risposta, classificazione della gravità e gestione delle patch: il ricercatore sostiene che alcune vulnerabilità legate a Microsoft Defender e WinRE siano state sottovalutate oppure trattate troppo lentamente.

La reazione è stata piuttosto aggressiva: pubblicazione pubblica dei proof-of-concept completi, spesso accompagnati da commenti polemici verso Microsoft e verso il modello di disclosure tradizionale.

YellowKey e il bypass di BitLocker attraverso WinRE

Secondo le informazioni condivise dal ricercatore, la falla YellowKey colpisce Windows 11 e Windows Server 2022/2025 sfruttando componenti caricati nel Windows Recovery Environment. L’exploit consentirebbe di ottenere pieno accesso a un volume protetto con BitLocker attraverso una procedura che richiede accesso fisico alla macchina e l’uso di un supporto USB.

La parte più controversa riguarda proprio il componente coinvolto. L’autore sostiene che il modulo responsabile del comportamento anomalo esista solo all’interno dell’immagine WinRE e che la stessa libreria, presente nel sistema operativo, non includa le funzioni che permettono il bypass. Da qui nascono le accuse, decisamente speculative, sull’ipotesi di una possibile backdoor intenzionale.

Va detto però che parlare di backdoor senza prove concrete rischia di spostare il dibattito fuori dal seminato. Windows include numerosi componenti legacy e moduli interni pensati per scenari OEM, recovery e diagnostica offline: non è raro trovare codice differente tra WinRE e ambiente standard. La presenza di funzionalità aggiuntive non implica automaticamente un meccanismo deliberato di bypass.

Dal punto di vista tecnico, il problema sembra collegato alla gestione delle chiavi di sblocco e alla fiducia concessa ai componenti di recovery durante la fase di boot. BitLocker basa buona parte della sicurezza sull’integrità verificata tramite TPM e PCR. Se un attaccante riesce a manipolare il percorso di avvio o a caricare componenti considerati attendibili dal boot chain, può arrivare a estrarre o utilizzare materiale crittografico senza conoscere direttamente la chiave di ripristino di BitLocker.

Una situazione simile si era già vista con le vulnerabilità WinRE corrette da Microsoft nel 2022 e nel 2023: in quel caso gli aggiornamenti richiedevano modifiche manuali alla partizione recovery e molti amministratori non completarono mai il processo di mitigazione. Ancora oggi esistono sistemi aziendali con immagini WinRE obsolete.

Perché il ricercatore dice di copiare la cartella FsTx nella chiavetta e come avviene la “rottura” di BitLocker

Il bypass di BitLocker si concretizza semplicemente copiando una cartella (FsTx) fornita dal ricercatore in un supporto USB avviabile quindi riavviando il sistema in modalità WinRE (avvio di emergenza). Lo si può fare, ad esempio, tenendo premuto il tasto MAIUSC mentre si chiede – dalla schermata di login – di effettuare il reboot della macchina.

Il motivo per cui il ricercatore dice di copiare FsTx dentro ChiavettaUSB:\System Volume Information è importante: quella directory è il punto in cui Windows conserva metadati protetti del volume, inclusi dati di ripristino, shadow copy, indicizzazione e altri database interni. Su NTFS è una cartella speciale, nascosta e normalmente accessibile solo a SYSTEM; sui supporti rimovibili o su partizioni accessibili offline, però, un attaccante può prepararla manualmente.

Come funziona l’attacco

La tesi tecnica è quindi questa: WinRE, durante l’avvio dell’ambiente di recupero, esamina o inizializza alcune strutture presenti in System Volume Information. Se trova la struttura FsTx nel formato atteso, la tratta come materiale legittimo del volume. Il bug sarebbe nel modo in cui quel componente WinRE gestisce i log transazionali: invece di considerarli non fidati, Windows li processa subito e con privilegi sufficienti da arrivare all’apertura di una shell con accesso al volume protetto. Il README del progetto afferma proprio che, dopo aver preparato la cartella e avviato WinRE, compare una shell con accesso al volume BitLocker.

La cosa davvero grave è che BitLocker non verrebbe “rotto” crittograficamente: non si parla di AES-XTS compromesso o di chiave di ripristino ricalcolata.

Il bypass sfrutterebbe un percorso fiduciario dell’ambiente di ripristino: WinRE monta o accede al volume in una fase in cui alcuni componenti locali hanno un ventaglio di privilegi particolarmente ampio. È il classico caso in cui la crittografia resta solida, ma l’integrazione con boot, recovery e gestione del volume apre una “porta sul retro”.

Dopo aver rilasciato il tasto MAIUSC all’avvio, il ricercatore specifica di premere CTRL in modo da far apparire un accesso da terminale che “dribbla” la protezione di BitLocker.

Perché il PIN pre-avvio può fermare YellowKey

La tecnica descritta nel repository GitHub di YellowKey sembra colpire soprattutto i sistemi configurati con BitLocker in modalità TPM-only, cioè senza autenticazione aggiuntiva all’avvio. In questa configurazione il chip TPM rilascia automaticamente il materiale crittografico necessario allo sblocco del volume durante la sequenza di boot, purché firmware, Secure Boot e catena di avvio corrispondano ai valori attesi. È proprio questa automazione a creare una superficie d’attacco interessante per strumenti che prendono di mira WinRE e i componenti recovery di Windows.

La situazione cambia sensibilmente quando BitLocker utilizza la modalità TPM+PIN. In quel caso il TPM non libera la chiave di sblocco senza l’inserimento manuale del PIN pre-boot da parte dell’utente.

Anche se un attaccante riuscisse a manipolare l’ambiente di recupero oppure a caricare componenti WinRE vulnerabili, il volume rimarrebbe cifrato in assenza del fattore di autenticazione aggiuntivo.

Per questo, come osservato nel nostro articolo sull’uso di BitLocker in modalità sicura, suggeriamo sempre di attivare la protezione con PIN da digitare all’avvio del sistema.

Va detto però che il PIN pre-avvio non elimina ogni possibile scenario offensivo: se il dispositivo risulta già acceso, ibernato oppure in stato sleep, parte delle chiavi può trovarsi ancora nella memoria RAM. Entrano allora in gioco tecniche molto più sofisticate, come cold boot attack o acquisizione DMA: si tratta però di attacchi diversi rispetto alla logica mostrata da YellowKey.

GreenPlasma e l’acquisizione dei diritti SYSTEM in Windows

Il secondo progetto pubblicato, GreenPlasma, descrive una vulnerabilità di acquisizione dei privilegi legata a CTFMON, che consente la creazione arbitraria di section object, ovvero aree di memoria condivisa gestite dal sistema, all’interno di directory object considerati affidabili da Windows.

Secondo la descrizione tecnica di Nightmare-Eclipse, il bug permetterebbe a un utente locale con privilegi limitati di creare oggetti condivisi in percorsi normalmente considerati attendibili da servizi Windows e dal driver kernel. Molti componenti, infatti, assumono che alcune namespace interne possano essere scritte soltanto da processi privilegiati.

Il ricercatore sostiene che diversi servizi effettuino controlli insufficienti sui section object presenti in directory accessibili: un processo senza alcun privilegio particolare riuscirebbe a influenzare strutture utilizzate da codice in esecuzione con i diritti SYSTEM. Da lì l’elevazione privilegi diventa possibile.

Al momento il repository GitHub descrive il comportamento vulnerabile e fornisce elementi sufficienti per riprodurre il problema, ma non un framework automatizzato pronto all’uso. La differenza è importante: un PoC tecnico richiede competenze elevate per essere integrato in catene offensive reali.

Perché il ricercatore ha pubblicato YellowKey e GreenPlasma dopo il Patch Tuesday di maggio?

La scelta di pubblicare i nuovi zero-day immediatamente dopo il Patch Tuesday Microsoft non sembra casuale:

• Microsoft ha appena chiuso il ciclo mensile di aggiornamenti: eventuali nuove falle rischiano quindi di restare esposte per settimane prima della patch successiva.
• I team difensivi abbassano temporaneamente il livello di attenzione dopo aver distribuito gli aggiornamenti del mese.
• L’impatto mediatico aumenta molto: la narrativa diventa “Microsoft ha appena corretto una falla ma ce ne sono già altre”.
• I ricercatori indipendenti che non vogliono rispettare le modalità di segnalazione responsabile delle vulnerabilità cercano pressione pubblica immediata sul vendor.

Il comportamento manifestato da Nightmare-Eclipse sembra poi andare oltre la classica “full disclosure“: diversi analisti hanno notato che i tool pubblicati formano quasi una catena offensiva: BlueHammer e RedSun permettono escalation a SYSTEM, mentre UnDefend punta a neutralizzare Microsoft Defender. Adesso YellowKey e GreenPlasma estendono il campo minato a BitLocker e ampliano la superficie di acquisizione di privilegi.