Introduction

En mai 2026, deux nouvelles vulnérabilités Windows publiquement divulguées ont provoqué une onde de choc dans la communauté cybersécurité : YellowKey et GreenPlasma. Ces deux failles, attribuées au chercheur connu sous les pseudonymes Chaotic Eclipse et Nightmare-Eclipse, ciblent des composants fondamentaux de l’écosystème Windows.

La première, YellowKey, remet en question la fiabilité du modèle de confiance de BitLocker en permettant un contournement du chiffrement de disque via l’environnement de récupération Windows (WinRE). La seconde, GreenPlasma, cible l’architecture interne du processus CTFMON et des objets mémoire partagés afin d’obtenir une élévation de privilèges jusqu’au niveau SYSTEM.

Ces vulnérabilités sont particulièrement intéressantes d’un point de vue technique car elles ne reposent pas sur des primitives classiques de corruption mémoire, mais sur des erreurs de conception liées aux frontières de confiance, aux mécanismes de boot sécurisé, aux environnements de récupération et à la gestion des objets du noyau Windows.

Cet article propose une analyse approfondie du fonctionnement supposé de ces vulnérabilités, des composants internes concernés et des implications en matière de sécurité offensive et défensive.

Partie I – YellowKey : contournement de BitLocker via WinRE

1. Rappels sur BitLocker

1.1 Architecture générale

BitLocker est le mécanisme de chiffrement de volume intégré à Windows. Il repose sur plusieurs briques de sécurité :

Le TPM (Trusted Platform Module)
Les protecteurs de clés
Les VMK (Volume Master Keys)
Les FVEK (Full Volume Encryption Keys)
Le Secure Boot
Le démarrage mesuré
Les PCR (Platform Configuration Registers)

L’objectif principal de BitLocker est d’empêcher l’accès aux données en cas de vol physique de la machine.

Le processus simplifié est le suivant :

La VMK est scellée dans le TPM.
Au démarrage, le TPM vérifie l’intégrité de la chaîne de boot.
Si les PCR correspondent à l’état attendu, la VMK est libérée.
La VMK déchiffre la FVEK.
La FVEK déchiffre le volume.

En mode TPM-only, l’utilisateur n’a même pas besoin d’entrer un mot de passe.

2. Le rôle critique de WinRE

2.1 Qu’est-ce que WinRE ?

WinRE (Windows Recovery Environment) est un environnement minimal dérivé de Windows PE.

Il est utilisé pour :

Réparer le système
Restaurer une image
Accéder à l’invite de commandes
Réinitialiser Windows
Diagnostiquer les erreurs de boot

Le point important est que WinRE doit pouvoir accéder aux volumes système afin d’effectuer certaines opérations de maintenance.

Cela implique qu’à certains moments du processus de récupération, des volumes BitLocker peuvent être montés automatiquement ou accessibles via des mécanismes privilégiés.

3. Principe général de YellowKey

3.1 Vue d’ensemble

YellowKey exploiterait un mécanisme interne de WinRE permettant le traitement automatique d’une structure spécifique nommée FsTx située dans :

System Volume Information\FsTx

Selon les éléments publiquement observés, l’exploitation se fait au travers des étapes suivantes :

1. Un périphérique de stockage USB (formatée en NTFS de préférence, mais FAT32/exFAT devrait fonctionner) contenant la structure évoquée ci-dessus est branché.
2. Redémarrer la machine en mode WinRE.
- Vous pouvez le faire en maintenant la touche MAJ enfoncée et en cliquant sur le bouton de redémarrage avec votre souris.
- Une fois que vous avez cliqué sur le bouton de redémarrage, levez votre doigt de la touche MAJ et maintenez la touche CTRL enfoncée sans la relâcher.
3. Un comportement spécial est déclenché au démarrage.
4. Une invite de commandes privilégiée est ouverte.
5. Le volume BitLocker devient alors accessible sans clé de récupération.

Le comportement ressemble fortement à un mécanisme de transaction ou de restauration interne laissé accessible dans WinRE, ou plus inquiétant, il s’agirait d’une backdoor déployée volontairement (sur Windows 11 et Server 2022/2025 uniquement).

4. Analyse technique du comportement

4.1 Le dossier System Volume Information

System Volume Information est un répertoire protégé utilisé par Windows pour :

les points de restauration
l’indexation
les métadonnées NTFS
les snapshots VSS
certaines transactions système

L’existence d’un sous-dossier FsTx suggère fortement un lien avec :

NTFS Transactional APIs
TxF (Transactional NTFS)
ou un moteur interne de réparation de fichiers

Microsoft a officiellement déprécié TxF depuis plusieurs années, mais une grande partie du code historique subsiste encore dans Windows pour des raisons de compatibilité.

