Disposer d’un EDR n’est plus une garantie. Dans des attaques récentes, les affiliés de Qilin déploient un module dédié capable de désactiver plus de 300 solutions de détection et réponse aux menaces (EDR), couvrant la quasi-totalité des éditeurs du marché. Cisco Talos, qui a publié une analyse technique approfondie le 2 avril 2026, décrit non pas un simple outil de contournement, mais une chaîne d’infection en quatre stades. Le composant ne s’improvise pas en cours d’attaque : il opère entièrement en mémoire, exploite des pilotes signés légitimes pour descendre au niveau du noyau Windows, et coupe les mécanismes de surveillance des EDR avant même que le vol de données ou le chiffrement ne commence. Les processus de sécurité sont terminés, leurs rapports de télémétrie interrompus, le tout sans qu’une seule alerte ne soit générée.
Qilin, également traqué sous les noms Agenda, Gold Feather et Water Galura, opère en RaaS depuis juillet 2022. Le groupe s’est imposé comme l’un des acteurs les plus actifs du paysage ransomware, avec une présence internationale marquée et une concentration sur les secteurs manufacturier et des services professionnels. Son infrastructure RaaS attire un nombre croissant d’affiliés disposant de compétences techniques variées.
L’analyse de Talos met en lumière une réalité que les statistiques de victimologie ne suffisent pas à exprimer : lorsqu’un attaquant neutralise la couche défensive elle-même au niveau du noyau, la question n’est plus la capacité de détection des EDR, mais l’existence de défenses indépendantes capables de fonctionner sans eux.
La neutralisation des EDR, condition préalable aux opérations ransomware
La désactivation des défenses endpoint n’est plus improvisée en cours d’attaque. Chez plusieurs opérateurs de ransomware, elle est planifiée et intégrée à la chaîne d’infection dès l’accès initial. Le groupe Play, par exemple, a abandonné les méthodes classiques d’arrêt de processus au profit de la suppression physique des fichiers d’agents de sécurité via des utilitaires légitimes de gestion de disque, contournant ainsi la télémétrie de terminaison de processus sans déclencher les signaux habituellement surveillés. D’autres opérations, comme BlackSanta, ciblent les postes RH via des leurres de candidature pour neutraliser les EDR avant toute exfiltration. Chaque groupe adapte son EDR killer à son vecteur d’attaque.
Ce que Qilin a développé est d’une autre nature. L’architecture fonctionne entièrement en mémoire pour les stades critiques, exploite des pilotes signés pour descendre au niveau du noyau, et désactive les callbacks de surveillance (les fonctions que les EDR enregistrent auprès du noyau Windows pour être alertés de chaque création de processus, de thread ou de chargement de module). Une fois ces callbacks neutralisés, les solutions de sécurité n’ont plus aucune visibilité sur ce qui se passe sur le système, et l’opérateur peut engager librement la phase d’exfiltration ou de chiffrement.
Stade 1 : comment la DLL piégée déjoue la surveillance des EDR
Side-loading de msimg32.dll : un point d’entrée silencieux
Tout commence par une DLL malveillante nommée msimg32.dll, side-loadée (chargée en lieu et place de la bibliothèque légitime) par une application qui importe normalement cette bibliothèque système Windows. Les appels légitimes à l’API originale sont redirigés vers la vraie msimg32.dll dans C:\\Windows\\System32, préservant le comportement attendu de l’application hôte, tandis que la logique malveillante s’exécute dès le chargement via la fonction DllMain. Ce premier stade ne touche aucun binaire sur le disque : il prépare entièrement en mémoire l’environnement d’exécution pour les stades suivants.
Halo’s Gate : contourner les hooks EDR sans les modifier
Pour échapper aux hooks EDR (points de surveillance), le chargeur PE (le module d’exécution en mémoire) implémente une variante de la technique Halo’s Gate. Plutôt que de modifier les stubs (points d’entrée) hookés de ntdll.dll, il scanne en avant et en arrière pour localiser des stubs syscall voisins intacts, récupère l’identifiant syscall correct dans le registre eax, puis transite directement en mode noyau via l’instruction syscall d’un stub propre. Le noyau Windows n’évalue que l’identifiant dans eax et ne vérifie pas depuis quelle fonction exportée l’appel a été initié, une lacune architecturale que le malware exploite méthodiquement.
Neutralisation de la télémétrie et masquage du flux de contrôle
La télémétrie ETW (Event Tracing for Windows) est neutralisée en ciblant spécifiquement les stubs NtTraceEvent, NtTraceControl et NtAlpcSendWaitReceivePort. Sans cette télémétrie, les EDR perdent leur principale source d’information sur l’activité du système.
Pour masquer le flux de contrôle, le chargeur détourne le gestionnaire d’exceptions de ntdll.dll en rendant la section .mrdata accessible en écriture via ntdll!LdrProtectMrdata, une fonction non exportée que le malware localise indirectement à partir d’une autre fonction utilisée comme ancre. Il substitue son propre handler, de sorte que chaque exception déclenche son code. Les mécanismes SEH (Structured Exception Handling) et VEH (Vectored Exception Handling) sont ainsi détournés pour dissimuler les patterns d’appel aux API, une technique qui rend l’analyse dynamique considérablement plus complexe pour les défenseurs comme pour les chercheurs.
Le chargeur inclut aussi un mécanisme de géo-ciblage : il termine son exécution si le système est configuré pour une langue des pays de l’ex-Union soviétique, signal caractéristique d’un acteur russophone.
Stades 2 et 3 : du détournement silencieux au chargement en mémoire
Stade 2 : un hook discret sur la terminaison du processus
Le deuxième stade est minimaliste mais critique : il accroche l’entrée ExitProcess dans l’IAT (Import Address Table) du processus principal pour rediriger l’exécution vers le stade 3 lors de la terminaison du processus. DllMain se termine normalement, sans anomalie visible. La charge utile ne s’active que plus tard, un choix de conception qui rend le comportement malveillant invisible aux outils d’analyse qui se concentrent sur la phase de chargement initial.
Stade 3 : un PE chargé intégralement en mémoire
Le troisième stade décompresse et charge une image PE (Portable Executable, format standard des programmes Windows) entièrement en mémoire, sans jamais l’écrire sur le disque. La technique est particulièrement sophistiquée : plutôt que de charger directement le PE, le malware mappe shell32.dll en mémoire, écrase son contenu avec l’image PE décodée, puis utilise des hardware breakpoints sur ntdll!NtOpenSection et ntdll!NtMapViewOfSection pour détourner les mécanismes internes du chargeur Windows (LdrpMinimalMapModule). Le résultat : un exécutable complet tourne en mémoire sous le couvert d’une bibliothèque système légitime.
Dans une note anecdotique, l’auteur du malware a délibérément nommé l’appel de DLL factice en référence à une chercheuse en sécurité connue, un geste que Talos interprète comme une provocation intentionnelle. L’image chargée constitue le stade 4 : l’EDR killer lui-même.
Stade 4 : l’EDR killer, du pilote vulnérable à la neutralisation des défenses
BYOVD et rwdrv.sys : accéder à la mémoire physique via un pilote signé
Une fois le PE de l’EDR killer en mémoire, la tactique change de registre. Le composant s’appuie sur la technique BYOVD (Bring Your Own Vulnerable Driver) et charge une version renommée de rwdrv.sys, pilote développé par TechPowerUp LLC pour son outil de diagnostic matériel ThrottleStop. Ce pilote, signé numériquement avec un certificat valide et également utilisé par l’utilitaire GPU-Z, ce qui lui confère une légitimité apparente aux yeux des systèmes de contrôle de signature Windows. Cisco Talos note que malgré son origine bénigne, ce pilote expose des fonctionnalités hautement privilégiées sans imposer de contrôles de sécurité significatifs.
Via des interfaces IOCTL (input/output control), rwdrv.sys offre un accès direct aux ports matériels, aux registres spécifiques au processeur (MSR) et surtout à la mémoire physique brute. C’est là que réside l’ingéniosité de l’approche : plutôt que de modifier les processus EDR dans l’espace virtuel (ce qui déclencherait des alertes), le malware localise les structures de données critiques des drivers EDR dans la mémoire physique et les réécrit directement, sans jamais toucher les images binaires sur le disque.
Concrètement, le composant itère à travers une liste de plus de 300 pilotes de sécurité couvrant pratiquement tous les éditeurs du marché. Pour chacun, il localise les pointeurs de callbacks dans la mémoire physique, les callbacks de création de processus, de création de thread et de chargement d’image que les solutions EDR utilisent pour surveiller le système, et les remplace par des pointeurs vides ou des routines inoffensives. L’EDR est rendu inopérant sans que son processus ait été touché, une distinction technique qui explique pourquoi cette attaque échappe aux mécanismes classiques de protection des processus.
Un pilote déjà exploité par d’autres groupes
L’abus de rwdrv.sys n’est pas une exclusivité de Qilin : des affiliés du groupe Akira ont également exploité ce même pilote pour neutraliser Microsoft Defender, une technique observée dès la mi-juillet 2025 selon GuidePoint Security. Le vecteur est partagé dans l’écosystème ransomware, ce qui renforce l’urgence de bloquer ce pilote spécifique et plus largement, d’adopter une stratégie de défense qui ne dépend pas d’une seule couche. Qilin lui-même diversifie ses approches : le groupe a également déployé une variante Linux sur Windows pour contourner les défenses centrées sur un seul OS, là où l’EDR killer documenté ici cible exclusivement l’espace noyau Windows.
Terminaison des processus et restauration furtive
Une fois les callbacks désactivés, un second driver auxiliaire, hlpdrv.sys, entre en jeu. Via l’IOCTL code 0x2222008, ce driver force la terminaison des processus de sécurité actifs, y compris Windows Defender, qui ne bénéficient plus de la protection de leurs callbacks. Les processus EDR s’arrêtent sans pouvoir générer d’alerte ni se relancer.
Une dernière étape, contre-intuitive, vient clore la séquence : le malware restaure le callback CiValidateImageHeader (la fonction de vérification d’intégrité du code que Windows utilise pour valider les images chargées dans le noyau), qu’il avait précédemment court-circuité en substituant au pointeur une routine qui renvoie true en toutes circonstances . Cette restauration réduit les traces laissées dans le noyau et traduit une attention particulière à l’hygiène post-exploitation, un niveau de discipline rarement observé dans les kits ransomware courants.
Le signal d’alarme pour la défense en profondeur
Le fait que Qilin parvienne à désactiver plus de 300 solutions EDR via une simple DLL malveillante constitue un important signal d’alarme. Si l’ensemble de la stratégie de détection repose sur des agents de terminaux susceptibles d’être neutralisés au niveau du noyau, l’organisation se retrouve sans visibilité au moment précis où elle en a le plus besoin. La mise en place d’une surveillance de l’intégrité au niveau du noyau et d’une détection comportementale basée sur le réseau n’est pas un complément optionnel : ce sont les couches qui continuent de fonctionner quand l’agent endpoint a été réduit au silence. C’est la conclusion opérationnelle la plus directe de l’analyse de Talos, et la plus urgente à mettre en œuvre.
Indicateurs de compromission publiés par Cisco Talos
| Composant | Type | MD5 | SHA1 | SHA256 |
|---|---|---|---|---|
| msimg32.dll | DLL malveillante (stade 1) | 89ee7235906f7d12737679860264feaf | 01d00d3dd8bc8fd92dae9e04d0f076cb3158dc9c | 7787da25451f5538766240f4a8a2846d0a589c59391e15f188aa077e8b888497 |
| rwdrv.sys | Pilote légitime abusé | 6bc8e3505d9f51368ddf323acb6abc49 | 82ed942a52cdcf120a8919730e00ba37619661a3 | 16f83f056177c4ec24c7e99d01ca9d9d6713bd0497eeedb777a3ffefa99c97f0 |
| hlpdrv.sys | Driver de terminaison de processus | cf7cad39407d8cd93135be42b6bd258f | ce1b9909cef820e5281618a7a0099a27a70643dc | bd1f381e5a3db22e88776b7873d4d2835e9a1ec620571d2b1da0c58f81c84a56 |
| EDRKiller.exe | Dump mémoire (stade 4) | 1305e8b0f9c459d5ed85e7e474fbebb1 | 84e2d2084fe08262c2c378a377963a1482b35ac5 | 12fcde06ddadf1b48a61b12596e6286316fd33e850687fe4153dfd9383f0a4a0 |
EDRKiller.exe (métadonnées complémentaires) :
ImpHash 05aa031a007e2f51e3f48ae2ed1e1fcb · Timestamp de compilation : 14 juin 2025, 08:33:52 UTC
Le timestamp de compilation indique que le composant a été développé près de dix mois avant sa documentation publique en avril 2026, confirmant une période d’utilisation opérationnelle significative.
ClamAV détecte ce composant sous les signatures Win.Malware.Bumblebee-10056548-0, Win.Tool.EdrKiller-10059833-0 et Win.Tool.ThrottleStop-10059849-0. Les règles Snort2 SIDs 1:66181 et 1:66180, ainsi que la règle Snort3 SID 1:301456, couvrent cette menace.
Comment se protéger face à une attaque qui opère dans le noyau
Face à une chaîne d’infection conçue pour opérer entièrement en mémoire et contourner les hooks EDR, la défense en profondeur n’est pas un principe abstrait.
1. Bloquer le chargement de drivers vulnérables connus
Microsoft publie et met à jour une liste de drivers vulnérables dans le cadre du programme Vulnerable Driver Blocklist. Son déploiement via Windows Defender Application Control (WDAC) ou les politiques de pilotes signés réduit significativement la surface BYOVD. La liste doit inclure rwdrv.sys et ses hachages connus.
2. Activer HVCI pour empêcher les attaques BYOVD
Hypervisor-Protected Code Integrity (HVCI) empêche le chargement de drivers non signés ou figurant sur la liste de blocage au niveau de l’hyperviseur, rendant les attaques BYOVD considérablement plus difficiles même en cas de compromission locale. C’est la mesure la plus directe contre le vecteur exploité par Qilin.
3. Surveiller le side-loading de DLL
Le chargement de msimg32.dll depuis un répertoire autre que C:\\Windows\\System32 par une application légitime constitue un signal d’attaque précoce, et potentiellement le seul observable avant que la chaîne d’infection ne bascule en mémoire. Les règles de détection Snort publiées par Talos couvrent cet indicateur.
4. Maintenir une visibilité indépendante de l’agent endpoint
Cisco Talos recommande explicitement une approche multi-couches. Journalisation centralisée (SIEM), surveillance comportementale réseau et segmentation constituent des filets de sécurité indépendants qui conservent leur utilité même si l’EDR est neutralisé. Quand la couche endpoint est compromise, ce sont ces dispositifs qui font la différence entre une détection tardive et une absence totale de visibilité.
5. Limiter les droits administrateurs locaux
L’ensemble de la chaîne d’infection Qilin nécessite des privilèges administrateurs pour s’exécuter. Réduire le nombre de comptes disposant de ces droits via PAM (Privileged Access Management) limite directement la surface d’exploitation, et constitue le levier préventif le plus simple à activer.
La guerre aux EDR, une tendance structurelle du ransomware
Le module documenté par Cisco Talos s’inscrit dans une tendance lourde où la neutralisation des agents de sécurité est devenue une condition préalable à toute opération ransomware sérieuse. Le timestamp de compilation du composant EDR killer (juin 2025) indique que cette capacité a été développée et affinée sur plusieurs mois avant sa documentation publique.
L’escalade est structurelle : à mesure que les EDR modernes améliorent leur détection comportementale, les groupes ransomware montent d’un niveau en ciblant directement la couche défensive plutôt que de l’esquiver. La sophistication technique illustrée par la chaîne en quatre stades de Qilin, Halo’s Gate, hooks SEH/VEH, BYOVD via mémoire physique, témoigne d’investissements en R&D qui dépassent largement le cadre d’un simple kit RaaS standard. Pour les équipes de sécurité, la question n’est plus de savoir si leurs EDR peuvent être ciblés, mais quelles défenses subsistent en dernier recours.
Sources
- Cisco Talos : Qilin EDR killer infection chain
- LeMagIT : Ransomware Qilin : un outil pour rendre aveugles plus de 300 EDR
