Connexion
BitLocker détourné avec une technique de mouvement latéral
Vous pensiez que BitLocker était votre ami ? Celui qui protège gentiment vos données avec son chiffrement intégral du disque ?
Eh bien, Fabian Mosch vient de prouver lors de la conférence Troopers 2025 qu’on pouvait le transformer en complice involontaire pour des attaques plutôt vicieuses. Le principe, c’est qu’au lieu d’attaquer BitLocker frontalement (ce qui serait suicidaire vu la robustesse du chiffrement), la technique consiste à détourner ses mécanismes internes pour exécuter du code malveillant.
Comment ?
Et bien en exploitant le fait que BitLocker cherche à charger des objets COM qui n’existent pas. C’est le fameux CLSID A7A63E5C-3877-4840-8727-C1EA9D7A4D50 que le processus BaaUpdate.exe essaie désespérément de trouver à chaque fois qu’il se lance.
L’astuce ici, c’est donc d’utiliser WMI (Windows Management Instrumentation) pour créer à distance cette clé de registre manquante et y glisser le chemin vers une DLL malveillante.
Comme ça, quand BitLocker démarre, il charge gentiment votre code en pensant que c’est un composant légitime. Et le plus magique c’est que tout s’exécute sous l’identité de l’utilisateur connecté.
Alors si c’est un admin du domaine, je vous raconte pas le jackpot ! Pour prouver que ce n’est pas que de la théorie, l’équipe de r-tec Cyber Security a développé BitLockMove, un outil qui automatise toute l’attaque.
Le mode énumération permet d’abord de scanner les sessions actives sur une machine distante grâce aux API non documentées de winsta.dll et une fois qu’on a repéré un utilisateur intéressant (genre DOMAINE\Administrateur), on passe en mode attaque.
La séquence d’attaque est assez cool d’ailleurs :
- Activation du service Remote Registry via WMI
- Création de la clé de registre piégée
- Déclenchement du processus BitLocker via l’interface BDEUILauncher
- Exécution du code malveillant dans le contexte de l’utilisateur ciblé
- Nettoyage des traces (suppression de la clé et de la DLL) Au fait, .
Ce qui rend cette technique particulièrement sournoise, c’est qu’elle abuse de processus Microsoft signés et légitimes. Par exemple, il y a BdeUISrv.exe, le processus qui finit par exécuter votre code, qui est un binaire officiel de Windows. Pour un EDR lambda, ça ressemble donc à du comportement normal de BitLocker.
Toutefois, ce n’est pas non plus la panacée pour les attaquants car il faut déjà avoir des privilèges d’administrateur local sur la machine cible. Ensuite, toute cette gymnastique laisse des traces exploitables. Le service Remote Registry qui passe de “désactivé” à “actif” puis retourne à “désactivé” en quelques secondes, c’est louche.
Les événements Windows 4657, 4660 et 4663 sur les clés de registre BitLocker, c’est donc un red flag énorme, sans parler des processus baaupdate.exe et BdeUISrv.exe qui apparaissent dans des contextes inhabituels.
Pour les défenseurs qui veulent mater leurs logs, voici les points de surveillance critiques :
- Event ID 7040 pour les changements d’état du service Remote Registry
- Surveillance des créations/suppressions sous HKEYCURRENTUSER\SOFTWARE\Classes\CLSID{A7A63E5C-3877-4840-8727-C1EA9D7A4D50}
- Processus BdeUISrv.exe lancé par svchost.exe (au lieu du comportement normal)
- Chargement des DLL winsta.dll ou wtsapi32.dll par des processus non standards
L’article original propose même des règles SIGMA toutes prêtes et des requêtes KQL pour Microsoft Defender for Endpoint. C’est du clé en main pour les équipes SOC qui veulent détecter cette technique.
Comme d’hab, la sécurité Windows reste un casse-tête car chaque fonctionnalité légitime introduit de nouvelles surfaces d’attaque. BitLocker protège vos données au repos, mais ses mécanismes internes deviennent des vecteurs d’attaque pour du “mouvement latéral” (c’est comme ça qu’on dit).
Pour ceux qui veulent creuser le sujet, le code de BitLockMove est disponible sur GitHub. Mais comme toujours avec ce genre d’outils, utilisez-le uniquement dans un cadre légal (tests d’intrusion autorisés, labos de recherche, etc.) sinon, vous allez finir en prison !!
Maintenant, reste à voir combien de temps il faudra à Microsoft pour patcher ce comportement… s’ils considèrent ça comme un bug, hein, et pas juste comme une “fonctionnalité” du système COM. On verra bien…
