Il caso GreatXML evidenzia una falla nella sicurezza degli endpoint: la fiducia riposta nel recovery path. Il problema è legato al bypass di BitLocker tramite WinRE e Microsoft Defender Offline Scan, ma le verifiche indipendenti non sono del tutto concordi sulla sua riproducibilità.

Nel giro di poche ore, GreatXML è passato dalla timeline dei ricercatori ai siti di settore, con il tipico effetto amplificatore che accompagna ogni disclosure non coordinata.

Il punto critico è ottenere l’accesso a un volume protetto da BitLocker senza la chiave di recupero, sfruttando il comportamento di Windows Recovery Environment (WinRE) dopo l’uso di Microsoft Defender Offline Scan.

Per chi lavora nel settore della sicurezza degli endpoint, il titolo era già di per sé un richiamo, perché toccava tre temi sensibili: full-disk encryption, trusted recovery environment e physical access. Per questo, serve un approccio rigoroso, il caso va trattato con metodo.

Quando un claim è molto impattante e non proviene da un advisory ufficiale, la prima difesa contro le semplificazioni consiste nel distinguere ciò che è documentato da Microsoft, ciò che è sostenuto dal ricercatore e ciò che è stato effettivamente verificato da terzi.

BitLocker non è stato violato: il problema è nella catena di fiducia

Un punto fermo è che BitLocker non è stato violato dal punto di vista crittografico. Microsoft descrive BitLocker come un full-volume encryption integrato in Windows, progettato per ridurre il rischio di accesso non autorizzato a dispositivi smarriti, rubati o dismessi.

La protezione più robusta si ottiene quando il sistema utilizza il TPM (Trusted Platform Module, un chip specializzato nella scheda madre del computer progettato per migliorare la sicurezza archiviando in modo sicuro le chiavi crittografiche usate per la crittografia e la decrittografia) e, nei contesti in cui il rischio lo richiede, un fattore aggiuntivo, come un PIN o una chiave di avvio.

Questa distinzione cambia il modo in cui va letto il problema perché sposta il ragionamento dal cifrario alla trust chain: se il problema risiedesse nel recovery path, il punto debole non sarebbe l’algoritmo, ma il modo in cui il sistema renderebbe disponibile il volume cifrato durante l’avvio, il ripristino e la risoluzione dei problemi.

Un altro elemento verificato riguarda Microsoft Defender Offline Scan La documentazione Microsoft spiega che la funzione serve ad avviare una scansione antimalware da un trusted environment esterno al kernel di Windows, in modo da intercettare rootkit o minacce che potrebbero eludere i controlli in-session.

La stessa documentazione aggiunge, però, due condizioni operative molto rilevanti per il caso GreatXML: gli utenti devono essere connessi con privilegi di amministratore locale e sul sistema di archiviazione deve essere attivo BitLocker, Microsoft raccomanda di sospendere temporaneamente la protezione prima di eseguire la scansione. Altrimenti, al riavvio, il sistema potrebbe richiedere la chiave di recupero. Inoltre, WinRE deve essere abilitato, altrimenti la scansione offline non viene avviata.

Su questa premessa si innesta il claim di GreatXML. Secondo le ricostruzioni che hanno preso in esame il proof-of-concept, il bypass dipenderebbe da artefatti lasciati dal passaggio in Microsoft Defender Offline Scan e dalla successiva elaborazione dei file XML in WinRE.

Gli articoli parlano di una catena nella quale un file unattend.xml malevolo e una directory Recovery predisposta ad hoc inducono WinRE ad aprire una shell con accesso al volume protetto. Alcune fonti sottolineano che non si tratterebbe di memory corruption o kernel exploit, ma di un security feature bypass basato sul modo in cui l’ambiente di recupero tratta le configurazioni e lo stato persistente.

Questo elemento rende il caso interessante: dimostra ancora una volta che le piattaforme moderne non falliscono solo in presenza di bug della memoria, ma anche quando l’architettura di fiducia tra i componenti di recupero e protezione dei dati presenta falle logiche.

GreatXML funziona davvero? Le verifiche indipendenti non concordano

