Date : 16/09/2025

 Quand un driver vulnérable permet aux malwares de prendre le contrôle de vos antivirus (BYOVD)

Un récent article à propos d'une nouvelle campagne malveillante met en lumière l’ingéniosité croissante des cybercriminels. Le malware ValleyRAT, déjà connu pour ses capacités d’accès à distance, exploite une technique redoutable appelée BYOVD (Bring Your Own Vulnerable Driver) : il utilise un pilote signé mais vulnérable pour neutraliser les solutions de sécurité.

En découvrant ces informations, je n’ai pas pu résister à la tentation de récupérer les binaires, en particulier le driver, et de l’ouvrir immédiatement dans IDA pour explorer ses fonctions et son interface. C’est fascinant de constater concrètement comment un driver signé peut être détourné pour neutraliser les protections du système.

1. Comment le malware se propage

La campagne se diffuse via de faux installateurs d’applications populaires comme WinRAR ou Telegram. Une fois exécuté, le fichier malveillant NVIDIA.exe installe un pilote nommé NSecKrnl64.sys, signé par une entreprise légitime mais utilisé à des fins malveillantes.

Le pilote est écrit dans un dossier temporaire et enregistré comme service système avec des privilèges élevés, ce qui permet son chargement furtif sans déclencher les protections telles que HVCI ou WDAC, souvent désactivées sur les machines ciblées.

2. Le rôle du pilote malveillant

Le pilote NSecKrnl64.sys expose un device accessible depuis l’espace utilisateur et offre des primitives critiques :

Ajouter des PIDs à une liste protégée, empêchant certains processus d’être terminés.
Terminer arbitrairement des processus via ZwTerminateProcess en mode noyau.
Intercepter et révoquer les droits d’accès sur des processus via ObRegisterCallbacks.

Ces capacités permettent à ValleyRAT de cibler spécifiquement des processus antivirus, comme ceux de Qihoo 360, grâce à une liste fixe de 20 processus à traquer et éliminer en boucle via des appels IOCTL.

Pourquoi la signature du pilote augmente le risque : un driver signé est automatiquement considéré comme digne de confiance par Windows et peut s’exécuter en mode noyau, ce qui lui donne un accès complet au système. Un attaquant n’a donc pas besoin d’introduire un driver malveillant : il peut exploiter un pilote existant ou mal configuré pour désactiver les protections.

3. Scénario d’abus typique

Le processus malveillant ouvre le device \\.\NSecKrnl.
Il envoie un IOCTL pour :
- Ajouter un PID à la liste protégée.
- Terminer un processus critique (antivirus ou agent de sécurité).
Le pilote exécute les actions en mode noyau, rendant la menace furtive et difficile à détecter.

Même après suppression du fichier et de la clé de registre, le pilote reste actif tant que le système n’est pas redémarré.

4. Indicateurs de compromission (IoC)

Fichier exécutable :
NVIDIA.exe | SHA-256 : b4ac2e473c5d6c5e1b8430a87ef4f33b53b9ba0f585d3173365e437de4c816b2
Pilote :
NSecKrnl64.sys | SHA-256 : 206f27ae820783b7755bca89f83a0fe096dbb510018dd65b63fc80bd20c03261
Apparition ou chargement récent de drivers signés inhabituels.
Création de devices inhabituels et accès par des comptes non autorisés.
Surveillance de l’installation ou du chargement de pilotes depuis des répertoires inhabituels (ex. %TEMP%, dossiers téléchargements, chemins non standards).
Tentatives d’OpenProcess/DuplicateHandle échouant en corrélation avec des modifications de droits noyau.

5. Mesures de détection et prévention

Pour les responsables non-techniques :

Surveiller le chargement de pilotes signés récents.
Vérifier la création d’objets device inhabituels.
Corréler les terminaisons d’agents de sécurité avec l’accès au device.

Pour les équipes techniques / SOC :

Surveiller les appels IOCTL inhabituels sur des devices spécifiques.
Vérifier les ObRegisterCallbacks sur PsProcessType avec altitudes anormales.
Identifier la séquence : PsLookupProcessByProcessId → ObOpenObjectByPointer(PROCESS_TERMINATE) → ZwTerminateProcess.
Détecter les modifications de droits sur les processus critiques.

Mesures recommandées :

Maintenir un inventaire des drivers signés et alerter sur tout ajout non approuvé.
Restreindre l’installation de drivers avec un processus d’approbation centralisé.
Appliquer des ACL sur les objets device exposés.
Corréler les logs d’IOCTL, création de devices et terminaisons d’agents de sécurité.
Playbook d’incident : isolation de l’hôte, collecte mémoire, inventaire des drivers, capture des preuves avant toute modification.
Best practices pour les développeurs : limiter les API exposées, valider les IOCTL, journaliser les appels sensibles, revoir tout code permettant des opérations dangereuses (kill arbitraire, callbacks globaux).