Negli ultimi giorni il nome YellowKey ha iniziato a circolare con insistenza nei forum dedicati alla sicurezza informatica, nei canali Telegram specializzati e tra i ricercatori che seguono l’evoluzione delle tecniche di attacco contro la cifratura dei dischi. Tutto nasce da una serie di post pubblicati dal ricercatore noto come Nightmare-Eclipse, che ha scoperto una vulnerabilità capace di compromettere alcune configurazioni di BitLocker su Windows 11 sfruttando un meccanismo legato all’ambiente di ripristino Microsoft.
Le affermazioni sono pesanti. In alcuni passaggi il ricercatore suggerisce addirittura l’esistenza di una backdoor all’interno del processo di avvio di Windows, o comunque di un comportamento talmente grave da consentire l’accesso a sistemi protetti senza conoscere la chiave di cifratura. Ma è davvero così? Esiste realmente una backdoor deliberatamente in Windows 11? Oppure ci troviamo davanti a un insieme di vulnerabilità, configurazioni deboli e condizioni particolari che, combinate, producono un effetto molto simile a quello di una “porta sul retro”?
Cos’è YellowKey e perché sta facendo discutere
L’exploit YellowKey (per trovarlo, basta digitare yellowkey github su Google Search) è descritto come un metodo per ottenere accesso a unità protette con BitLocker sfruttando una combinazione di procedure di boot alterate, file caricati da USB, sblocco automatico del volume e Windows Recovery Environment (WinRE).
WinRE è l’ambiente di ripristino integrato in Windows che permette di avviare strumenti diagnostici e procedure di recupero quando il sistema operativo non riesce più a partire correttamente. Si tratta di una versione minimale di Windows caricata in fase di boot, separata dall’installazione principale: normalmente si attiva da sé dopo due caricamenti mancati di Windows.
È possibile accedere manualmente a WinRE in vari modi: come già detto, interrompendo per almeno due volte consecutive l’avvio del sistema, premendo il tasto MAIUSC mentre si fa clic sul pulsante Riavvia, effettuando il boot dal supporto d’installazione di Windows 11 o da unità di ripristino USB. Proprio perché WinRE opera a basso livello e può interagire con unità BitLocker già sbloccate in alcune condizioni, è diventato uno degli elementi centrali nelle analisi legate a YellowKey.
Come abbiamo spiegato nei giorni scorsi, il problema nasce dal modo in cui Windows gestisce alcune fasi del recovery boot: in certe condizioni, il volume BitLocker verrebbe montato in uno stato già autenticato, permettendo l’accesso ai dati senza dover conoscere la chiave di ripristino né le credenziali dell’utente.
La parola “backdoor” è corretta?
Dal punto di vista tecnico, definire ciò che YellowKey sfrutta una backdoor appare eccessivo. Una backdoor, in senso stretto, implica generalmente un accesso nascosto intenzionale; una funzione progettata deliberatamente per aggirare i controlli di sicurezza; un meccanismo occulto inserito volontariamente dal produttore.
Nel caso di YellowKey, almeno sulla base delle informazioni pubbliche disponibili, non esistono prove concrete di un accesso nascosto introdotto da Microsoft.
Piuttosto, la situazione sembra riguardare un comportamento architetturale complesso; possibili errori di progettazione; interazioni impreviste tra TPM, WinRE e Secure Boot; gestione discutibile delle trust chain durante alcune procedure di recovery. Il rischio sembra derivare da una combinazione di componenti legittimi che, in certe circostanze, consentono un bypass della protezione offerta da BitLocker.
TPM-only: il vero punto debole
Come osservavamo nel nostro articolo sull’analisi della vulnerabilità YellowKey, le configurazioni BitLocker che utilizzano soltanto la protezione TPM (Trusted Platform Module) sono più vulnerabili agli attacchi fisici.
In modalità TPM-only, infatti, l’utente non inserisce alcun PIN all’avvio; il TPM rilascia automaticamente le chiavi se il sistema appare integro; il boot procede senza autenticazione interattiva. Si tratta però di una configurazione molto diffusa perché l’impostazione predefinita su molti sistemi Windows 11 moderni, soprattutto nei notebook aziendali.
Un attaccante con accesso fisico al sistema della vittima può tentare di manipolare l’ambiente di avvio, sfruttare recovery environment alterati o forzare scenari anomali di boot per convincere il TPM a rilasciare le chiavi.
Quanto è sicuro BitLocker con PIN rispetto all’attacco YellowKey?
Nightmare-Eclipse sostiene di possedere una variante dell’attacco capace di compromettere anche configurazioni BitLocker con TPM+PIN, ma non ha pubblicato un proof-of-concept completo né dettagli tecnici sufficienti per consentire verifiche indipendenti.
Senza codice riproducibile, analisi tecnica completa, dump di memoria, log di boot o una metodologia verificabile, è estremamente complesso confermare la validità delle asserzioni del ricercatore.
L’aggiunta di un PIN pre-boot a BitLocker aumenta significativamente la sicurezza del sistema, proprio perché introduce un fattore che il TPM da solo non può rilasciare automaticamente. Anche se l’unità di memorizzazione locale sulla quale risulta attivo BitLocker fosse fisicamente accessibile, l’attaccante dovrebbe comunque conoscere il PIN corretto prima che le chiavi vengano rese disponibili.
Se davvero esistesse un bypass completo di TPM+PIN, ci troveremmo davanti a un problema molto più grave e potenzialmente storico per l’intero modello di protezione BitLocker: tuttavia, al momento, tale scenario resta non verificato pubblicamente.
Quindi c’è davvero una backdoor in BitLocker di Windows 11?
La risposta più onesta, al momento, è no: non esistono prove pubbliche che dimostrino la presenza di una backdoor intenzionale in Windows 11 o in BitLocker.
Esiste però un problema serio legato alla gestione del boot, all’integrazione con WinRE e e alle configurazioni di BitLocker TPM-only. YellowKey mostra quanto possa diventare fragile un modello di sicurezza quando l’intera catena di trust dipende da componenti estremamente complessi e interconnessi.
Il punto cruciale dell’intera vicenda non è quindi tanto l’idea di una backdoor, quanto la possibilità che la complessità stessa delle piattaforme moderne finisca per creare comportamenti equivalenti a una “porta sul retro”, pur senza esserlo formalmente.
In un post del 14 maggio 2026, Nightmare-Eclipse collega la lacuna sfruttata da YellowKey al file autofstx.exe e cita la possibile presenza dello stesso binario nelle immagini WinRE usate da Windows Update. Secondo il ricercatore, in forza di ciò disabilitare WinRE potrebbe non bastare.
Cosa dovrebbero fare utenti e aziende
Per la maggior parte degli utenti domestici il rischio resta relativamente basso, ma in ambito aziendale, governativo, giornalistico o nella protezione di dati personali e riservati, vale la pena rivedere alcune scelte architetturali.
La misura più importante consiste nell’evitare, quando possibile, la modalità TPM-only. L’autenticazione automatica garantita dal TPM migliora la comodità d’uso ma riduce la resistenza contro manipolazioni del boot e attacchi offline. L’aggiunta di un PIN pre-boot rende molto più difficile ottenere le chiavi di cifratura senza conoscere un segreto inserito manualmente dall’utente: almeno fintanto che non emergeranno prove di un attacco possibile su TPM+PIN.
È inoltre consigliabile usare PIN lunghi e non prevedibili, mantenere aggiornati firmware, Secure Boot e WinRE, limitare l’accesso fisico ai dispositivi, soprattutto notebook aziendali.
Le organizzazioni che gestiscono dati ad alta criticità dovrebbero però spingersi oltre la semplice configurazione di BitLocker. Sempre più aziende stanno adottando approcci multilivello che combinano: autenticazione multifattore pre-boot, smart card o token hardware, segmentazione dei dati, virtualizzazione sicura, sistemi EDR con monitoraggio dell’integrità del boot e protezioni firmware avanzate.
Progetti open source come VeraCrypt permettono configurazioni particolarmente rigide e offrono maggiore trasparenza sul funzionamento interno, anche se richiedono una gestione più complessa e non garantiscono l’integrazione profonda tipica dell’ecosistema Microsoft.