BYOVD : comment les ransomwares tuent vos EDR en 2026

Vos EDR coûtent des dizaines de milliers d'euros. Des groupes comme Warlock les désactivent en cinq minutes avec un pilote Windows signé et certifié. Bienvenue dans l'ère du BYOVD — Bring Your Own Vulnerable Driver — la technique qui rend vos outils de détection inutiles avant même que l'attaque commence.

Ce qu'est le BYOVD, et pourquoi c'est différent d'un simple exploit

Le BYOVD (Bring Your Own Vulnerable Driver) n'est pas une nouveauté. Les chercheurs en sécurité discutent de cette technique depuis 2018, et les premiers cas documentés d'exploitation par des acteurs malveillants remontent à 2020-2021. Mais en 2026, le BYOVD est devenu une tactique standard, banalisée, présente dans les playbooks d'au moins une douzaine de groupes cybercriminels et APT actifs. Ce qui était une technique d'élite est désormais une routine.

La logique est simple mais redoutable. Windows impose depuis Vista une exigence stricte : les pilotes noyau (kernel drivers) doivent être signés numériquement par une autorité de certification reconnue pour pouvoir être chargés. Cette exigence, renforcée avec Secure Boot et Driver Signature Enforcement (DSE), avait pour but d'empêcher les rootkits de s'installer en mode noyau. Et ça marche — écrire un pilote malveillant non signé et le faire charger par un Windows moderne est extrêmement difficile.

Le BYOVD contourne cette protection avec élégance. Au lieu d'écrire un pilote malveillant non signé, l'attaquant apporte son propre pilote — légitimement signé, sorti des lignes de production d'un éditeur respectable de logiciels de sécurité, d'utilitaires système, de solutions industrielles. Ce pilote est parfaitement valide aux yeux de Windows. Mais il contient une vulnérabilité connue qui, exploitée depuis le userspace, permet d'exécuter du code arbitraire en mode noyau.

Une fois en mode noyau, l'attaquant est au-dessus de tout. L'EDR qui surveille les processus tourne en userspace, ou au mieux en kernel space mais sans les privilèges nécessaires pour résister à une attaque depuis le Ring 0. L'antivirus idem. En quelques lignes de code, l'attaquant peut terminer les processus de protection, désactiver leurs pilotes de filtre système, et effacer leur présence. En 2026, cette opération prend quelques minutes et est entièrement scriptable.

Le catalogue des pilotes vulnérables : une arme collective et publique

Ce qui rend le BYOVD particulièrement dangereux, c'est que l'arsenal des pilotes exploitables est immense — et public. Le projet LOLDrivers (Living Off the Land Drivers), maintenu par la communauté cybersécurité, référence aujourd'hui plus de 1 200 pilotes Windows légitimes présentant des vulnérabilités exploitables pour le BYOVD. Ces pilotes viennent de chez ASUS, MSI, Gigabyte, Lenovo, Dell, Nvidia, mais aussi d'éditeurs de sécurité comme Trend Micro, Avast, ou K7 Security.

K7RKScan.sys — le pilote utilisé par Warlock dans ses attaques d'octobre 2026 — fait partie de cette liste. Il s'agit d'un composant de K7 Total Security, une suite de sécurité indienne distribuée dans de nombreux pays. Le pilote a été identifié comme vulnérable depuis plusieurs mois. Microsoft l'a ajouté à sa Vulnerable Driver Blocklist, disponible depuis Windows 11 22H2. Mais combien d'organisations ont activé cette protection ? Très peu.

La liste de blocage de Microsoft n'est pas activée par défaut sur Windows Server, les versions les plus courantes en entreprise. Elle requiert l'activation d'HVCI (Hypervisor-Protected Code Integrity), une fonctionnalité de virtualisation qui n'est pas supportée par tous les équipements matériels et qui peut engendrer des baisses de performance. Les DSI font alors un choix : activer HVCI et risquer des incompatibilités, ou ne pas l'activer et rester vulnérable au BYOVD. En 2026, la majorité choisit encore l'inaction.

La situation est aggravée par le fait que certains éditeurs tardent à révoquer les certificats de signature de leurs pilotes vulnérables. Un pilote signé avec un certificat non révoqué reste utilisable, même si la vulnérabilité est connue et documentée. Les attaquants maintiennent des collections de pilotes dont les certificats sont encore valides — une forme d'armes numériques stockées et prêtes à l'emploi.

Warlock et le BYOVD industriel : ce que ça révèle sur la maturité des attaquants

L'utilisation du BYOVD par Warlock dans ses attaques sur les infrastructures critiques en octobre 2026 illustre parfaitement la maturité opérationnelle des groupes ransomware modernes. Ce n'est plus l'image du hacker solitaire bricolant des outils dans sa chambre. Warlock opère comme une organisation criminelle structurée, avec des spécialistes de l'intrusion initiale (SharePoint ToolShell), des opérateurs responsables de l'escalade de privilèges (BYOVD via K7RKScan.sys), et des équipes de déploiement de ransomware (distribution via SYSVOL).

Ce découpage en phases spécialisées est caractéristique des groupes dits "tier 1" dans la taxonomie des acteurs ransomware. L'accès initial via SharePoint peut être vendu sur les marchés d'Initial Access Brokers (IAB) si le groupe décide de ne pas l'exploiter lui-même. La phase BYOVD peut être confiée à un opérateur spécialisé dans la désactivation des outils de sécurité. Le déploiement du ransomware est l'étape finale, exécutée une fois le terrain préparé.

