Understanding the theory before analyzing real attack logs
I’m learning about WMI persistence. This is not research. This is me documenting what I found while studying a technique that APT29 and 20+ other APT groups use.
Part 2 will be different — actual lab testing, real Sysmon logs, detection methodology. This is just my notes.
Why I’m Studying This
I kept seeing WMI persistence mentioned in threat reports. APT29, APT28, and 20+ other groups use it. But I realized I didn’t actually understand HOW it works. I just knew THAT they use it.
So I started reading. Here’s what I found.
What I Found: WMI Has Three Parts
When I read about WMI persistence, I kept seeing three things mentioned:
- Event Filter
- Event Consumer
- Binding
I didn’t understand why all three mattered. Here’s what I learned.
The Event Filter (EventID 19)
An Event Filter is a trigger. It’s basically saying: “When this happens, do something.”
From MITRE docs, I read that APT29 set up a filter that said: “When a process is created, trigger my action.”
In Sysmon, this shows up as EventID 19 — WMI Event Filter Activity.
What confused me: This isn’t execution yet. This is just setup. The trigger exists, but nothing has happened.
The Event Consumer (EventID 20)
The Consumer is what actually runs. It’s the payload.
So the Consumer says: “When the filter triggers, execute this command.”
MITRE documents that attackers use Event Consumers to execute backdoors, malware, or lateral movement commands when the trigger fires.
In Sysmon, this shows up as EventID 20 — WMI Event Consumer Activity.
Still no execution. Still just setup.
The Binding (EventID 21)
This is where I realized the attack actually happens: the binding connects the filter to the consumer.
Without the binding, you have a filter with nothing to execute. You have a consumer with no trigger.
The binding LINKS them together.
In Sysmon, this is EventID 21 — WMI Event Consumer-to-Filter Binding Activity.
Once this binding exists, the attack is armed.
Why APT29 (and 20+ Others) Use This
I was wondering: Why WMI? Why not just use a Registry Run key or Scheduled Task?
Here’s what I think:
WMI looks like a Windows function. Most defenders trust it by default. Most people think WMI activity is normal system behavior.
APT29, APT28, and others all chose WMI because it blends in. If a defender saw EventID 20 (WMI Consumer activity), they might think: “That’s probably Windows doing Windows things.”
But if they saw Registry Run key activity, they’d immediately think: “That’s suspicious.”
So WMI is harder to detect. That’s why so many APT groups use it.
The Attack Timeline
I was confused about when the actual execution happens. The answer: EventID 4688.
EventID 4688 is process creation. This is when the malicious command actually runs.
Here’s the timeline:
- Attacker creates Filter (EventID 19) — “When X event happens, trigger”
- Attacker creates Consumer (EventID 20) — “Run this command”
- Attacker creates Binding (EventID 21) — “Link filter to consumer”
- System triggers the event (boot, process creation, file write, etc.)
- Filter executes the consumer
- Sysmon captures EventID 4688 — process created (the malicious code running)
So EventID 19, 20, 21 might happen at 3 AM on Tuesday.
But EventID 4688 might happen at 8 AM on Friday when the trigger fires.
That’s why defenders miss this — the setup and execution are days apart.
What I Don’t Understand Yet
When I read about this, some things didn’t click:
Question 1: If the setup (EventID 19, 20, 21) happens at 3 AM, why does the trigger wait until Friday?
Question 2: Can an attacker control WHEN the trigger fires, or does it depend on the system event?
Question 3: If I see EventID 20 and 21 in my logs, how do I know if it’s legitimate WMI activity or malicious?
Question 4: Where exactly do these WMI components get stored on disk? Is it Registry? Memory? Both?
Why This Matters (Even Though It’s Old)
APT29, APT28, APT19, APT33, APT37, APT38, APT40, APT41, Lazarus Group — MITRE documents that 20+ groups use WMI persistence.
APT29 used it in the SolarWinds compromise to maintain backdoor access. But it’s not just SolarWinds. It’s everywhere.
Most defenders still miss it because they don’t correlate WMI events with process creation events.
That’s what I want to understand: If the technique is old and documented, why are people still falling for it?
Answer: Because WMI looks legitimate.
Open to Collaboration
Building detection rules that actually work in real environments is what drives me. The gap between theory and practice is huge, and that’s where the interesting problems are.
If you’re working on detection engineering, scaling your SOC, or trying to improve threat hunting in your environment, I’m interested in talking about it.
I’m open to remote contract work or project-based collaboration where I can contribute expertise in detection engineering. If your team is serious about improving threat detection capabilities and understanding real-world attack patterns, let’s connect.
LinkedIn: https://www.linkedin.com/in/manishrawat-soc/
GitHub: https://github.com/Manishrawat21/
Sources
- MITRE ATT&CK: T1547.001 (Event Triggered Execution — Windows Management Instrumentation Event Subscription)
- Mandiant: SolarWinds Compromise & APT29 Analysis
- Red Canary: WMI Persistence & Detection Evasion Research
This is Part 1: My Learning Notes
Part 2 Coming: Real lab testing. Real Sysmon logs. Real detection.
Not theory. Proof.
WMI Event Consumer Persistence: How APT29 Achieves Fileless Persistence (Part 1) was originally published in OSINT Team on Medium, where people are continuing the conversation by highlighting and responding to this story.