Contournement par clé USB, environnement de récupération détourné et accès complet aux données chiffrées de Windows 11
Par Thomas | Publié le
🔥 Ce qu’il faut retenir
- Microsoft a publié le 20 mai 2026 une mitigation manuelle pour CVE-2026-45585 (alias YellowKey), faille BitLocker exploitable avec un simple accès physique au PC, score CVSS 6.8
- L’exploit, divulgué sans coordination par le chercheur Nightmare-Eclipse, détourne Transactional NTFS et l’environnement de récupération Windows (WinRE) pour spawner un shell sans restriction sur le disque chiffré
- Windows 11 24H2 / 25H2 / 26H1 et Windows Server 2025 sont concernés, Windows 10 est épargné, et aucune date de patch officiel n’est annoncée
Microsoft vient de reconnaître publiquement YellowKey, une faille de contournement de BitLocker désormais référencée sous CVE-2026-45585, et propose une mitigation manuelle plutôt qu’un correctif intégré dans le cycle Patch Tuesday. La singularité du dossier tient au fait que le proof of concept a été publié AVANT toute coordination avec Redmond, forçant le constructeur à publier dans l’urgence une procédure de contournement à appliquer device par device. Sur le suivi des actualités sécurité hardware de Test Disque Dur, ce genre de faille touchant directement le chiffrement disque est un signal fort pour quiconque gère un parc de laptops ou stocke des données sensibles.
Une faille publiée sans coordination, Microsoft mis devant le fait accompli
Le chercheur connu sous les pseudonymes Nightmare-Eclipse ou Chaotic Eclipse a divulgué publiquement l’exploit fonctionnel une semaine avant l’avis officiel Microsoft, en dehors de toute procédure de divulgation coordonnée. Redmond a explicitement qualifié l’incident de violation des pratiques de coordinated vulnerability disclosure dans son advisory. Ce mode opératoire n’est pas une première pour ce chercheur : il avait déjà publié des PoC pour plusieurs zero-days Windows précédents, dont BlueHammer (élévation de privilèges) et UnDefend (blocage de Microsoft Defender).
💡 Pour comprendre : BitLocker, TPM et chiffrement disque sur Windows
BitLocker est la solution de chiffrement intégrale de disque intégrée aux éditions Pro, Enterprise et Education de Windows. En pratique, BitLocker chiffre tous les secteurs du disque avec une clé maître stockée dans le TPM (Trusted Platform Module), une puce dédiée présente sur la carte mère ou intégrée au CPU. Au démarrage, le TPM vérifie que le firmware et la séquence de boot n’ont pas été altérés, puis libère la clé pour déchiffrer le système. Cette mécanique protège efficacement contre l’extraction physique du disque (le disque sorti d’un PC reste inutilisable), mais elle repose entièrement sur la confiance accordée à la chaîne de démarrage Windows, environnement de récupération inclus.
YellowKey n’attaque pas le chiffrement lui-même : il exploite la confiance accordée par BitLocker à l’environnement de récupération Windows pour obtenir un shell qui voit le disque déjà déchiffré.
Concrètement, le déroulé d’attaque est trivial pour quiconque a un accès physique de quelques minutes au PC ciblé. L’attaquant insère une clé USB préparée avec le code d’exploit publiquement disponible, force un redémarrage en mode récupération et laisse le payload exploiter Transactional NTFS pour supprimer le fichier winpeshl.ini. WinRE, ne trouvant plus son script de lancement standard, retombe sur un shell sans restriction qui voit l’intégralité du disque déchiffré. Pas besoin d’identifiants, pas d’installation logicielle, pas de réseau. Pour les organisations qui s’appuient sur BitLocker pour sécuriser leur flotte de laptops, une bonne pratique complémentaire reste la sauvegarde redondante des données critiques sur des disques durs externes dédiés à la sauvegarde chiffrée, indépendants de la machine principale.
Découvrir notre sélection au meilleur prix !
WinRE, le maillon faible exploité par YellowKey
L’environnement de récupération Windows est censé être un espace de confiance, c’est précisément pour cette raison que BitLocker l’autorise à accéder au disque déchiffré sans authentification supplémentaire. C’est cette confiance excessive qui devient l’angle d’attaque de YellowKey.
💡 Pour comprendre : WinRE, l’environnement de récupération Windows
WinRE (Windows Recovery Environment) est une mini-installation de Windows stockée dans une partition cachée du disque, qui se lance automatiquement quand le système principal détecte un problème de démarrage ou quand l’utilisateur force la séquence de récupération. Son rôle légitime : réparer le boot, restaurer une image système, accéder à l’invite de commandes en cas de pépin. Le problème de conception exposé par YellowKey, c’est que WinRE charge ses propres scripts depuis le disque (winpeshl.ini, BootExecute du Session Manager) et que BitLocker lui fait confiance par défaut. Si un attaquant arrive à modifier ces scripts ou à faire échouer leur chargement, WinRE bascule sur un shell générique qui hérite des droits maximums sur un disque déjà déchiffré.
La mitigation Microsoft consiste à empêcher autofstx.exe (la FsTx Auto Recovery Utility) de démarrer automatiquement quand l’image WinRE se lance. L’administrateur doit monter l’image WinRE sur chaque appareil, charger la ruche de registre système associée, supprimer la valeur autofstx.exe du paramètre BootExecute du Session Manager, puis rétablir la relation de confiance BitLocker pour WinRE. La procédure n’est pas triviale et demande à être scriptée pour un déploiement de masse.
TPM seul vs TPM+PIN, l’écart de protection devient critique
Microsoft recommande explicitement de basculer les machines à risque du mode TPM seul vers le mode TPM+PIN. Cette préconisation n’est pas anodine : la majorité des déploiements BitLocker en entreprise sont aujourd’hui configurés en TPM seul, par souci de confort utilisateur (démarrage silencieux, sans saisie).
💡 Pour comprendre : TPM seul vs TPM+PIN, deux niveaux de défense
En mode TPM seul, le PC démarre sans rien demander à l’utilisateur : le TPM libère automatiquement la clé BitLocker dès que la chaîne de boot est validée. C’est confortable, mais cela signifie aussi qu’un attaquant qui parvient à faire valider sa séquence de démarrage (via WinRE par exemple) obtient le disque déchiffré sans aucune intervention humaine. Le mode TPM+PIN ajoute un code numérique de 6 à 20 chiffres que l’utilisateur doit saisir avant que la clé ne soit libérée. YellowKey ne sait pas contourner cette saisie : sans le PIN, le shell récupéré dans WinRE ne voit que des données chiffrées illisibles. Le contre-coup, c’est qu’il faut former les utilisateurs, gérer les oublis de PIN et accepter de perdre le démarrage sans intervention.
Voici un tableau récapitulatif des quatre modes d’authentification BitLocker et de leur résistance face à une attaque physique de type YellowKey, en attendant les SSD NVMe à chiffrement matériel intégré qui restent une couche de protection complémentaire au niveau hardware.
| Mode BitLocker | Authentification au démarrage | Résistance à YellowKey | Confort d’usage |
|---|---|---|---|
| TPM seul (default) | Aucune saisie | Vulnérable | Démarrage transparent |
| TPM + PIN | PIN 6 à 20 chiffres | Résistant | Saisie au démarrage |
| TPM + clé USB | Clé USB physique | Variable selon usage | Clé à conserver séparément |
| TPM + PIN + clé USB | PIN + clé USB | Très résistant | Double facteur exigé |
À noter : le chercheur Nightmare-Eclipse a indiqué qu’il garde sous le coude un second PoC capable de contourner également le mode TPM+PIN. Cette menace n’est pour l’instant que théorique pour le grand public, mais elle pèse sur la stratégie de défense long terme.
Systèmes affectés et plan d’action pour les administrateurs
Tout PC sous Windows 11 récent avec un port USB et la possibilité de redémarrer en récupération est une cible viable tant que la mitigation n’est pas appliquée.
L’avis Microsoft cible explicitement Windows 11 versions 24H2, 25H2 et 26H1 sur x64, ainsi que Windows Server 2025 (installation standard et Server Core). Windows 10 n’est pas concerné en raison de différences dans sa configuration WinRE. Des analyses techniques publiques signalent toutefois Windows Server 2022 comme potentiellement vulnérable sous certaines conditions de déploiement, sans que Microsoft n’ait formellement traité ce cas dans son advisory.
Pour un parc de machines, le plan d’action immédiat est triple : identifier tous les endpoints sous versions affectées, déployer la mitigation WinRE de manière scriptée et automatisée, et envisager le passage progressif vers TPM+PIN sur les machines les plus exposées (laptops nomades, postes en open space, dispositifs prêtés). En parallèle, la sauvegarde régulière des données critiques sur des supports externes reste la dernière ligne de défense en cas de compromission physique.
Si tu hésites sur le choix d’un support de sauvegarde externe adapté à un usage pro ou sensible, sinon je suis là pour t’orienter selon ton budget et tes contraintes, j’ai testé pas mal de modèles 2,5 pouces chiffrés et de SSD externes USB-C qui couvrent bien le segment 50 à 200 €.
Pour suivre la suite du dossier YellowKey et la publication éventuelle du patch officiel, le mieux reste de consulter le site officiel du Microsoft Security Response Center, qui publie les advisories au fil de l’eau et tiendra à jour la fiche CVE-2026-45585.
Qu’est-ce que la faille BitLocker YellowKey CVE-2026-45585 ?
YellowKey est une vulnérabilité de contournement de BitLocker référencée sous CVE-2026-45585, avec un score CVSS de 6.8. Elle permet à un attaquant disposant d’un accès physique au PC de spawner un shell sans restriction dans l’environnement de récupération Windows (WinRE), ce qui donne accès au disque chiffré sans saisie d’identifiants ni installation logicielle. La faille a été divulguée publiquement par le chercheur Nightmare-Eclipse avant toute coordination avec Microsoft.
Quelles versions de Windows sont concernées ?
L’avis Microsoft cible Windows 11 versions 24H2, 25H2 et 26H1 sur architecture x64, ainsi que Windows Server 2025 et Windows Server 2025 Server Core. Windows 10 n’est pas concerné en raison d’une configuration WinRE différente. Windows Server 2022 est signalé comme potentiellement vulnérable par certaines analyses techniques publiques, mais Microsoft ne l’a pas formellement intégré à son advisory pour l’instant.
Faut-il un accès physique au PC pour exploiter YellowKey ?
Oui, l’exploitation requiert obligatoirement un accès physique à la machine cible. L’attaquant doit pouvoir y brancher une clé USB préparée avec le code d’exploit publié et forcer un redémarrage en mode récupération. Aucune attaque à distance n’est possible via YellowKey. Le risque concerne donc principalement les laptops volés, perdus, ou les postes laissés sans surveillance dans des environnements partagés.
Quelle différence entre BitLocker en mode TPM seul et TPM+PIN ?
En mode TPM seul, le PC démarre sans demander aucun code à l’utilisateur, le TPM libère automatiquement la clé de chiffrement dès que la chaîne de boot est validée. C’est ce mode qui est vulnérable à YellowKey. Le mode TPM+PIN ajoute la saisie d’un code numérique de 6 à 20 chiffres au démarrage : la clé n’est libérée qu’après cette validation, ce qui bloque l’exploit actuel. Microsoft recommande explicitement de passer en TPM+PIN sur les machines les plus exposées.
Comment appliquer la mitigation Microsoft contre YellowKey ?
La procédure officielle consiste à monter l’image WinRE sur chaque appareil concerné, charger la ruche de registre système associée, puis supprimer la valeur autofstx.exe du paramètre BootExecute du Session Manager. Il faut ensuite rétablir la relation de confiance BitLocker pour WinRE. La manipulation n’est pas triviale et doit idéalement être scriptée pour un déploiement de masse. Microsoft documente la procédure complète dans son advisory officiel sur le portail MSRC.
Quand Microsoft publiera-t-il un patch officiel pour CVE-2026-45585 ?
Microsoft confirme travailler sur un correctif permanent mais n’a annoncé aucune date de publication. L’avis officiel précise que le CVE a été émis pour fournir une mitigation provisoire, dans l’attente de la mise à disposition de la mise à jour de sécurité. Cette approche divulgation sans patch est inhabituelle chez Microsoft et reflète l’urgence imposée par la publication non coordonnée du proof of concept. En attendant, la mitigation manuelle et le passage en TPM+PIN restent les deux leviers disponibles.
