detecting-wmi-persistence
by mukul975The detecting-wmi-persistence skill helps threat hunters and DFIR analysts detect WMI event subscription persistence in Windows telemetry using Sysmon Event IDs 19, 20, and 21. Use it to identify malicious EventFilter, EventConsumer, and FilterToConsumerBinding activity, validate findings, and separate attacker persistence from benign admin automation.
This skill scores 78/100 and is worth listing: it gives directory users a concrete WMI-persistence hunting workflow, enough context to trigger it correctly, and a supporting script/reference set. It is solid for install decisions, though users should note that it is oriented to Windows/Sysmon environments and is more detection-oriented than fully end-to-end automated.
- Clear, specific trigger: hunting WMI event subscription persistence via Sysmon Event IDs 19, 20, and 21.
- Operational workflow is spelled out with prerequisites, suspicious consumer types, and PowerShell/WMI enumeration examples.
- Support files add leverage: a Python agent script and an API reference for Sysmon/WMI fields and commands.
- Requires a fairly specific environment: Sysmon WMI logging, SIEM ingestion, and PowerShell/WMI access on Windows endpoints.
- Installability is somewhat limited by missing install command and only moderate workflow signal density beyond the core detection path.
Overview of detecting-wmi-persistence skill
The detecting-wmi-persistence skill helps you hunt for WMI event subscription persistence in Windows telemetry, especially Sysmon Event IDs 19, 20, and 21. It is best for threat hunters, DFIR analysts, and blue teams who need to confirm whether suspicious WMI activity is benign admin automation or attacker persistence.
What detecting-wmi-persistence is for
This detecting-wmi-persistence skill is designed for a specific job: identify malicious EventFilter, EventConsumer, and FilterToConsumerBinding activity tied to MITRE ATT&CK T1546.003. It is most useful when you already have telemetry or an alert and need a fast path from signal to evidence.
Why it is different from a generic prompt
Unlike a broad “check for persistence” prompt, detecting-wmi-persistence gives you a concrete data model: Sysmon logs, WMI namespace queries, suspicious consumer types, and cleanup steps. That makes it more reliable for repeatable investigations and easier to apply in a SIEM or endpoint workflow.
Best-fit users and environments
Use detecting-wmi-persistence if you have Sysmon deployed, Windows event forwarding or SIEM ingestion, and enough access to query root\subscription. It fits hunt engineering, incident response, and purple team validation better than lightweight desktop-only investigations.
How to Use detecting-wmi-persistence skill
Install the detecting-wmi-persistence skill
Install with:
npx skills add mukul975/Anthropic-Cybersecurity-Skills --skill detecting-wmi-persistence
Then open skills/detecting-wmi-persistence/SKILL.md first, followed by references/api-reference.md and scripts/agent.py to understand the event mapping and detection logic.
Start with the right input
The detecting-wmi-persistence usage works best when you provide one of these: a Sysmon event excerpt, a suspicious host name, a time window, or a specific WMI consumer/filter name. A weak request like “check WMI persistence” is slower to act on than “investigate Sysmon Event IDs 19-21 from host X between 02:00 and 06:00 UTC.”
Suggested workflow for threat hunting
For detecting-wmi-persistence for Threat Hunting, begin with Sysmon Event IDs 19, 20, and 21, then inspect whether the consumer is CommandLineEventConsumer or ActiveScriptEventConsumer, then verify the binding in root\subscription. If you have a candidate filter or consumer name, use it to narrow the hunt before you enumerate everything.
What to read first in the repo
Read references/api-reference.md for event IDs, PowerShell enumeration, and suspicious consumer classes. Read scripts/agent.py if you want to understand how the skill automates collection, what it considers suspicious, and what assumptions it makes about Windows access and telemetry availability.
detecting-wmi-persistence skill FAQ
Is detecting-wmi-persistence only for Sysmon users?
Mostly yes. The skill is built around Sysmon Event IDs 19, 20, and 21, so if you do not have Sysmon WMI logging enabled, the detecting-wmi-persistence skill will be much less effective. You can still use the WMI query ideas, but you will lose the strongest detection path.
Do I need to be a WMI expert to use it?
No. The detecting-wmi-persistence guide is useful for beginners who can provide logs or host context, because it turns a niche persistence check into a structured hunt. You do need enough Windows access to validate subscriptions or work with someone who has it.
When should I not use this skill?
Do not use detecting-wmi-persistence as a general malware triage skill or as a replacement for full endpoint forensic analysis. If the problem is broader than WMI persistence, you may want a more general hunting or IR skill first.
How does it compare to a normal prompt?
A normal prompt usually asks the model to infer the workflow from memory. The detecting-wmi-persistence skill gives you a tighter path: event IDs, likely artifact classes, and repo-backed validation steps, which usually means fewer false starts and better investigation structure.
How to Improve detecting-wmi-persistence skill
Give higher-quality telemetry up front
The biggest improvement for detecting-wmi-persistence is better input. Provide raw Sysmon XML, forwarded event snippets, the host role, and the time range. For example, “Host WS-17, Sysmon 19-21 events, suspicious CommandLineEventConsumer, user context unknown” is far stronger than “I think WMI is weird.”
Separate benign automation from suspicious persistence
A common failure mode is overcalling legitimate admin WMI usage. Improve detecting-wmi-persistence results by telling the skill what normal looks like in your environment: known deployment tools, scheduled management agents, or approved scripts. That context helps the hunt focus on unusual filters, consumers, and bindings.
Iterate with targeted follow-up questions
After the first pass, ask the detecting-wmi-persistence skill to narrow on one artifact type at a time: filter, consumer, or binding. You can also ask for a validation checklist, a cleanup-oriented query plan, or a SIEM query translation. Iterating this way usually produces more actionable output than asking for a single broad verdict.