1. Résumé exécutif

GreatXML est un code de démonstration public, publié le 10 juin 2026 par le chercheur Nightmare Eclipse / Chaotic Eclipse / MSNightmare, qui revendique un contournement de BitLocker. La technique abuse de l’environnement de récupération Windows (WinRE), de l’état laissé par la fonctionnalité d’analyse hors ligne de Microsoft Defender, et du traitement légitime des fichiers de réponse d’installation (unattend.xml). Le résultat revendiqué est l’obtention d’un interpréteur de commandes avec accès non restreint au volume protégé par BitLocker, alors que BitLocker continue de signaler le volume comme protégé.

Le modèle de menace repose sur un accès physique. BitLocker étant un contrôle de protection des données au repos, le scénario pertinent est celui des terminaux perdus, volés ou laissés sans surveillance, et non une compromission à distance.

La fiabilité de la technique est débattue. Un chercheur tiers (Will Dormann) a jugé le write-up défaillant, l’interpréteur n’apparaissant qu’à l’analyse hors ligne suivante, ce qui rattache le déclencheur au chemin d’amorçage de l’analyse hors ligne plutôt qu’à un simple démarrage WinRE.

2. Chaîne d’attaque (niveau défenseur)

La chaîne revendiquée, telle que décrite par les analyses publiques, se résume ainsi :

1. La machine est dans un état de récupération lié à une analyse hors ligne de Defender (état conservé après une analyse initiée au moins une fois).
2. L’attaquant écrit un fichier unattend.xml et un répertoire Recovery à la racine de la partition de récupération.
3. La machine est redémarrée vers WinRE (Maj + Redémarrer, démarrage avancé, support de récupération, ou amorçage automatique après échec).
4. La logique d’installation ou de récupération traite le contenu unattend contrôlé par l’attaquant.
5. Un interpréteur de commandes s’ouvre avec accès au volume chiffré.

Le point critique n’est pas l’existence de unattend.xml, qui est un mécanisme de déploiement Windows pris en charge. Le problème est contextuel : un mécanisme de déploiement est honoré dans un chemin de récupération ou d’analyse hors ligne qui dispose par ailleurs d’un accès au volume du système d’exploitation. L’environnement de récupération devient alors le côté faible de la frontière de chiffrement.

3. Primitives techniques impliquées

WinRE (Windows Recovery Environment). Environnement de récupération basé sur Windows PE, présent par défaut sur Windows 10, Windows 11 et Windows Server 2016 et ultérieurs. Il s’exécute hors de la session utilisateur normale, avant que les contrôles de point d’accès et la télémétrie d’entreprise ne soient pleinement actifs, et dispose de l’autorité nécessaire pour réparer un système. La documentation Microsoft pose comme promesse de sécurité que les fichiers chiffrés ne devraient pas être accessibles en récupération sans la clé : c’est cette promesse que la technique met en cause.

unattend.xml. Fichier de réponse d’installation sans assistance, conçu pour automatiser la configuration et le déploiement de Windows. Il peut porter une logique d’exécution de commandes. Selon l’analyse défensive publique du PoC, le fichier embarqué dans le dépôt n’est pas un artefact de durcissement d’entreprise : il écrit puis lance un script, démarre conhost.exe et s’appuie sur une logique de script PowerShell d’installation. Cette caractérisation sert d’indicateur pour la détection. La charge utile exacte n’est volontairement pas reproduite ici.

État d’analyse hors ligne de Defender. L’analyse hors ligne reconfigure l’amorçage pour démarrer la machine dans un mode d’analyse au sein de l’environnement de récupération. C’est cette reconfiguration qui, selon la revendication, place la partition de récupération dans un état exploitable. Le test de reproduction tiers situe le déclenchement effectif au moment de l’analyse hors ligne suivante.

4. Pré-conditions et portée

• Pré-condition revendiquée : analyse hors ligne de Defender initiée au moins une fois sur la machine.
• Chemin alternatif, qualifié de spéculatif par l’auteur lui-même : sans analyse hors ligne préalable, l’attaquant devrait se connecter et l’initier, ou trouver un moyen d’amorcer WinRE dans l’état d’analyse hors ligne. Ce chemin ne doit pas être présenté comme une exploitation distante ou sans connexion confirmée.
• La technique aurait été démontrée sur Windows 11 24H2 (build 10.0.26100.x).
• Le contournement viserait notamment les configurations BitLocker à TPM seul, qui n’imposent pas de secret au démarrage.

5. Confirmé / revendiqué / non vérifié

Élément	Statut
Dépôt public GreatXML (README, unattend.xml, captures, répertoire Recovery/WindowsRE)	Confirmé
Obtention d’un shell avec accès non restreint au volume après copie des fichiers et amorçage WinRE	Revendication de l’auteur
WinRE comme environnement PE de récupération par défaut, et unattend comme mécanisme de déploiement légitime	Confirmé (documentation Microsoft)
Versions affectées, répétabilité matérielle, déclenchement sans connexion	Non vérifié
Reconnaissance du problème comme vulnérabilité par Microsoft	Non confirmé
Attribution CVE et correctif	Aucun à la date de rédaction

6. Détection et chasse

