Une recherche menée par Check Point Research met en lumière une méthode inattendue : il serait possible de transformer BTR.sys détourné, un pilote utilisé par Microsoft Defender pour des tâches de remédiation au démarrage, en outil d’exécution d’actions arbitraires au niveau du noyau. L’angle surprenant tient au fait qu’il ne s’agit pas d’une faille « classique » exploitant un bug, mais d’un détournement d’un composant déjà présent sur les machines.
Selon le rapport, cette approche viserait des systèmes allant de Windows 7 jusqu’à Windows 11 (jusqu’à la version 25H2), en s’appuyant sur un pilote embarqué et légitimement signé. Check Point indique n’avoir trouvé aucune preuve d’usage dans des attaques réelles au moment de l’étude, ce qui rendrait la détection proactive particulièrement pertinente.
Pourquoi BTR.sys intéresse autant les chercheurs
Le cœur du sujet est le pilote BTR.sys, aussi appelé Boot Time Removal Tool. Il s’agit d’un composant requis de Windows utilisé lorsque Defender doit terminer la suppression de certains éléments après un redémarrage. Concrètement, il efface des fichiers ou des entrées de registre qui étaient verrouillés pendant que Windows tournait.
Du point de vue de la défense, ce point change la donne : puisque le pilote fait partie du fonctionnement normal, il ne peut pas être simplement ajouté à une liste de blocage de pilotes vulnérables, et le filtrage via les mécanismes prévus pour contrôler les composants approuvés peut être délicat. Check Point souligne que toute tentative de blocage risquerait d’entraver Defender lui-même.
Une technique de « remédiation au boot » détournable
Check Point explique que BTR.sys est intégré dans MpEngine.dll de Defender. Le pilote est déployé quand l’éditeur antivirus a besoin d’effectuer des opérations en toute fin de processus, précisément au moment où certains verrous ne sont plus actifs.
Le chercheur Jiří Vinopal, reverse engineer chez Check Point, affirme avoir reconstruit un protocole de transactions propriétaire et non documenté. L’idée est la suivante : en fournissant des « blobs » de configuration selon le format attendu par le pilote, on pourrait déclencher des actions arbitraires.
Le protocole chiffré et le rôle de la clé
Un détail technique ressort : chaque configuration transmise à BTR.sys serait chiffrée avec RC4. La clé, indique Check Point, est de 256 octets et serait codée en dur dans la section .rdata de chaque version de BTR.sys livrée depuis Windows 7. La même clé aurait été retrouvée inchangée sur 18 versions 64 bits étudiées.
Cette régularité facilite la construction de transactions valides, ce qui réduit l’incertitude pour un attaquant potentiel disposant déjà des bons privilèges.
BTR_CLI : une preuve de concept opérationnelle
Pour illustrer la faisabilité, Check Point publie une preuve de concept nommée BTR_CLI. L’outil localise MpEngine.dll dans les mises à jour des définitions Defender, extrait le binaire BTR.sys embarqué, puis construit une transaction chiffrée conforme.
Ensuite, l’installation du pilote passe par des écritures directes dans le registre, avec un positionnement particulier des paramètres. L’approche mise en avant par Check Point évite d’utiliser le Service Control Manager et ne générerait pas l’entrée habituelle associée à l’installation d’un service (mentionnée via l’absence de l’événement classique côté Windows).
Ce que BTR.sys peut faire une fois chargé
Lorsque le pilote est exécuté, Check Point décrit une exécution en mode noyau (Ring 0), attribuée dans les traces à le processus System (PID 4). À partir de là, les opérations mises dans la file (queued operations) peuvent inclure :
- la suppression de fichiers et de répertoires même verrouillés ;
- le déplacement de fichiers vers des chemins non contraints, y compris System32\drivers ;
- la suppression de clés et valeurs de registre ;
- l’écriture de nouvelles valeurs de registre, quel que soit leur type.
La technique prévoit aussi un second mode : au lieu d’exécuter immédiatement, elle planifie les actions pour le prochain redémarrage. Le facteur temps devient alors crucial.
La « golden window » avant le démarrage complet de Defender
Vinopal décrit une fenêtre stratégique : la période après le moment où le système de fichiers est à nouveau accessible, mais avant le lancement complet des services Defender côté utilisateur. Check Point appelle cette phase la « golden window ».
Dans cette fenêtre, BTR.sys pourrait retirer physiquement des binaires de sécurité avant qu’ils ne se verrouillent et se protègent eux-mêmes. La démonstration effectuée lors d’événements comme Black Hat USA 2026 et DEF CON 34 aurait montré la suppression de la pile Defender sur une machine Windows 11 25H2 maintenue à jour, avec la Tamper Protection active.
Conditions d’exploitation : privilèges administrateur
Check Point insiste sur un point : l’exploitation nécessite un compte disposant de SeLoadDriverPrivilege. L’outil BTR_CLI activerait automatiquement ce privilège lorsque le compte le possède déjà.
Ce cadrage est important car il diffère d’autres scénarios souvent associés à des attaques exploitant des pilotes signés vulnérables tiers. Ici, l’approche reposerait sur un pilote déjà présent et intégré à l’environnement Windows, ce qui modifie l’angle de la défense.
Réponse de Microsoft et statut de correctif
Après le responsible disclosure, MSRC aurait confirmé que les résultats ne répondaient pas aux critères d’une correction immédiate. La raison avancée est que la technique dépendrait d’un état préalable : la présence de privilèges administrateur et de SeLoadDriverPrivilege.
Dans sa publication, le dépôt GitHub de BTR_CLI mentionne qu’aucun patch n’est prévu. Microsoft n’aurait pas confirmé publiquement cette absence de correctif au moment de la rédaction.
Pourquoi la recherche estime le risque « exploitable mais pas observé »
Check Point dit ne pas avoir observé d’abus réel de BTR.sys dans les échantillons et sources de télémétrie collectés. L’entreprise en tire une conclusion pratique : la technique pourrait être inconnue ou inutilisée par des acteurs malveillants, ce qui laisse une marge pour développer des capacités de détection avant une éventuelle généralisation.
La recherche précise également une origine inhabituelle. Elle aurait commencé pendant une investigation d’incident : des signaux de télémétrie endpoint semblaient suspects, mais auraient finalement été rattachés à des activités légitimes de remédiation de Defender.
Indicateurs Sysmon et événements Windows à surveiller
Pour aider les équipes de sécurité, Check Point liste plusieurs conditions pouvant signaler un BTR.sys détourné. Les indicateurs s’appuient sur des traces Sysmon et des événements Windows, notamment :
- Sysmon Event ID 15 (FileCreateStreamHash) lorsque le nom cible finit par .sys:changelist, correspondant à l’écriture d’une configuration chiffrée via un Alternate Data Stream ;
- Sysmon Event ID 12 ou 13 (RegistryEvent) créant une clé de service dont la valeur Args contient :changelist et dont le Group est Boot Bus Extender, surtout si cela n’est pas accompagné de l’événement Windows habituel lié à l’installation de service ;
- Sysmon Event IDs 11 (FileCreate) et 23 (FileDelete) qui reflètent une création puis une suppression rapide de \SystemRoot\Temp\BootClean.log par le processus System (PID 4) ;
- Sysmon Event ID 6 (DriverLoad) suivi immédiatement de Sysmon Event ID 23 (FileDelete), toujours attribués à System (PID 4), constituant un « fingerprint » d’exécution côté noyau.
Le message de fond est clair : même si l’activité s’appuie sur un composant légitime, le chaînage des événements et la présence de certains chemins/valeurs peuvent rendre l’abus plus détectable.
Recommandation principale : réduire SeLoadDriverPrivilege
En termes de durcissement, Check Point recommande de limiter l’attribution de SeLoadDriverPrivilege comme contrôle prioritaire. L’objectif est de réduire la surface d’attaque, puisque la technique dépend de la capacité à charger un pilote.
Cette approche se situe au niveau des politiques et des droits, plutôt qu’au niveau d’une suppression de composant. Elle vise donc à rendre plus difficile toute action malveillante reposant sur ce mécanisme.
Leçons à retenir pour la sécurité des endpoints
Le cas de BTR.sys détourné illustre une idée importante : la présence d’un élément signé et intégré à Windows ou à Defender ne garantit pas automatiquement qu’il ne puisse jamais être utilisé dans un scénario offensif. Ce qui compte aussi, ce sont les frontières de confiance, les privilèges requis et la manière dont les opérations sont orchestrées au bon moment.
Dans l’immédiat, l’enjeu pour les équipes de défense consiste à deux choses : d’une part, renforcer la gouvernance des droits comme SeLoadDriverPrivilege, et d’autre part, préparer des règles de détection basées sur les enchaînements d’événements Sysmon/Windows mentionnés par Check Point. Même sans preuve d’exploitation réelle, l’anticipation reste utile.
Enfin, même si l’étude n’indique pas d’usage observé, elle rappelle qu’une technique peut rester « en attente » tant que les conditions nécessaires ne sont pas réunies. La meilleure défense consiste souvent à réduire ces conditions avant qu’un acteur ne les exploite.
Source: https://thehackernews.com/2026/08/microsoft-defenders-own-driver-can-be.html
