YellowKey: bypass BitLocker, Microsoft rilascia mitigazioni d'emergenza

Il 20 maggio Microsoft ha emesso mitigazioni temporanee per CVE-2026-45585, il bypass di BitLocker sfruttato via WinRE. Il PoC di Nightmare Eclipse funziona con

Contenuto

YellowKey: bypass BitLocker, Microsoft rilascia mitigazioni d'emergenza
YellowKey: bypass BitLocker, Microsoft rilascia mitigazioni d'emergenza

Microsoft ha rilasciato mitigazioni temporanee il 20 maggio 2026 per CVE-2026-45585, la vulnerabilità conosciuta come YellowKey che consente di bypassare la protezione BitLocker sfruttando il Windows Recovery Environment. La disclosure del proof-of-concept da parte del ricercatore Nightmare Eclipse ha forzato la mano di Redmond, che fino a quel momento non aveva riconosciuto pubblicamente la falla. Il rischio è concreto: chiunque abbia accesso fisico a un laptop o server fisico per pochi minuti può ottenere una shell unrestricted sul volume criptato con una chiavetta USB e la pressione di un tasto.

Punti chiave
  • Il bypass sfrutta autofstx.exe, componente WinRE eseguito automaticamente via BootExecute, per innescare il replay di transazioni TxF in un contesto pre-boot ad alta privilegio.
  • Microsoft ha pubblicato uno script per rimuovere autofstx.exe dall'immagine WinRE offline, ma l'operazione richiede intervento manuale su ogni endpoint e la rigenerazione dell'immagine di recovery.
  • L'alternativa al passaggio a TPM+PIN incontra resistenze operative nei deployment aziendali, con l'aggravante di un possibile PoC withheld annunciato dal ricercatore.
  • Il punteggio CVSS è 6.8: la bassa complessità dell'attacco è bilanciata dal requisito di accesso fisico, ma questo non riduce l'esposizione su device mobili e server in collocazioni condivise.

Come funziona l'exploit: il recovery environment diventa vettore

Il nucleo dell'attacco risiede in un'assunzione di fiducia nel comportamento predefinito di WinRE. Quando il sistema entra in recovery, il file autofstx.exe — la FsTx Auto Recovery Utility — viene eseguito automaticamente tramite il valore BootExecute nel Session Manager. L'attaccante inserisce file FsTx appositamente creati su una chiavetta USB o sulla partizione EFI, riavvia in WinRE e innesca il replay di transazioni TxF (Transactional NTFS) in un contesto pre-boot.

Secondo la ricostruzione tecnica disponibile, premendo il tasto CTRL durante la sequenza di recovery si ottiene una shell non restrittiva con accesso completo al volume protetto da BitLocker. Il ricercatore ha documentato la procedura in modo esplicito: "If you did everything properly, a shell will spawn with unrestricted access to the BitLocker protected volume", ha scritto Nightmare Eclipse nel post di disclosure riportato da The Hacker News.

Il meccanismo non attacca la crittografia in sé. L'analisi di LevelBlue, citata dalle stesse fonti, precisa che "YellowKey abuses a behavioral trust assumption in the recovery interface, allowing attackers to spawn an unrestricted shell with full access to the encrypted volume during the pre-boot recovery sequence". La debolezza è architetturale: il recovery environment opera con privilegi elevati e presuppone un contesto fidato, ma non valida l'origine dei file FsTx che elabora.

Le mitigazioni di Microsoft: un tourniquet operativamente costoso

Microsoft ha risposto con due linee d'intervento, entrambe temporanee e nessuna delle due equivalente a una patch automatizzabile. La prima richiede la modifica manuale dell'immagine WinRE: rimuovere autofstx.exe dal valore BootExecute REG_MULTI_SZ nell'hive offline, salvare le modifiche e ripristinare la fiducia BitLocker. L'azienda ha pubblicato uno script per automatizzare la procedura, ma la sua applicazione su larga scala resta fragile: ogni endpoint necessita dell'accesso all'immagine WinRE, la modifica offline espone a errori di montaggio e commit, e un'operazione fallita può rendere il sistema non recuperabile.