Il punto più delicato, però, è un altro. Le fonti non concordano su quanto il PoC sia realmente immediato da sfruttare. SecurityWeek e Cyderes lo presentano come un bypass di BitLocker legato all’uso pregresso di Defender Offline Scan.

Cyderes aggiunge di aver verificato il comportamento su Windows 11 aggiornato, ma lo colloca in una categoria molto precisa: non initial access, bensì post-compromise persistence and data-access primitive. Questo implica che, per scrivere gli artefatti nella partizione di ripristino sarebbero necessari già dei privilegi elevati o una forma equivalente di controllo sul dispositivo.

Se l’analisi di Cyderes fosse corretta, GreatXML non rappresenterebbe il classico scenario “prendo un portatile e in dieci minuti leggo tutto”, ma una tecnica che diventerebbe preziosa quando qualcuno ha avuto i privilegi di amministratore in un momento precedente, ha lasciato un foothold nel recovery path e vuole conservare la possibilità di accedere ai dati in un secondo momento.

La principale obiezione arriva da CSO Online, che riporta le osservazioni del ricercatore Will Dormann. Il punto è: il write-up pubblico descriverebbe la shell come conseguenza del riavvio in WinRE, mentre nei test di Dormann il comportamento si verificherebbe solo quando viene effettivamente attivata una nuova scansione offline di Microsoft Defender.

Se così fosse, la frase “no login needed” dovrebbe essere ridimensionata parecchio, perché la stessa documentazione di Microsoft indica che l’avvio della scansione offline richiede privilegi amministrativi. In questo caso, il bypass perderebbe gran parte del suo valore, almeno come tecnica per accedere al contenuto di un laptop rubato senza credenziali.

Ciò non significa che GreatXML sia irrilevante, ma piuttosto che, allo stato attuale delle fonti, può essere descritto come un caso tecnicamente plausibile, i cui prerequisiti operativi, tuttavia, non sono ancora stati chiariti in modo definitivo.

Perché il caso GreatXML riguarda tutti gli amministratori di endpoint

Per chi gestisce endpoint, questo è il punto più rilevante. Anche ipotizzando che il PoC sia incompleto, GreatXML pone nuovamente l’attenzione su un problema noto: la distanza tra la sicurezza teorica di una full-disk encryption e la sicurezza reale dell’intero ecosistema che lo circonda.

BitLocker protegge il volume quando la piattaforma si comporta come previsto e quando il processo di rilascio delle chiavi rimane ancorato alla trust policy stabilita da TPM, firmware e boot configuration.

Tuttavia, se un ambiente di recupero considerato attendibile possa essere influenzato da file o stati persistenti in modo inatteso, il perimetro di sicurezza si estenderebbe ben oltre il cifrario. In altre parole, non basta dire: “Abbiamo attivato BitLocker”; bisogna chiedersi con quale policy, in quale modalità di preboot, con quali controlli su WinRE e con quale disciplina sulle funzionalità di recupero.

Non è un caso che il tema del TPM-only ritorni spesso. Microsoft non nasconde che l’uso di TPM con PIN o avvio sicuro offre un livello di protezione superiore grazie alla preboot multifactor authentication. Nei contesti aziendali, tuttavia, il compromesso tra usabilità, carico di lavoro dell’help desk e attrito dell’utente ha spesso favorito configurazioni TPM-only.

GreatXML non dimostra da solo che ogni implementazione di questo tipo sia inadeguata, ma ricorda che il margine di sicurezza dei profili senza un secondo fattore di autenticazione dipende maggiormente dal corretto funzionamento dell’ambiente di avvio e recupero.

Quando l’attacco intercetta proprio quel perimetro, l’assenza di un ulteriore fattore di autenticazione in fase di preboot rappresenta un fattore di rischio.

Come ridurre il rischio in attesa di una posizione ufficiale di Microsoft

In pratica, la cosa più utile è un controllo selettivo. Prima di tutto, è necessario evitare di trarre conclusioni affrettate finché Microsoft non pubblicherà, se mai lo farà, un advisory tecnico specifico o una CVE associata.

