• Guide, Sicurezza, Sistemi Operativi
• 13 Maggio 2026

BitLocker non è morto. E, per fortuna, non siamo davanti all’ennesimo “la cifratura è inutile” da bar sport della cybersecurity.

Il caso BitUnlocker è più interessante, e anche più utile da capire: mostra cosa può accadere quando una protezione crittografica solida viene inserita dentro una catena di avvio che continua a fidarsi di componenti legacy. In altre parole, il problema non è solo “BitLocker è abilitato?”. La domanda vera è: “BitLocker è abilitato nel modo giusto, su una catena di boot realmente aggiornata e con le revoche Secure Boot applicate?”.

La differenza sembra sottile. In realtà è enorme.

A maggio 2026 è stata pubblicata BitUnlocker, una proof of concept che dimostra un attacco di downgrade contro sistemi Windows 11 protetti con BitLocker, sfruttando un vecchio boot manager vulnerabile ma ancora considerato valido da Secure Boot in determinati scenari. Secondo la descrizione del repository, l’attacco consente di accedere a dischi cifrati con BitLocker in meno di cinque minuti su macchine Windows 11 aggiornate, se sono presenti alcune condizioni specifiche.

Il punto centrale è proprio questo: non basta installare gli aggiornamenti. In alcuni casi bisogna anche revocare la fiducia verso vecchi componenti di boot ancora firmati con certificati precedenti.

Di cosa parliamo: BitUnlocker, CVE-2025-48804 e downgrade attack

BitUnlocker è una PoC pubblicata su GitHub da garatc e descritta come un downgrade attack legato a CVE-2025-48804. La vulnerabilità riguarda Windows BitLocker e, secondo NVD, consiste nell’accettazione di dati non trusted insieme a dati trusted, permettendo a un attaccante non autorizzato di bypassare una funzionalità di sicurezza tramite accesso fisico. Il punteggio CVSS 3.1 indicato da Microsoft è 6.8, con vettore AV:P, cioè physical access.

Questo dettaglio è importante: non stiamo parlando di un attacco remoto da Internet. Qui serve accesso fisico al dispositivo o comunque controllo della fase di boot, ad esempio tramite USB o PXE.

Il repo BitUnlocker indica tre prerequisiti fondamentali:

• accesso fisico a un dispositivo protetto con BitLocker;
• BitLocker configurato in modalità TPM-only, con PCR 7 + 11;
• Secure Boot database che continua a fidarsi del certificato Microsoft Windows PCA 2011.

Ed è qui che la faccenda diventa interessante per chi gestisce endpoint aziendali.

Il problema non è BitLocker bucato

Quando si legge “accesso a dischi cifrati BitLocker in cinque minuti”, la tentazione è quella di arrivare subito alla conclusione più rumorosa: BitLocker non serve.

Conclusione sbagliata.

BitLocker continua a essere una tecnologia fondamentale per proteggere i dati a riposo, specialmente su notebook, workstation e dispositivi mobili aziendali. Il punto debole evidenziato da BitUnlocker non è l’algoritmo di cifratura, ma la combinazione tra:

• configurazione BitLocker TPM-only;
• catena Secure Boot che accetta ancora boot manager legacy;
• mancata applicazione delle revoche;
• possibilità di eseguire un boot controllato dall’attaccante.

Come funziona l’attacco, ad alto livello

L’attacco utilizza un boot manager precedente alla patch ancora firmato con Microsoft Windows PCA 2011. Secure Boot, in questo scenario, valida la firma del componente, ma non verifica che si tratti della versione più recente e corretta del boot manager.

Il flusso, semplificato, è questo:

1. l’attaccante prepara un ambiente di boot controllato;
2. il sistema carica un vecchio bootmgfw.efi vulnerabile;
3. Secure Boot lo considera valido perché la firma è ancora trusted;
4. viene usato un meccanismo legato a WinRE e ai file SDI/WIM;
5. il sistema arriva a montare il volume BitLocker già decifrato;
6. l’attaccante ottiene accesso al contenuto del disco.

Il dettaglio più importante è che il TPM può rilasciare la chiave perché, dal suo punto di vista, la catena di misurazione risulta ancora accettabile nel contesto previsto dall’attacco. I sistemi più esposti sono quelli con BitLocker in modalità TPM-only e Secure Boot database ancora fiducioso verso PCA 2011.

TPM-only: comodo, ma non sempre sufficiente

Molte aziende configurano BitLocker in modalità TPM-only perché è il compromesso più semplice: l’utente accende il computer e lavora. Nessun PIN pre-boot, nessuna frizione, meno ticket al service desk.