La seconda mitigazione è il passaggio dalla protezione TPM-only a TPM+PIN all'avvio. Questo approccio aggiunge un fattore di conoscenza che, in teoria, bloccherebbe l'exploit nella sua forma attuale. Nella pratica aziendale, però, il cambio di configurazione su migliaia di endpoint richiede ridefinizione delle policy Group Policy o Intune, test di compatibilità con i workflow esistenti, e formazione degli utenti alla gestione del PIN. Non è un intervento da fine settimana.

Will Dormann, analista di vulnerabilità citato da Help Net Security, ha confermato che il PoC pubblico funziona esattamente come descritto. La validazione indipendente del codice ha quindi eliminato ogni margine di dubbio sulla reale pericolosità della falla.

Il dilemma TPM+PIN e la minaccia del PoC withheld

La scelta di migrare a TPM+PIN incontra resistenze strutturali nei deployment enterprise. Molte organizzazioni hanno adottato TPM-only proprio per eliminare l'attrito operativo: nessun PIN da dimenticare, nessun ticket di helpdesk per sblocco, nessun delay all'avvio. Il ritorno a un fattore di conoscenza rappresenta una regressione nel modello di user experience che IT e security avevano negoziato negli ultimi anni.

Il compromesso si complica ulteriormente con l'annuncio di Nightmare Eclipse. Secondo quanto riportato da Help Net Security, il ricercatore ha dichiarato di detenere un secondo proof-of-concept in grado di bypassare anche la protezione TPM+PIN. La verifica di questa affermazione non è disponibile: il PoC è "withheld", trattenuto dalla pubblicazione. La sola minaccia, però, introduce incertezza nel calcolo del rischio. Le aziende devono investire risorse nella migrazione a TPM+PIN sapendo che potrebbe non essere sufficiente, senza una data per una patch definitiva né conferma o smentita sulla reale esistenza del secondo exploit.

"The vulnerability is not in the encryption itself, but in the recovery environment that surrounds BitLocker" — NCSC Netherlands

La precisazione dell'NCSC olandese, citata da Help Net Security, definisce con chiarezza i confini del problema. BitLocker come algoritmo di cifratura non è compromesso; il perimetro che lo circonda, il recovery environment concepito come zona di sicurezza, lo è. Questa distinzione ha conseguenze pratiche: le organizzazioni che hanno auditato la robustezza crittografica dei loro storage possono dover rivedere le assunzioni sulle protezioni fisiche e pre-boot.

Cosa fare adesso

Le azioni prioritarie per i team di sicurezza e infrastruttura:

  • Inventariare gli endpoint BitLocker in modalità TPM-only su laptop, workstation mobili e server fisici in collocazioni non dedicate: questi sono l'esposizione massima all'exploit pubblico.
  • Applicare la mitigazione WinRE con procedura controllata: testare lo script Microsoft su un campione rappresentativo di modelli hardware prima del rollout massivo, documentando ogni fallimento di montaggio immagine.
  • Valutare il passaggio a TPM+PIN per i device ad alto rischio — quelli in transito frequente, in site con accesso condiviso, o con dati classificati — accettando il costo operativo e pianificando la comunicazione agli utenti.
  • Monitorare la disclosure del ricercatore e l'eventuale rilascio del PoC withheld, preparando un canale per aggiornare rapidamente la postura di mitigazione senza riprogettare la risposta da zero.

Il recovery environment come nuovo fronte della sicurezza fisica

YellowKey riapre una questione che l'industria aveva tendenzialmente archiviato: la sicurezza del boot e del pre-boot non è riducibile alla sola crittografia del volume. Il Windows Recovery Environment, progettato come salvagente per situazioni di emergenza, funziona con privilegi che ne fanno un bersaglio privilegiato quando le assunzioni di fiducia vengono violate. La fragilità non è nel cifrario, ma nell'interfaccia che lo avvolge.

Per le organizzazioni, il messaggio è che il divario tra "encryption at rest" come promessa e "accesso fisico controllato" come prerequisito si è allargato. Il recovery environment è diventato un perimetro d'attacco vero e proprio, e le mitigazioni attuali richiedono interventi manuali su larga scala che la supply chain di patching non è strutturata per assorbire con velocità. In attesa di una correzione definitiva, il costo operativo della sicurezza si è spostato dall'automazione alla chirurgia distribuita su ogni singolo endpoint.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Link utili

Apri l'articolo su DeafNews