Cette fragmentation de la chaîne d'attaque a une conséquence directe sur la détection : aucune phase ne ressemble à une attaque complète prise isolément. Le chargement de K7RKScan.sys peut ressembler à un problème de compatibilité logicielle. La création de GPO dans SYSVOL peut ressembler à une opération d'administration légitime. La difficulté est de corréler ces événements discrets pour les reconnaître comme les étapes d'une même chaîne d'attaque. C'est précisément là que les SIEM avec des règles de corrélation adaptées prennent tout leur sens.

Pourquoi vos outils ne détectent pas le BYOVD — et ce qu'il faut changer

La question que les RSSI devraient poser à leurs fournisseurs EDR est directe : est-ce que votre solution détecte le chargement de pilotes vulnérables référencés dans LOLDrivers ? Et si un de ces pilotes est exploité pour désactiver votre EDR, qu'est-ce qui se passe ?

La réponse honnête, pour la grande majorité des solutions, est inconfortable. La détection du BYOVD dépend de l'existence de règles spécifiques pour chaque pilote vulnérable. Ces règles existent pour les pilotes les plus connus — certains EDR détectent et bloquent le chargement de K7RKScan.sys. Mais la liste des pilotes vulnérables s'allonge constamment. Les attaquants testent en permanence quels pilotes passent sous le radar des solutions déployées chez leurs cibles. C'est un jeu du chat et de la souris que les défenseurs ne peuvent pas gagner avec une approche purement réactive.

Il existe une stratégie défensive plus robuste que la détection signature-par-signature : la liste blanche de pilotes (driver allowlisting). Au lieu de bloquer les pilotes connus comme mauvais, on n'autorise que les pilotes connus comme nécessaires. Cette approche est beaucoup plus difficile à contourner — si un pilote inconnu (même signé) est chargé, il est bloqué par défaut. HVCI avec une politique de liste blanche stricte représente le niveau de protection le plus élevé contre le BYOVD.

Le problème est opérationnel. Dans un parc de plusieurs centaines de serveurs, maintenir une liste blanche de pilotes autorisés est une tâche complexe qui génère des alertes opérationnelles et des incidents de compatibilité. C'est un coût réel, qui doit être mis en balance avec le coût d'une compromission par ransomware — chiffré en moyenne à 4,9 millions d'euros pour une PME selon le rapport Sophos 2026.

L'angle que personne ne regarde : la responsabilité des éditeurs

Il y a un angle qui reste sous-traité dans les discussions sur le BYOVD : la responsabilité des éditeurs de logiciels dont les pilotes sont exploités. Quand K7RKScan.sys sert à désactiver des EDR dans des hôpitaux ou des opérateurs d'eau, qui porte la responsabilité ?

Légalement, pour l'instant, personne ne force les éditeurs à révoquer rapidement les certificats de signature de pilotes vulnérables. Microsoft maintient une liste de blocage, mais c'est une mesure volontaire et non obligatoire. La NIS2, qui impose des exigences de cybersécurité renforcées pour les opérateurs de services essentiels en Europe, commence à créer une pression indirecte sur les fournisseurs logiciels qui n'appliquent pas les bonnes pratiques de cycle de vie de leurs composants signés.

Mais la véritable pression devrait venir des acheteurs. Dans les appels d'offres pour des suites de sécurité, la question devrait être posée explicitement : votre éditeur dispose-t-il d'une procédure de révocation des certificats de pilotes en cas de divulgation de vulnérabilité ? Sous quel délai ? Ces questions ne sont quasiment jamais posées aujourd'hui.

Ce qui va changer dans les 6 prochains mois

Microsoft a annoncé une mise à jour de la politique HVCI pour Windows Server 2025 qui activera par défaut la liste de blocage des pilotes vulnérables, sans nécessiter l'activation complète d'HVCI. Cette mesure, moins contraignante sur les performances, devrait couvrir les cas les plus courants de BYOVD si elle est correctement déployée.

Plusieurs éditeurs EDR de premier rang travaillent sur des mécanismes de "tamper protection" renforcés au niveau noyau, conçus spécifiquement pour résister aux tentatives BYOVD. Ces protections utilisent des techniques de virtualisation pour isoler les composants critiques de l'EDR dans un environnement protégé. L'efficacité réelle sera à évaluer sur le terrain — les groupes comme Warlock s'adapteront rapidement.

L'ANSSI devrait publier d'ici fin 2026 un guide opérationnel sur la gestion des pilotes Windows dans les systèmes critiques, dans le cadre des travaux NIS2. Ce guide devrait inclure des recommandations concrètes sur HVCI et la gestion des pilotes vulnérables pour les OIV et OSE français.

Conclusion

Le BYOVD a transformé la relation entre les outils de sécurité et les attaquants. Ce que vous avez payé pour vous protéger peut être retourné contre vous avec un fichier .sys signé et quelques lignes de code. La réponse n'est pas d'abandonner les EDR — ils restent utiles contre un spectre large de menaces. La réponse est de comprendre leurs limites et de construire des défenses complémentaires : durcissement noyau, gestion stricte des pilotes, surveillance du SYSVOL, et segmentation réseau. Face à des groupes comme Warlock qui opèrent avec une efficacité d'entreprise, l'improvisation ne suffit plus.