Dal punto di vista operativo è comprensibile. Dal punto di vista della sicurezza fisica, però, TPM-only non offre lo stesso livello di protezione di TPM + PIN.

Con TPM-only, il rilascio della chiave dipende dal fatto che il dispositivo riconosca una catena di boot valida. Se un attaccante riesce a far accettare un percorso di boot vulnerabile ma ancora trusted, il dispositivo può comportarsi come se nulla fosse.

Con TPM + PIN, invece, serve anche un segreto conosciuto dall’utente prima dell’avvio del sistema operativo. Questo cambia radicalmente lo scenario: anche se l’attaccante controlla il boot, non può ottenere automaticamente il rilascio della chiave senza interazione pre-boot.

È una differenza spesso trascurata, perché TPM-only “funziona bene” fino al giorno in cui il modello di minaccia include qualcuno con il dispositivo in mano.

Perché gli aggiornamenti non bastano sempre

Microsoft ha corretto CVE-2025-48804 con aggiornamenti rilasciati nel ciclo di patching di luglio 2025, ma il punto operativo è più complesso: se un vecchio boot manager vulnerabile è ancora firmato da un certificato considerato trusted dal firmware, può continuare a essere accettato in uno scenario di downgrade.

Il repository BitUnlocker specifica, infatti, che un bootmgfw.efi pre-patch firmato sotto PCA 2011 può essere usato per un downgrade attack se il target continua a fidarsi di quella PCA.

Quindi il tema non è solo:

“Ho installato la patch?”

ma anche:

“Ho aggiornato la catena di boot?”

“Ho applicato le revoche?”

“Il mio firmware si fida ancora di PCA 2011?”

“I miei supporti USB, PXE, WinPE e recovery sono coerenti con questa nuova configurazione?”

Qui entra in gioco KB5025885, la documentazione Microsoft sulla gestione delle revoche del Windows Boot Manager per Secure Boot. Microsoft indica chiaramente che le organizzazioni devono valutare e applicare mitigazioni specifiche, ma avverte anche che, una volta abilitate, alcune revoche non sono reversibili mantenendo Secure Boot attivo. Anche una reinstallazione del sistema operativo non rimuove le revoche già applicate.

Questo spiega perché Microsoft abbia gestito il tema con un rollout graduale: revocare componenti di boot non è come aggiornare Notepad. Se sbagli, non hai un fastidio. Hai un fermacarte con tastiera.

Cosa verificare in azienda

La parte più utile, per un team IT o security, non è provare BitUnlocker. È verificare se il proprio parco macchine è esposto alle condizioni che rendono possibile questo tipo di attacco.

Le verifiche dovrebbero includere almeno questi punti.

1. Stato BitLocker

Verificare che BitLocker sia abilitato e capire quali protector sono configurati.

Comandi utili:

 

L’obiettivo non è solo vedere “Protection On”, ma capire se il dispositivo usa TPM-only oppure TPM + PIN.

2. Stato Secure Boot

Verificare che Secure Boot sia attivo:

Secure Boot disattivato è un problema evidente. Ma BitUnlocker ricorda una cosa ancora più sottile: Secure Boot attivo non significa automaticamente catena di boot immune ai downgrade.

Figura 1 – SecureBoot attivo

3. Versione e firma del boot manager effettivamente usato

Bisogna controllare il boot manager presente nella partizione EFI, non solo i file presenti sotto C:\Windows.

Una possibile procedura di audit, da usare con attenzione e privilegi amministrativi, è:

Qui il punto è verificare quale certificato firma il boot manager attivo e distinguere scenari ancora legati a PCA 2011 da scenari migrati verso Windows UEFI CA 2023.

Figura 2 – Certificato firma

4. Eventi di applicazione delle mitigazioni

Microsoft indica eventi specifici per verificare l’applicazione delle mitigazioni legate a DB e DBX:

• Event ID 1036: il certificato PCA2023 è stato aggiunto al DB;
• Event ID 1799: è stato applicato il boot manager firmato PCA2023;
• Event ID 1037: è stato applicato l’aggiornamento DBX che rimuove la fiducia verso PCA2011.

Questi eventi sono fondamentali perché permettono di distinguere una macchina semplicemente aggiornata da una macchina su cui la mitigazione è stata effettivamente applicata.

5. Stato di WinRE

Dato che la vulnerabilità coinvolge Windows Recovery Environment e il meccanismo SDI/WIM, ha senso verificare anche lo stato di WinRE:

