detecting-wmi-persistence

Aperçu du skill detecting-wmi-persistence

Le skill detecting-wmi-persistence vous aide à traquer la persistance par abonnement à des événements WMI dans la télémétrie Windows, en particulier les Event IDs Sysmon 19, 20 et 21. Il est particulièrement adapté aux threat hunters, aux analystes DFIR et aux équipes blue team qui doivent déterminer si une activité WMI suspecte relève d’une automatisation d’administration légitime ou d’une persistance attaquant.

À quoi sert detecting-wmi-persistence

Ce skill detecting-wmi-persistence est conçu pour une mission précise : identifier les activités malveillantes EventFilter, EventConsumer et FilterToConsumerBinding liées à MITRE ATT&CK T1546.003. Il est surtout utile lorsque vous disposez déjà de télémétrie ou d’une alerte et que vous voulez passer rapidement du signal à la preuve.

En quoi il diffère d’un prompt générique

Contrairement à un prompt large du type « vérifier la persistance », detecting-wmi-persistence vous donne un modèle de données concret : journaux Sysmon, requêtes sur les espaces de noms WMI, types de consommateurs suspects et étapes de nettoyage. Cela le rend plus fiable pour des investigations répétables et plus simple à intégrer dans un workflow SIEM ou endpoint.

Utilisateurs et environnements les plus adaptés

Utilisez detecting-wmi-persistence si Sysmon est déployé, si vous ingérez les événements Windows via Windows event forwarding ou un SIEM, et si vous avez suffisamment d’accès pour interroger root\subscription. Il convient mieux à l’ingénierie de chasse, à la réponse à incident et à la validation purple team qu’à une enquête légère menée uniquement depuis un poste de travail.

Comment utiliser le skill detecting-wmi-persistence

Installer le skill detecting-wmi-persistence

Installez avec :

npx skills add mukul975/Anthropic-Cybersecurity-Skills --skill detecting-wmi-persistence

Ouvrez ensuite d’abord skills/detecting-wmi-persistence/SKILL.md, puis references/api-reference.md et scripts/agent.py pour comprendre le mappage des événements et la logique de détection.

Démarrer avec la bonne entrée

L’usage de detecting-wmi-persistence fonctionne mieux si vous fournissez l’un de ces éléments : un extrait d’événement Sysmon, un nom d’hôte suspect, une fenêtre temporelle ou un nom précis de consommateur/filtre WMI. Une demande vague comme « vérifier une persistance WMI » est plus lente à exploiter que « enquêter sur les Event IDs Sysmon 19-21 depuis l’hôte X entre 02:00 et 06:00 UTC ».

Workflow recommandé pour la threat hunting

Pour detecting-wmi-persistence en Threat Hunting, commencez par les Event IDs Sysmon 19, 20 et 21, puis vérifiez si le consumer est CommandLineEventConsumer ou ActiveScriptEventConsumer, puis validez le binding dans root\subscription. Si vous avez un nom de filtre ou de consumer candidat, utilisez-le pour resserrer la chasse avant de tout énumérer.

Ce qu’il faut lire en premier dans le dépôt

Lisez references/api-reference.md pour les Event IDs, l’énumération PowerShell et les classes de consumers suspects. Lisez scripts/agent.py si vous voulez comprendre comment le skill automatise la collecte, ce qu’il considère comme suspect, et quelles hypothèses il fait sur l’accès Windows et la disponibilité de la télémétrie.

FAQ sur le skill detecting-wmi-persistence

detecting-wmi-persistence est-il réservé aux utilisateurs de Sysmon ?

Dans l’ensemble, oui. Le skill est construit autour des Event IDs Sysmon 19, 20 et 21 ; si vous n’avez pas activé la journalisation WMI de Sysmon, le skill detecting-wmi-persistence sera nettement moins efficace. Vous pouvez toujours utiliser les idées de requêtes WMI, mais vous perdrez le chemin de détection le plus solide.

Faut-il être expert WMI pour l’utiliser ?

Non. Le guide detecting-wmi-persistence est utile aux débutants capables de fournir des logs ou du contexte hôte, parce qu’il transforme un contrôle de persistance très ciblé en chasse structurée. Il faut toutefois disposer d’un accès Windows suffisant pour valider les subscriptions, ou travailler avec une personne qui l’a.

Quand ne faut-il pas utiliser ce skill ?

N’utilisez pas detecting-wmi-persistence comme skill général de triage malware ni comme remplacement d’une analyse forensique endpoint complète. Si le problème dépasse la seule persistance WMI, vous aurez peut-être d’abord intérêt à utiliser un skill de hunting ou d’IR plus généraliste.

En quoi se compare-t-il à un prompt classique ?

Un prompt classique demande souvent au modèle d’inférer le workflow de mémoire. Le skill detecting-wmi-persistence vous donne une trajectoire plus serrée : Event IDs, classes d’artefacts probables et étapes de validation appuyées par le dépôt, ce qui réduit généralement les faux départs et améliore la structure de l’investigation.

Comment améliorer le skill detecting-wmi-persistence

Fournir une télémétrie de meilleure qualité dès le départ

Le principal levier d’amélioration pour detecting-wmi-persistence, c’est la qualité de l’entrée. Fournissez le XML Sysmon brut, des extraits d’événements transférés, le rôle de l’hôte et la plage horaire. Par exemple, « Host WS-17, événements Sysmon 19-21, CommandLineEventConsumer suspect, contexte utilisateur inconnu » est bien plus utile que « je crois que WMI est bizarre ».

Distinguer l’automatisation légitime de la persistance suspecte

Une erreur fréquente consiste à surinterpréter un usage WMI d’administration légitime. Améliorez les résultats de detecting-wmi-persistence en indiquant ce qui est normal dans votre environnement : outils de déploiement connus, agents de gestion planifiés ou scripts approuvés. Ce contexte aide la chasse à se concentrer sur les filtres, consumers et bindings inhabituels.

Itérer avec des questions de suivi ciblées

Après le premier passage, demandez au skill detecting-wmi-persistence de se concentrer sur un seul type d’artefact à la fois : filter, consumer ou binding. Vous pouvez aussi demander une checklist de validation, un plan de requêtes orienté nettoyage ou une traduction de requête SIEM. Cette façon d’itérer produit généralement des résultats plus exploitables qu’un verdict large et unique.