• Intégrité de la partition de récupération : surveiller l’apparition ou la modification de unattend.xml à la racine du volume de récupération, ainsi que les modifications de \Recovery\WindowsRE\ReAgent.xml et du répertoire Recovery hors contexte de déploiement légitime.
• État WinRE : reagentc /info pour relever l’emplacement de l’image, l’identifiant et l’état. Toute modification non planifiée est un signal.
• État Defender : Get-MpComputerStatus pour vérifier le mode de fonctionnement et la trace d’une analyse hors ligne initiée.
• Protecteurs BitLocker : manage-bde -status pour identifier les volumes en TPM seul par rapport à TPM+PIN.
• Journaux d’amorçage : transitions vers WinRE ou démarrage avancé hors fenêtre de maintenance, traités comme événements de sécurité.
• Indicateurs de fichiers : présence de unattend.xml et ReAgent.xml sur le volume de récupération hors déploiement, lancement de conhost.exe ou de scripts inattendus depuis WinRE.
• Indices physiques : traces d’accès physique, d’amorçage externe ou de manipulation du châssis.

7. Remédiation

Mesures défensives indépendantes d’un correctif éditeur.

• Authentification pré-démarrage (priorité) : passer de TPM seul à TPM+PIN. La clé n’étant pas libérée sans le PIN, le chemin de récupération n’atteint pas un volume auto-déverrouillé. En poste : manage-bde -protectors -add C: -TPMAndPIN. En parc : stratégie GPO ou Intune « Exiger une authentification supplémentaire au démarrage ». À valider selon votre modèle de menace.
• Durcissement de WinRE : maintenir l’intégrité et la mise à jour de l’image WinRE (cf. séquence de mise à jour WinRE liée à KB5025885), contrôler l’usage de reagentc, et envisager la désactivation de WinRE sur les profils à haut risque, au prix de la capacité de récupération.
• Sécurité physique : mot de passe firmware ou UEFI, Secure Boot actif, désactivation de l’amorçage externe, scellés et verrouillage châssis.
• Maîtrise de l’analyse hors ligne : restreindre et journaliser le déclenchement de l’analyse hors ligne de Defender.
• Suivi correctif : surveiller l’attribution d’un CVE et la publication d’un correctif Microsoft, cette divulgation s’inscrivant dans la séquence YellowKey (CVE-2026-45585, corrigé au Patch Tuesday de juin 2026).

8. Localisation et statut du PoC

Le code de démonstration est publié sur un dépôt GitHub public sous l’identité MSNightmare et répliqué sur deux forges Git indépendantes. Les trois adresses figurent dans le corps du billet d’origine. Elles ne sont pas relayées dans cette note, par cohérence avec une pratique de divulgation responsable, et parce que la réplication sur plusieurs forges rend tout retrait ponctuel inopérant : le PoC doit être considéré comme diffusé, indépendamment de l’état d’une page individuelle.

9. Contexte de la série

GreatXML s’inscrit dans une série de divulgations non coordonnées du même auteur, motivées selon ses déclarations par un différend avec le processus de signalement de Microsoft. Divulgations associées : YellowKey (CVE-2026-45585), BlueHammer (CVE-2026-33825), RedSun (CVE-2026-41091), UnDefend (CVE-2026-45498), GreenPlasma et RoguePlanet. La cadence et la proximité avec le Patch Tuesday de juin 2026 suggèrent une focalisation continue sur l’environnement de récupération.

10. Sources

• Hive Security, GreatXML: When a Setup File Unlocks BitLocker, 11 juin 2026 (analyse défensive, primitives WinRE/unattend) : https://hivesecurity.gitlab.io/blog/greatxml-bitlocker-bypass-winre-defender-offline/
• The Register, Nightmare Eclipse drops claimed BitLocker bypass for Microsoft Windows, 11 juin 2026 (reproduction tierce, W. Dormann) : https://www.theregister.com/security/2026/06/11/nightmare-eclipse-drops-claimed-bitlocker-bypass-for-microsoft-windows/5254371
• SecurityWeek, GreatXML Zero-Day Exploit Bypasses BitLocker, 11 juin 2026 : https://www.securityweek.com/greatxml-zero-day-exploit-bypasses-bitlocker/
• The Hacker News, New GreatXML Exploit Bypasses Windows BitLocker via Recovery Partition XML Files, 11 juin 2026 : https://thehackernews.com/2026/06/new-greatxml-exploit-bypasses-windows.html
• GBHackers, GreatXML Zero-Day Enables BitLocker Bypass Through Windows Defender Offline Scan, 11 juin 2026 : https://gbhackers.com/greatxml-zero-day-enables-bitlocker-bypass/
• CybersecurityNews, GreatXML BitLocker Bypass 0-Day Exploited Via Windows Defender Offline Scan, 11 juin 2026 : https://cybersecuritynews.com/greatxml-bitlocker-bypass-0-day-exploited/
• IT-Connect, Microsoft fixes YellowKey, but GreatXML zero-day bypasses BitLocker, 11 juin 2026 : https://www.it-connect.tech/microsoft-fixes-yellowkey-but-greatxml-zero-day-bypasses-bitlocker/
• Billet d’origine (Blogger), publié le 10 juin 2026, état du contenu vérifié le 12 juin 2026 : https://deadeclipse666.blogspot.com/2026/06/greatxml-bitlocker-that-seems-to-only.html