Introduction
Un fichier XML déposé dans la bonne partition, un redémarrage en mode recovery, et BitLocker ne protège plus rien. C'est le scénario que rend possible GreatXML, un exploit zero-day publié le 11 juin 2026 par le chercheur en sécurité Nightmare Eclipse. Sans CVE attribué ni correctif de Microsoft à ce jour, les équipes IT qui s'appuient sur BitLocker comme principal bouclier de protection des endpoints doivent réévaluer leur exposition.
Une vulnérabilité dans l'environnement de pré-amorçage
GreatXML exploite une interaction non documentée entre le scan hors ligne de Windows Defender et Windows Recovery Environment (WinRE). Le scan hors ligne Defender est une fonctionnalité permettant d'analyser un système avant son démarrage complet, depuis un environnement minimal — fréquemment activée dans les politiques de sécurité Intune ou SCCM des parcs Windows d'entreprise.
La condition d'exploitation est précisément là : si ce scan a été exécuté au moins une fois sur la machine, un attaquant disposant d'un accès physique peut copier un fichier unattend.xml malveillant à la racine de la partition de récupération. Lors du redémarrage en mode Recovery — accessible via la combinaison Shift + Redémarrer —, Windows charge ce fichier sans validation suffisante. Une invite de commandes s'ouvre alors avec les privilèges SYSTEM, le volume déchiffré intégralement accessible, BitLocker réduit à néant sans qu'une seule clé de chiffrement n'ait été compromise.
Sept zero-days en dix semaines contre les mêmes composants
GreatXML ne surgit pas dans le vide. Il s'inscrit dans une campagne publique menée depuis début avril 2026 par Nightmare Eclipse, qui a publié en dix semaines sept exploits zero-day ciblant Microsoft Defender et ses composants — dont BlueHammer, RedSun, UnDefend, GreenPlasma, YellowKey et, la veille de GreatXML, RoguePlanet. Ce dernier exploite une condition de course dans le pipeline de traitement de fichiers de Defender pour obtenir des droits SYSTEM sur un système entièrement patché, y compris avec les mises à jour de juin 2026.
La cadence est délibérée. Le chercheur, qui aurait engagé cette publication en série après avoir exprimé publiquement son mécontentement vis-à-vis du programme de divulgation de Microsoft, publie chaque exploit avant qu'un correctif existe. Certains de ces zero-days ont depuis reçu un CVE et des atténuations officielles — c'est le cas de YellowKey (CVE-2026-45585), qui ciblait lui aussi WinRE. GreatXML, publié deux semaines plus tard, reste sans réponse officielle.
Ce que les équipes IT doivent faire maintenant
BitLocker reste un mécanisme de chiffrement robuste, mais GreatXML confirme une réalité structurelle que YellowKey avait déjà mise en lumière : WinRE et la partition de récupération constituent une surface d'attaque à part entière, trop souvent laissée hors du périmètre de surveillance des équipes sécurité. Les configurations en mode TPM seul — les plus répandues dans les déploiements d'entreprise — sont particulièrement exposées aux scénarios d'accès physique non supervisé.
En l'absence de correctif, plusieurs mesures réduisent concrètement le risque :
- Sécuriser l'accès physique aux postes critiques et protéger le BIOS/UEFI par mot de passe pour contrôler les options de démarrage en mode Recovery.
- Surveiller les modifications apportées à la partition de récupération via les solutions EDR, en alertant sur tout changement inhabituel des fichiers WinRE.
- Basculer en mode TPM + PIN plutôt que TPM seul : cela ne supprime pas la surface WinRE, mais complique significativement les scénarios d'exploitation physique.
- Réévaluer l'usage des scans Defender hors ligne dans les politiques Intune ou SCCM — cette fonctionnalité constitue la condition préalable à l'exploitation de GreatXML et peut souvent être remplacée par des scans en ligne.
L'attaque ne casse pas la cryptographie. Elle contourne le chiffrement en ciblant la couche système qui l'entoure — un rappel que la sécurité d'un endpoint ne se résume jamais à une seule ligne de défense.