Persistance
Pilotes noyau (.sys, services de pilote, BYOVD)
Fiche pilotes noyau : services de pilote (Type 1/2), événement 7045, DriverStore, setupapi.dev.log, Amcache et journaux CodeIntegrity contre BYOVD et rootkits.
- Emplacement
- C:\Windows\System32\drivers\*.sys
- Prouve
- Un pilote noyau a été installé ou déclaré comme service, quand, depuis quel chemin, et si Windows l'a bloqué ou chargé
- Horodatages
- LastWrite de la clé Services (FILETIME, UTC), événements 7045/4697 et CodeIntegrity (UTC), sections de setupapi.dev.log (heure locale), dates $SI/$FN du .sys
- Rétention
- Clés de service et fichiers .sys restent jusqu'à suppression ; System.evtx et le journal CodeIntegrity tournent (20 Mo et environ 1 Mo par défaut) ; setupapi.dev.log grossit jusqu'à purge
- Accès
- Administrateur pour le registre, les journaux et le dossier des pilotes à chaud ; ruche SYSTEM, Amcache.hve et .evtx actifs verrouillés : copie brute ou VSS
- Type
- Fichier / système de fichiers
- Windows
- XPVista / 78 / 8.11011
- Cible KAPE
- RegistryHivesSystemEventLogsAmcacheUSBDevicesLogs
- Velociraptor
- Windows.Triage.Targets:RegistryHivesSystemEventLogsAmcacheUSBDevicesLogs
Outils
Comparer tous les outilsPrésentation
Les pilotes noyau sont l'équivalent Windows des modules du noyau Linux : des fichiers PE .sys chargés en ring 0 par le Service Control Manager, le gestionnaire Plug and Play ou un appel direct à NtLoadDriver. Le matériel et les produits de sécurité en ont besoin ; les attaquants s'en servent pour des rootkits et, bien plus souvent aujourd'hui, pour le Bring Your Own Vulnerable Driver (BYOVD) : ils déposent un pilote signé mais exploitable (par exemple RTCore64.sys, gdrv.sys, dbutil_2_3.sys, procexp152.sys) et l'utilisent pour tuer les processus EDR ou modifier la mémoire du noyau. Tout pilote a besoin d'une entrée de service, d'un fichier sur disque et d'une vérification de signature réussie, et chacune de ces étapes laisse des traces.
Emplacement
| Source | Chemin |
|---|---|
| Binaires des pilotes | C:\Windows\System32\drivers\*.sys (mais un pilote peut se charger depuis n'importe quel chemin) |
| Déclaration du service | HKLM\SYSTEM\<ControlSet00x>\Services\<nom> avec Type = 1 (pilote noyau) ou 2 (pilote de système de fichiers) |
| Installation de service | System.evtx événement 7045 (Service Control Manager) ; Security.evtx événement 4697 si l'audit « Extension système de sécurité » est actif |
| Paquets de pilotes PnP | C:\Windows\System32\DriverStore\FileRepository\<inf>_<arch>_<hash>\, C:\Windows\INF\oem*.inf |
| Journal d'installation PnP | C:\Windows\INF\setupapi.dev.log (Vista et suivants) |
| Amcache | Amcache.hve, clés Root\InventoryDriverBinary et Root\InventoryDriverPackage (Windows 10 et suivants) |
| Contrôle de signature | Microsoft-Windows-CodeIntegrity%4Operational.evtx |
| Liste de blocage des pilotes vulnérables | C:\Windows\System32\CodeIntegrity\driversipolicy.p7b ; interrupteur HKLM\SYSTEM\CurrentControlSet\Control\CI\Config\VulnerableDriverBlocklistEnable |
Ce que l'artefact prouve
- Déclaration : une clé Services avec
Type1 ou 2 montre qu'un pilote a été configuré pour se charger, avec sonImagePathet son modeStart(0 boot, 1 système, 2 automatique, 3 à la demande, 4 désactivé). - Date et compte d'installation : l'événement 7045 donne le nom du service, le chemin du fichier, le type « pilote en mode noyau » et le type de démarrage ; le 4697 ajoute le compte à l'origine.
- Identité du fichier :
InventoryDriverBinaryd'Amcache conserve le SHA-1, l'état de signature, l'éditeur et la version du pilote, même après suppression du fichier. - Chargements bloqués : les événements CodeIntegrity montrent que Windows a refusé un pilote pour cause de niveau de signature ou de stratégie.
Il ne prouve pas que le pilote a réellement été chargé ou exploité. Un service créé avec sc create et démarré une seule fois peut ne laisser aucune trace de chargement avec la journalisation par défaut. Confirmez avec la mémoire (modules chargés), l'événement Sysmon 6 (pilote chargé) si Sysmon était déployé, ou les effets induits comme l'arrêt des services EDR.
Champs clés
| Champ | Signification |
|---|---|
Type | 1 = pilote noyau, 2 = pilote de système de fichiers (16/32 = services en mode utilisateur) |
Start | 0 boot, 1 système, 2 auto, 3 à la demande, 4 désactivé |
ImagePath | Chemin du pilote, souvent \SystemRoot\System32\drivers\x.sys ou System32\drivers\x.sys ; tout autre dossier est suspect |
Group, Tag | Groupe d'ordre de chargement ; rarement renseigné par les pilotes malveillants |
DriverId (InventoryDriverBinary) | SHA-1 du fichier (précédé de zéros de remplissage) |
DriverSigned, DriverCompany, Product, DriverLastWriteTime | Indicateur de signature et ressources de version |
setupapi.dev.log >>> Section start | Sections horodatées d'installation de pilotes PnP avec le nom de l'INF |
Horodatages
- LastWrite de la clé Services (FILETIME, UTC) : création ou dernière modification du service. Changer
StartouImagePathle met à jour. - 7045 / 4697 : horodatages UTC, le repère d'installation le plus fiable.
- setupapi.dev.log : les heures de début et de fin de section sont écrites en heure locale ; convertissez-les avant de construire la chronologie.
- Fichier .sys : dates $SI et $FN dans la $MFT ; $FN est plus difficile à falsifier et trahit souvent un pilote déposé puis antidaté pour ressembler à un fichier système.
- Amcache : le LastWrite de la clé reflète le passage de l'inventaire, pas forcément l'arrivée du pilote.
Rétention et effacement
La clé de registre et le fichier restent jusqu'à leur suppression. Les attaquants suppriment souvent le service et le .sys après usage : cherchez la suppression dans le journal USN, l'entrée Amcache orpheline et l'événement 7045, qui survit à la suppression du service jusqu'à la rotation du journal System (20 Mo par défaut). Le journal CodeIntegrity/Operational est petit (souvent environ 1 Mo) : les événements de blocage peuvent être écrasés vite. L'effacement d'un journal produit l'événement 104 (System) ou 1102 (Security).
Collecte
KAPE RegistryHivesSystem, EventLogs, Amcache et USBDevicesLogs (qui inclut les journaux setupapi), plus les fichiers de pilotes eux-mêmes :
driverquery /v /fo csv > E:\case\driverquery.csv
driverquery /si /fo csv > E:\case\driver_signing.csv
sc query type= driver state= all > E:\case\sc_drivers.txt
robocopy C:\Windows\System32\drivers E:\case\drivers *.sys /COPY:DAT
Get-WinEvent -FilterHashtable @{LogName='System'; Id=7045} |
Where-Object Message -match 'kernel mode driver|file system driver' |
Select-Object TimeCreated, Message | Export-Csv E:\case\7045_drivers.csv -NoTypeInformation
Get-WinEvent -LogName 'Microsoft-Windows-CodeIntegrity/Operational' |
Select-Object TimeCreated, Id, Message | Export-Csv E:\case\codeintegrity.csv -NoTypeInformation
Sur un système en français, le texte des messages 7045 est traduit : adaptez le filtre (« pilote en mode noyau ») ou filtrez sur les champs de l'événement.
Outils d'analyse
- Autoruns (Sysinternals) : onglet Drivers avec « Verify code signatures » et contrôle VirusTotal ;
autorunsc -a d -h -s -cpour un CSV. - sigcheck (
sigcheck -e -h -c C:\Windows\System32\drivers) pour le signataire et les hashs de chaque.sys. - Registry Explorer / RegRipper pour les ruches SYSTEM hors ligne (pensez à choisir le jeu de contrôle actif).
- AmcacheParser pour
InventoryDriverBinary. - EvtxECmd pour les événements 7045, 4697 et CodeIntegrity.
- Volatility 3 :
windows.modules,windows.modscanetwindows.driverscanpour comparer modules listés et modules retrouvés par scan, et repérer les pilotes déliés ; voir le guide d'analyse mémoire.
Conseils d'investigation
- Hachez chaque pilote non Microsoft et comparez-le au projet LOLDrivers (loldrivers.io) et à la liste de blocage Microsoft. Un pilote signé d'un éditeur de jeux, d'overclocking ou de matériel sur un serveur est un signe classique de BYOVD.
- Un
ImagePathdans\Users\,\ProgramData\,\Windows\Temp\ou un nom de service court et aléatoire associé àType1 etStart3 est typique d'un pilote déposé par un outil. - Dans CodeIntegrity/Operational, des événements comme 3033 (image ne respectant pas le niveau de signature requis), 3077 (bloqué par une stratégie de contrôle d'application appliquée) et 3076 (mode audit) sont les points de départ habituels ; les identifiants et libellés exacts varient selon la version et la stratégie, lisez le message.
- La liste de blocage des pilotes vulnérables est active par défaut sur les versions récentes de Windows 11 et avec HVCI ou Smart App Control, mais elle a du retard sur les nouveaux pilotes : vérifiez
VulnerableDriverBlocklistEnableet la version de la stratégie avant de conclure qu'un pilote n'a pas pu se charger. - Rapprochez la minute d'installation du pilote de la chronologie des programmes installés, des arrêts de service de Windows Defender et des événements de protection contre les falsifications.
- Les installations de pilotes PnP (clés USB, imprimantes) arrivent aussi dans setupapi.dev.log et le DriverStore : séparez le bruit matériel légitime des installations manuelles via
pnputil /add-driver.
Artefacts liés
- Services WindowsFiche services Windows : valeurs de la clé Services (ImagePath, Start, Type, ServiceDll), événements 7045 et 4697, traces de PsExec et pièges.
- Amcache.hveFiche Amcache.hve : clés d'inventaire des fichiers et programmes, SHA-1, métadonnées PE, horodatages, et pourquoi une entrée ne prouve pas l'exécution.
- Fichiers PE (exécutables Windows)Fiche de tri des fichiers PE : hash, imphash et en-tête Rich, limites de la date de compilation, sections et entropie, informations de version, signatures, PDB.
- Journaux d'événements Windows (EVTX)Fiche des journaux d'événements Windows : emplacements EVTX, ID indispensables (connexions, processus, services, effacement), rétention, audit et outils.
- Journaux et quarantaine Microsoft DefenderForensique Microsoft Defender : événements 1116/1117/5001/5007, fichiers MPLog, DetectionHistory, quarantaine chiffrée, exclusions et traces de sabotage.
- Journal d'événements SysmonFiche Sysmon : emplacement du journal Operational, ID d'événements clés, corrélation ProcessGuid et hash, config dans le registre, altérations et outils.
- Programmes installés (clés Uninstall, MSI, AppX)Fiche programmes installés : clés Uninstall, événements MSI 1033/11707, MSI en cache, paquets AppX, journaux winget et Amcache pour dater les installations.
- Historique des périphériques USBFiche forensique USB : clés USBSTOR et USB, numéros de série, première et dernière connexion, lettres de lecteur, setupapi.dev.log et événements.
Termes du glossaire
- PersistanceMécanismes permettant à un malware ou à un attaquant de survivre aux redémarrages : clés Run, services, tâches planifiées, abonnements WMI.
- Anti-forensiqueTechniques visant à détruire, cacher ou falsifier des preuves : effacement de journaux, timestomping, wiping, suppression des clichés ou du journal USN.
- ControlSet et CurrentControlSetLes jeux de configuration numérotés de la ruche SYSTEM ; CurrentControlSet est un lien d'exécution absent d'une ruche analysée hors ligne.
- ID d'événement WindowsLe numéro qui identifie un type d'événement au sein d'un fournisseur donné ; il n'a de sens qu'associé à ce fournisseur et à son canal.
- LastWrite d'une clé de RegistreL'unique FILETIME stocké dans chaque clé de Registre, qui indique en UTC la dernière modification de la clé ou de l'une de ses valeurs.
Guides
- Chasser la persistance Windows : registre, tâches, WMIDétecter la persistance d'un attaquant sous Windows : clés Run, services, tâches planifiées, WMI, Winlogon, IFEO, COM et BITS, avec MITRE ATT&CK et outils.
- Anti-forensique Windows : détecter les traces qui subsistentDétecter effacement de journaux, timestomping, suppression sécurisée, destruction des VSS et neutralisation de Defender, avec ATT&CK et les traces laissées.
- Analyse mémoire Windows avec Volatility 3 : guide pratiqueAcquérir la RAM Windows, exploiter hiberfil et pagefile, puis dérouler Volatility 3 pour trouver code injecté, processus cachés et activité réseau.