{"id":462,"date":"2026-03-29T01:33:15","date_gmt":"2026-03-29T01:33:15","guid":{"rendered":"http:\/\/quantusintel.group\/osint\/blog\/2026\/03\/29\/wmi-event-consumer-persistence-how-apt29-achieves-fileless-persistence-part-1\/"},"modified":"2026-03-29T01:33:15","modified_gmt":"2026-03-29T01:33:15","slug":"wmi-event-consumer-persistence-how-apt29-achieves-fileless-persistence-part-1","status":"publish","type":"post","link":"https:\/\/quantusintel.group\/osint\/blog\/2026\/03\/29\/wmi-event-consumer-persistence-how-apt29-achieves-fileless-persistence-part-1\/","title":{"rendered":"WMI Event Consumer Persistence: How APT29 Achieves Fileless Persistence (Part 1)"},"content":{"rendered":"

Understanding the theory before analyzing real attack\u00a0logs<\/h4>\n

I\u2019m 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\u00a0use.<\/p>\n

Part 2 will be different\u200a\u2014\u200aactual lab testing, real Sysmon logs, detection methodology. This is just my\u00a0notes.<\/p>\n

Why I\u2019m Studying\u00a0This<\/h3>\n

I kept seeing WMI persistence mentioned in threat reports. APT29, APT28, and 20+ other groups use it. But I realized I didn\u2019t actually understand HOW it works. I just knew THAT they use\u00a0it.<\/p>\n

So I started reading. Here\u2019s what I\u00a0found.<\/p>\n

\"\"
redcanary\u2019s quote<\/figcaption><\/figure>\n

What I Found: WMI Has Three\u00a0Parts<\/h3>\n

When I read about WMI persistence, I kept seeing three things mentioned:<\/p>\n

    \n
  1. Event Filter<\/li>\n
  2. Event Consumer<\/li>\n
  3. Binding<\/li>\n<\/ol>\n

    I didn\u2019t understand why all three mattered. Here\u2019s what I\u00a0learned.<\/p>\n

    The Event Filter (EventID\u00a019)<\/h3>\n

    An Event Filter is a trigger. It\u2019s basically saying: \u201cWhen this happens, do something.\u201d<\/p>\n

    From MITRE docs, I read that APT29 set up a filter that said: \u201cWhen a process is created, trigger my\u00a0action.\u201d<\/p>\n

    In Sysmon, this shows up as EventID 19\u200a\u2014\u200aWMI Event Filter Activity.<\/p>\n

    What confused me: This isn\u2019t execution yet. This is just setup. The trigger exists, but nothing has happened.<\/p>\n

    The Event Consumer (EventID\u00a020)<\/h3>\n

    The Consumer is what actually runs. It\u2019s the\u00a0payload.<\/p>\n

    So the Consumer says: \u201cWhen the filter triggers, execute this command.\u201d<\/p>\n

    MITRE documents that attackers use Event Consumers to execute backdoors, malware, or lateral movement commands when the trigger\u00a0fires.<\/p>\n

    In Sysmon, this shows up as EventID 20\u200a\u2014\u200aWMI Event Consumer Activity.<\/p>\n

    Still no execution. Still just\u00a0setup.<\/p>\n

    The Binding (EventID\u00a021)<\/h3>\n

    This is where I realized the attack actually happens: the binding connects the filter to the consumer.<\/p>\n

    Without the binding, you have a filter with nothing to execute. You have a consumer with no\u00a0trigger.<\/p>\n

    The binding LINKS them together.<\/p>\n

    In Sysmon, this is EventID 21\u200a\u2014\u200aWMI Event Consumer-to-Filter Binding Activity.<\/p>\n

    Once this binding exists, the attack is\u00a0armed.<\/p>\n

    Why APT29 (and 20+ Others) Use\u00a0This<\/h3>\n

    I was wondering: Why WMI? Why not just use a Registry Run key or Scheduled Task?<\/p>\n

    Here\u2019s what I\u00a0think:<\/p>\n

    WMI looks like a Windows function.<\/strong> Most defenders trust it by default. Most people think WMI activity is normal system behavior.<\/p>\n

    APT29, APT28, and others all chose WMI because it blends in. If a defender saw EventID 20 (WMI Consumer activity), they might think: \u201cThat\u2019s probably Windows doing Windows\u00a0things.\u201d<\/p>\n

    But if they saw Registry Run key activity, they\u2019d immediately think: \u201cThat\u2019s suspicious.\u201d<\/p>\n

    So WMI is harder to detect. That\u2019s why so many APT groups use\u00a0it.<\/p>\n

    The Attack\u00a0Timeline<\/h3>\n

    I was confused about when the actual execution happens. The answer: EventID\u00a04688.<\/p>\n

    EventID 4688 is process creation. This is when the malicious command actually\u00a0runs.<\/p>\n

    Here\u2019s the timeline:<\/p>\n

      \n
    1. Attacker creates Filter (EventID 19)\u200a\u2014\u200a\u201cWhen X event happens,\u00a0trigger\u201d<\/li>\n
    2. Attacker creates Consumer (EventID 20)\u200a\u2014\u200a\u201cRun this\u00a0command\u201d<\/li>\n
    3. Attacker creates Binding (EventID 21)\u200a\u2014\u200a\u201cLink filter to consumer\u201d<\/li>\n
    4. System triggers the event (boot, process creation, file write,\u00a0etc.)<\/li>\n
    5. Filter executes the\u00a0consumer<\/li>\n
    6. Sysmon captures EventID 4688\u200a\u2014\u200aprocess created (the malicious code\u00a0running)<\/li>\n<\/ol>\n

      So EventID 19, 20, 21 might happen at 3 AM on\u00a0Tuesday.<\/p>\n

      But EventID 4688 might happen at 8 AM on Friday when the trigger\u00a0fires.<\/p>\n

      That\u2019s why defenders miss this\u200a\u2014\u200athe setup and execution are days\u00a0apart.<\/p>\n

      What I Don\u2019t Understand Yet<\/h3>\n

      When I read about this, some things didn\u2019t\u00a0click:<\/p>\n

      Question 1:<\/strong> If the setup (EventID 19, 20, 21) happens at 3 AM, why does the trigger wait until\u00a0Friday?<\/p>\n

      Question 2:<\/strong> Can an attacker control WHEN the trigger fires, or does it depend on the system\u00a0event?<\/p>\n

      Question 3:<\/strong> If I see EventID 20 and 21 in my logs, how do I know if it\u2019s legitimate WMI activity or malicious?<\/p>\n

      Question 4:<\/strong> Where exactly do these WMI components get stored on disk? Is it Registry? Memory?\u00a0Both?<\/p>\n

      Why This Matters (Even Though It\u2019s\u00a0Old)<\/h3>\n

      APT29, APT28, APT19, APT33, APT37, APT38, APT40, APT41, Lazarus Group\u200a\u2014\u200aMITRE documents that 20+ groups use WMI persistence.<\/p>\n

      APT29 used it in the SolarWinds compromise to maintain backdoor access. But it\u2019s not just SolarWinds. It\u2019s everywhere.<\/p>\n

      Most defenders still miss it because they don\u2019t correlate WMI events with process creation\u00a0events.<\/p>\n

      That\u2019s what I want to understand: If the technique is old and documented, why are people still falling for\u00a0it?<\/p>\n

      Answer: Because WMI looks legitimate.<\/p>\n

      Open to Collaboration<\/h3>\n

      Building detection rules that actually work in real environments is what drives me. The gap between theory and practice is huge, and that\u2019s where the interesting problems\u00a0are.<\/p>\n

      If you\u2019re working on detection engineering, scaling your SOC, or trying to improve threat hunting in your environment, I\u2019m interested in talking about\u00a0it.<\/p>\n

      I\u2019m 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\u2019s\u00a0connect.<\/p>\n

      LinkedIn: https:\/\/www.linkedin.com\/in\/manishrawat-soc\/<\/a>
      GitHub:       https:\/\/github.com\/Manishrawat21\/<\/a><\/p>\n

      Sources<\/h3>\n