Skip to content

Persistance WMI par abonnement aux événements expliquée

Persistance WMI : fonctionnement de __EventFilter, des consommateurs et de __FilterToConsumerBinding, où ils sont stockés et comment les détecter.

Publié le 5 min de lecture

En bref. Un abonnement aux événements WMI se compose de trois objets : un __EventFilter (une requête WQL qui décrit quand), un consommateur d'événements (quoi faire) et un __FilterToConsumerBinding qui les relie. Enregistré de façon permanente, il survit aux redémarrages et s'exécute en tant que SYSTEM. MITRE le référence sous T1546.003. Les traces se trouvent dans le dépôt CIM, et vous pouvez les lire hors ligne, objets supprimés compris.

Les trois éléments

WMI est la couche d'administration de Windows. En plus de répondre à des requêtes, il peut réagir : lorsqu'un événement correspondant à une requête se produit, il le transmet à un consommateur. Un abonnement permanent se compose de :

ObjetClasseContenu
Filtre__EventFilterName, Query (WQL), QueryLanguage, EventNamespace, CreatorSID
Consommateurune classe dérivée de __EventConsumerl'action : ligne de commande, script, fichier journal, événement, e-mail
Liaison__FilterToConsumerBindingréférences Filter et Consumer, CreatorSID

Windows fournit cinq classes de consommateurs standard :

  • CommandLineEventConsumer : CommandLineTemplate, ExecutablePath, WorkingDirectory. Lancé par l'hôte des fournisseurs WMI (WmiPrvSE.exe).
  • ActiveScriptEventConsumer : ScriptingEngine (VBScript ou JScript) et soit ScriptText, soit ScriptFilename. Exécuté par scrcons.exe.
  • LogFileEventConsumer : ajoute Text à Filename.
  • NTEventLogEventConsumer : écrit une entrée dans le journal des événements.
  • SMTPEventConsumer : envoie un e-mail.

Seuls les deux premiers exécutent du code arbitraire, c'est pourquoi la plupart des persistances WMI les utilisent.

Pourquoi les attaquants l'utilisent

Créer un abonnement nécessite des droits administrateur, mais une fois en place, il offre beaucoup :

  • Il survit aux redémarrages et ne nécessite aucun fichier dans une clé Run, un service ou une tâche planifiée.
  • L'action s'exécute en tant que SYSTEM, avec pour parents des processus WMI toujours actifs.
  • Le déclencheur peut être tout ce que WMI observe : quelques minutes après le démarrage, une ouverture de session, le lancement d'un processus, l'insertion d'une clé USB, une heure de la journée ou un minuteur WMI.
  • Il se cache à la vue de tous : les revues de type autoruns qui ignorent WMI le manquent, et le dépôt est une base de données binaire que peu de gens ouvrent.

Un exemple classique est un filtre sur Win32_PerfFormattedData_PerfOS_System qui se déclenche quand SystemUpTime est compris entre 240 et 325 secondes, de sorte que la charge utile démarre environ quatre minutes après chaque démarrage :

SELECT * FROM __InstanceModificationEvent WITHIN 60
WHERE TargetInstance ISA 'Win32_PerfFormattedData_PerfOS_System'
AND TargetInstance.SystemUpTime >= 240 AND TargetInstance.SystemUpTime < 325

Lié à un CommandLineEventConsumer dont le modèle est C:\ProgramData\Intel\m64.exe -svc, cela constitue un mécanisme de persistance complet. C'est exactement ce que contient l'exemple de WMI Parser, sur l'hôte fictif FIN-WKS-07.

Où se trouvent les traces

Les abonnements sont des objets du dépôt WMI, C:\Windows\System32\wbem\Repository :

Ils se trouvent normalement dans l'espace de noms root\subscription, mais un abonnement enregistré dans root\cimv2 ou root\default fonctionne aussi. Le format est décrit dans Au cœur d'OBJECTS.DATA.

Deux propriétés comptent beaucoup dans une investigation :

  • CreatorSID sur chaque objet enregistre le compte qui l'a créé. Un SID se terminant par -500, S-1-5-32-544 ou le SID d'un utilisateur précis racontent chacun une histoire différente.
  • Les objets supprimés ne sont pas effacés. Leurs pages sont libérées et ne sont réécrites que lorsque WMI a besoin de l'espace, si bien que le nettoyage d'un attaquant laisse souvent derrière lui le filtre, le consommateur ou la liaison. Voir récupérer une persistance WMI supprimée.

Ce que le dépôt ne fournit pas, c'est une date de création documentée. Chaque enregistrement d'instance porte deux FILETIME non documentés qui suivent souvent le moment de son écriture ; traitez-les comme des pistes. Pour la chronologie, corrélez avec l'événement 5861 de Microsoft-Windows-WMI-Activity/Operational et avec les événements Sysmon 19 à 21, présentés dans la checklist d'investigation.

Comment la détecter

  1. Collectez le dépôt depuis un cliché instantané (shadow copy), avec KAPE (cible WBEM) ou Velociraptor : comment collecter le dépôt WMI.
  2. Analysez-le hors ligne. Déposez le dossier dans WMI Parser : il liste chaque liaison avec son filtre et son consommateur, récupère les objets supprimés et indique pour chaque objet s'il provient de l'index ou du carving.
  3. Écartez les abonnements par défaut. Windows installe un abonnement SCM Event Log, et les images plus anciennes un abonnement BVT. Ils sont inoffensifs lorsque leur contenu correspond : voir SCM Event Log Consumer et BVTConsumer.
  4. Lisez ce qui reste : la requête de déclenchement, la commande ou le script, les chemins et le créateur.

Éléments à rechercher : PowerShell encodé, binaires dans des dossiers accessibles en écriture aux utilisateurs (C:\ProgramData, C:\Users\Public, %TEMP%), consommateurs de script, déclencheurs sur la durée de fonctionnement ou l'ouverture de session, et abonnements hors de root\subscription.

FAQ

Qu'est-ce que la persistance par abonnement aux événements WMI ?

Un attaquant enregistre un abonnement permanent aux événements WMI : un __EventFilter qui décrit un événement, un consommateur qui décrit une action, et un __FilterToConsumerBinding qui les relie. Windows exécute alors l'action en tant que SYSTEM à chaque occurrence de l'événement, y compris après un redémarrage.

Où sont stockés les abonnements aux événements WMI ?

Dans le dépôt WMI (CIM), C:\Windows\System32\wbem\Repository, principalement dans OBJECTS.DATA avec ses fichiers INDEX.BTR et MAPPING. Ils se trouvent normalement dans l'espace de noms root\subscription.

Quels consommateurs comptent pour la persistance ?

CommandLineEventConsumer (exécute une ligne de commande) et ActiveScriptEventConsumer (exécute du VBScript ou du JScript) exécutent du code. LogFileEventConsumer, NTEventLogEventConsumer et SMTPEventConsumer écrivent un fichier, un événement ou un e-mail.

Articles liés

Articles liés

Checklist pas à pas face à une persistance WMI : requêtes en direct, dépôt, événements 5860 et 5861, Sysmon 19-21, traces d'exécution et nettoyage sûr.
Les deux abonnements WMI livrés avec Windows, SCM Event Log et BVTFilter/BVTConsumer : contenu attendu, innocuité et détournement de leurs noms.
Pourquoi filtres, consommateurs et liaisons WMI supprimés subsistent dans OBJECTS.DATA : parcours d'index, carving, python-cim et PyWMIPersistenceFinder.