4.2 Hypothèse sur la chaîne d’exploitation

Le comportement observé suggère un scénario proche du suivant :

WinRE détecte automatiquement une structure FsTx.
Cette structure déclenche une routine privilégiée.
Une opération de restauration ou de réparation est exécutée.
La routine s’exécute avant certaines vérifications BitLocker.
Une console SYSTEM est ouverte.
Le volume déjà déverrouillé devient accessible.

Le point fondamental est ici la rupture de frontière de confiance car le système considère implicitement que l’environnement WinRE est légitime et autorisé à manipuler des volumes chiffrés.

YellowKey semble ici exploiter cette hypothèse.

5. Pourquoi BitLocker devient accessible

5.1 Déverrouillage automatique du volume

Dans un système TPM-only :

le TPM libère automatiquement les clés
le volume système est monté très tôt
WinRE hérite potentiellement de cet état déverrouillé

Si un composant WinRE privilégié permet ensuite l’ouverture d’un shell SYSTEM, l’attaquant récupère indirectement l’accès au volume déchiffré.

Il est important de comprendre qu’ici :

le chiffrement AES de BitLocker n’est pas cassé
le TPM n’est pas compromis cryptographiquement
la chaîne de confiance logique est contournée

C’est une différence essentielle, on est face à un bypass et non pas une faiblesse ou faille cryptographique.

6. Impact réel

6.1 Scénario d’attaque réaliste

Supposons un ordinateur portable volé.

L’attaquant :

Branche une clé USB préparée.
Démarre en WinRE.
Déclenche le mécanisme YellowKey.
Obtient une invite SYSTEM.
Monte le disque.
Exfiltre les données.

La totalité des protections BitLocker TPM-only devient alors inefficace.

6.2 Environnements les plus exposés

Les configurations suivantes semblent particulièrement vulnérables :

Windows 11 avec BitLocker activé par défaut
serveurs Windows Server 2022/2025
machines sans PIN BitLocker
environnements utilisant uniquement TPM

7. Analyse de la surface d’attaque

YellowKey démontre un problème architectural fréquent dans Windows :

les environnements de récupération disposent souvent de privilèges extrêmement élevés.

WinRE possède notamment :

un accès privilégié au stockage
des composants hérités
des outils de réparation puissants
des exceptions de sécurité
des mécanismes de compatibilité anciens

Historiquement, plusieurs vulnérabilités BitLocker ont déjà exploité cette zone grise entre maintenance système et sécurité.

8. Pourquoi la faille est particulièrement grave

8.1 Remise en question du modèle TPM-only

Le problème principal est le suivant :

BitLocker TPM-only repose sur l’idée que :

la machine physique est digne de confiance
le boot n’a pas été altéré
WinRE fait partie de cette chaîne de confiance

YellowKey montre qu’un composant de récupération pourrait suffire à casser ce modèle.

Cela remet directement en question :

les politiques de chiffrement d’entreprise
les modèles Zero Trust endpoint
les recommandations de déploiement Microsoft

9. Mitigations possibles

9.1 Utiliser TPM + PIN

L’ajout d’un PIN empêche le déverrouillage automatique du volume.

Même si certaines variantes évoquées par le chercheur prétendent contourner ce mécanisme, cela reste une défense importante.

9.2 Désactiver WinRE

Commande :

reagentc /disable

Cependant cela réduit fortement les capacités de récupération système.

9.3 Restreindre le boot externe

Dans l’UEFI :

désactivation du boot USB
mot de passe BIOS/UEFI
Secure Boot strict

9.4 Détection défensive

Les équipes SOC peuvent surveiller :

l’usage anormal de WinRE
les boots de récupération
les événements BitLocker inhabituels
les modifications dans System Volume Information

Partie II – GreenPlasma : élévation SYSTEM via CTFMON

1. Présentation générale

GreenPlasma est une vulnérabilité d’élévation de privilèges locale.

Contrairement à YellowKey, elle ne nécessite pas d’accès physique.

Le but de l’exploit est d’obtenir les droits NT AUTHORITY\SYSTEM.

Le vecteur d’attaque impliquerait :

ctfmon.exe
les objets Section du noyau Windows
la mémoire partagée
l’Object Manager

2. Comprendre CTFMON

2.1 Rôle du processus

ctfmon.exe appartient au système CTF (Collaborative Translation Framework).

Il gère notamment :

les méthodes de saisie ;
les IME ;
les claviers alternatifs ;
la reconnaissance vocale ;
les services linguistiques.

Le problème historique de CTFMON est qu’il interagit avec de nombreux processus de session utilisateur tout en disposant parfois de privilèges élevés.