Attualmente, le fonti del settore parlano apertamente di “no CVE, no patch” e non risulta alcuna presa di posizione tecnica pubblica di Microsoft su GreatXML, paragonabile alla documentazione disponibile per altri argomenti.

Un altro aspetto, è necessario rivedere la configurazione dei dispositivi che combinano dati sensibili, mobilità frequente e profili BitLocker TPM-only.

Inoltre, è necessario prestare maggiore attenzione alle politiche di accesso a WinRE dalla schermata di blocco, allo stato di abilitazione di WinRE e all’uso di Defender Offline Scan in ambienti in cui il threat model prevede il furto del dispositivo o l’accesso fisico non supervisionato.

Infine, è necessario distinguere bene tra la protezione dei dati a riposo e il controllo degli ambienti che possono sbloccarli, perché spesso il secondo aspetto viene dato per scontato finché non si verifica un caso come questo.

La vera lezione di GreatXML: la sicurezza non finisce con BitLocker

Al netto delle incertezze, ci sono due motivi per cui il caso resta rilevante. La prima ragione è immediata: se il bypass venisse confermato nella forma descritta dalle analisi più favorevoli, avremmo un altro esempio di come il recovery path possa diventare il punto debole di una misura percepita come molto solida.

La seconda ragione è più generale e forse più utile: anche se il PoC pubblico venisse corretto, ridimensionato o parzialmente smentito, il dibattito che ha aperto resterebbe importante.

Questo porta a considerare BitLocker non come una scatola nera rassicurante, ma come parte di una catena articolata che include TPM, il firmware, le regole di avvio, WinRE e gli strumenti di risoluzione dei problemi. È lì che si misura la sicurezza reale di un dispositivo.

Ed è lì che, troppo spesso, la narrativa di prodotto e la pratica operativa smettono di coincidere.

Tra hype e realtà: cosa dovrebbero fare ora le organizzazioni

C’è infine un aspetto meno evidente, ma molto concreto: il linguaggio utilizzato per descrivere GreatXML influenza direttamente le decisioni difensive.

Se lo si descrivesse come un bypass “universale” di BitLocker, si rischierebbe di generare una reazione sproporzionata e imprecisa. Se invece lo si sminuisse perché il PoC appare controverso, si rischierebbe di perdere l’opportunità di effettuare una revisione seria del percorso di recupero.

La posizione più utile è quella di stare in mezzo ai due estremi. Ciò significa riconoscere che la combinazione di WinRE, answer file, stato persistente lasciato da una scansione offline e policy BitLocker merita un’analisi di hardening, a prescindere dall’esito finale del singolo claim.

Per molte organizzazioni, ciò si traduce in attività pratiche: verificare quali dispositivi utilizzano TPM-only, controllare che la partizione di ripristino sia monitorata nei processi di incident response, siano aggiornate le procedure di passaggio di handover e di smaltimento dei notebook, siano riesaminate le eccezioni concesse per l’accesso fisico ai device e documentare in modo più rigoroso l’esecuzione di una scansione offline di Microsoft Defender.

In altre parole, GreatXML rappresenta anche uno stress test del modo in cui le aziende gestiscono gli endpoint al di fuori della normale sessione Windows.

Riferimenti

1. Microsoft Learn. BitLocker overview.
2. Microsoft Learn. BitLocker recovery overview.
3. Microsoft Learn. Run and review the results of a Microsoft Defender Offline scan.
4. Microsoft Learn. Start-MpWDOScan (Defender).
5. Microsoft Learn. Answer files (unattend.xml).
6. SecurityWeek. “GreatXML” Zero-Day Exploit Bypasses BitLocker. 11 giugno 2026.
7. Cyderes. GreatXML: Inside the Windows Zero-Day That Turns Defender’s Offline Scanner Into a BitLocker Backdoor. 11 giugno 2026.
8. CSO Online. GreatXML zero-day BitLocker bypass doesn’t seem to work, yet. 12 giugno 2026.

The Register. Nightmare Eclipse drops claimed BitLocker bypass for Microsoft Windows. 11 giugno 2026.