Figura 3 – Stato WinRE

Non significa che WinRE vada disabilitato ovunque. Significa che, sui sistemi ad alto rischio, va compreso e gestito come parte della superficie di boot.

6. Supporti di recovery, imaging e PXE

Una delle trappole più sottovalutate riguarda i supporti esterni.

Dopo l’applicazione delle revoche, vecchi supporti USB, ISO, immagini WinPE o ambienti PXE potrebbero non avviarsi più correttamente o potrebbero non essere coerenti con la nuova catena di fiducia. Microsoft stessa richiama la necessità di aggiornare i bootable media nel percorso di gestione delle mitigazioni.

In pratica: non basta sistemare i client. Bisogna sistemare anche tutto ciò che usiamo per installarli, recuperarli e gestirli.

Mitigazioni consigliate

Per ridurre il rischio, le azioni più importanti sono queste.

Abilitare TPM + PIN sui dispositivi ad alto rischio

Non tutti i dispositivi hanno lo stesso profilo di rischio. Su workstation amministrative, notebook di utenti privilegiati, dispositivi usati da figure apicali o endpoint che trattano dati critici, TPM + PIN dovrebbe essere seriamente valutato.

Sì, introduce frizione. Ma in alcuni scenari quella frizione è esattamente la sicurezza che mancava.

Applicare KB5025885

Le organizzazioni dovrebbero valutare il percorso Microsoft per la migrazione verso Windows UEFI CA 2023 e l’applicazione delle revoche DBX. Questo richiede test, inventario hardware, verifica firmware e aggiornamento dei supporti di recovery.

Microsoft avverte che l’applicazione delle revoche non è un’operazione banale e che va testata accuratamente prima del rollout.

Aggiornare firmware e BIOS/UEFI

Secure Boot vive nel firmware. Quindi una postura seria richiede anche aggiornamento firmware, BIOS/UEFI e verifica della compatibilità dei modelli hardware.

Aggiornare WinRE, WinPE, immagini e PXE

Il parco recovery deve essere trattato come parte dell’infrastruttura di sicurezza, non come una cartella polverosa che si apre solo quando qualcosa è già andato storto.

Controllare l’escrow delle recovery key

Prima di toccare policy BitLocker, PIN, Secure Boot e revoche, bisogna verificare che le recovery key siano correttamente salvate in Active Directory, Entra ID o nella piattaforma di management usata dall’organizzazione.

Perché il giorno in cui si rompe il boot e nessuno trova la recovery key, la sicurezza smette di essere una disciplina e diventa archeologia.

Cosa non fare

Ci sono anche alcune cose da evitare.

Non bisogna disabilitare BitLocker “per sicurezza”. È una contraddizione in termini.

Non bisogna applicare revoche DBX in modo massivo senza test.

Non bisogna considerare “patch installata” come sinonimo di “rischio mitigato”.

Non bisogna dimenticare i supporti di recovery.

E soprattutto non bisogna liquidare l’attacco dicendo “serve accesso fisico, quindi non conta”. Per notebook, workstation privilegiate, dispositivi smarriti, furti mirati e ambienti ad alta esposizione, l’accesso fisico è esattamente uno degli scenari per cui BitLocker viene adottato.

Domande da fare al proprio ambiente

Prima di considerare chiuso il tema, conviene porsi alcune domande molto pratiche:

• Quanti dispositivi aziendali sono in TPM-only?
• Quanti dispositivi privilegiati usano TPM + PIN?
• Abbiamo evidenza dell’applicazione delle revoche Secure Boot?
• I nostri bootable media sono aggiornati?
• Le immagini PXE sono coerenti con le mitigazioni?
• Le recovery key sono disponibili e correttamente escrowed?
• Abbiamo testato l’impatto su modelli hardware diversi?
• Abbiamo una procedura di rollback operativo, dove possibile?

Conclusione

BitUnlocker è interessante perché ci costringe a uscire dalla visione binaria della sicurezza. BitLocker attivo non significa automaticamente dato protetto in ogni scenario. Secure Boot attivo non significa automaticamente catena di boot inattaccabile. Patch installata non significa automaticamente revoca applicata.

Il messaggio per chi gestisce ambienti Windows è chiaro: la protezione dei dati a riposo non dipende da una singola spunta verde nella console. Dipende da una catena: BitLocker, TPM, Secure Boot, firmware, boot manager, WinRE, recovery media, policy e processi operativi.

E come sempre, in sicurezza, la catena non si rompe dove è più crittografica. Si rompe dove è più comoda.

Stay tuned!