3. Les objets Section dans Windows

3.1 Fonctionnement interne

Les objets Section sont des objets du noyau permettant :

le memory mapping
la mémoire partagée inter-processus
le chargement d’exécutables
les fichiers mappés

Ils sont créés via :

NtCreateSection()

et manipulés via :

NtMapViewOfSection()

L’Object Manager de Windows gère ces objets dans des namespaces internes comme :

\BaseNamedObjects
\Sessions
\KnownDlls

4. Hypothèse de fonctionnement de GreenPlasma

4.1 Primitive principale

Les descriptions publiques suggèrent que l’exploit :

force CTFMON à créer ou mapper une section mémoire
injecte un objet mémoire contrôlé
place cet objet dans un namespace privilégié
contourne les ACL normales
permet l’accès à des régions mémoire SYSTEM

Cela ressemble à une combinaison de :

namespace confusion
object squatting
section hijacking
trusted process abuse

5. Pourquoi CTFMON est une cible idéale

CTFMON possède plusieurs propriétés dangereuses :

communication inter-processus
interaction avec Win32k
confiance élevée
héritage historique
complexité énorme

Les composants d’input Windows ont historiquement été une surface d’attaque importante.

Des vulnérabilités similaires ont déjà impliqué :

ALPC
Win32k
clipboard
window messages
shared sections

6. Escalade vers SYSTEM

6.1 Objectif final

L’objectif probable est :

obtenir l’écriture dans une zone mémoire privilégiée
détourner un handle
injecter dans un processus SYSTEM
ou modifier des structures du noyau

Une fois SYSTEM obtenu, l’attaquant peut :

désactiver les EDR
voler des secrets LSASS
installer des rootkits
créer des comptes
persister au niveau machine

7. Analyse offensive

7.1 Chaîne d’exploitation réaliste

Une attaque moderne pourrait combiner :

une exécution de code utilisateur
GreenPlasma pour SYSTEM
dump LSASS
mouvement latéral
persistance

YellowKey et GreenPlasma deviennent particulièrement puissantes lorsqu’elles sont combinées.

Exemple :

YellowKey pour accéder physiquement à une machine chiffrée
GreenPlasma pour obtenir SYSTEM après ouverture de session

Partie III – Analyse sécurité et implications

1. Une tendance inquiétante

Ces vulnérabilités illustrent une tendance moderne : les attaques ciblent de plus en plus les frontières de confiance plutôt que la cryptographie elle-même.

Les systèmes modernes possèdent énormément de composants privilégiés :

TPM
hyperviseurs
recovery environments
drivers
services de compatibilité
objets noyau

Chaque composant introduit une nouvelle surface d’attaque.

2. Le problème des composants hérités

Windows transporte plusieurs décennies de compatibilité.

On retrouve encore aujourd’hui :

TxF
Win32k legacy
CTF
COM historiques
APIs NT natives

Ces composants anciens interagissent parfois avec des mécanismes modernes comme :

VBS
HVCI
TPM
Credential Guard

Cette cohabitation produit souvent des comportements inattendus.

3. Pourquoi ces vulnérabilités fascinent la recherche offensive

YellowKey et GreenPlasma sont techniquement intéressantes car elles montrent :

des abus de logique système
des erreurs de trust boundary
des mécanismes internes peu documentés
des primitives d’exploitation inhabituelles

On est loin des buffer overflows classiques, ces vulnérabilités relèvent davantage :

de l’ingénierie système
du reverse engineering avancé
de l’analyse du boot Windows
de l’étude du noyau NT

4. Conclusion

YellowKey et GreenPlasma rappellent une vérité fondamentale en cybersécurité : la robustesse d’un système ne dépend pas uniquement de la solidité de ses algorithmes cryptographiques, mais également de l’intégrité de toutes les chaînes de confiance qui les entourent.

YellowKey ne casse pas AES.
GreenPlasma ne compromet pas directement le noyau.

Pourtant, les deux vulnérabilités permettent des compromissions majeures parce qu’elles exploitent des hypothèses implicites dans l’architecture Windows.

Ces failles soulignent également les difficultés de sécurisation d’un système aussi vaste et historiquement complexe que Windows.

Entre compatibilité ascendante, environnements de récupération, composants hérités et objets noyau historiques, la surface d’attaque reste immense.

Pour les défenseurs, ces vulnérabilités rappellent l’importance :

du durcissement physique
des politiques BitLocker avancées
de la segmentation des privilèges
de la supervision des événements système
et de la réduction des composants exposés

Pour les chercheurs offensifs, elles constituent surtout un excellent exemple de ce qu’est réellement la sécurité moderne : une guerre permanente autour des frontières de confiance.