Event Triggered Execution (T1546): Detect fileless WMI persistence and event-based triggers

What is Event Triggered Execution?

Most persistence mechanisms run on a schedule or at boot. T1546 is different: it creates persistence that fires in response to specific system events, a user logging in, a particular process starting, a timer expiring, or even a failed logon attempt. The attacker's payload sits dormant until its trigger condition is met, then executes automatically without any human interaction.

The most dangerous sub-technique is T1546.003 (WMI Event Subscription). WMI subscriptions are entirely fileless: the persistence payload lives in the WMI repository database, not as a file on disk. No Registry entries, no Startup Folder shortcuts, no services. Traditional endpoint security tools that scan files and Registry keys miss WMI subscriptions completely, which is why state-sponsored groups like APT29 and APT3 have used this technique in high-value intrusions documented by Mandiant.

Part of the Persistence (TA0003) tactic in the MITRE ATT&CK® framework.

Key facts about T1546

How the attack works: attack scenario

WMI Event Subscription persistence (T1546.003)

A WMI event subscription consists of three components that the attacker creates: an Event Filter (the trigger condition), an Event Consumer (the action to execute), and a Filter-to-Consumer Binding (connecting the two). Once installed, the WMI service monitors for the filter condition and automatically invokes the consumer when triggered.

What this looks like in practice: the attacker runs a PowerShell command that creates a WMI subscription watching for system startup. Every time the machine boots, the subscription triggers a script consumer that executes an encoded PowerShell payload, downloading and running the attacker's implant without writing any files to disk.

The filter and consumer are stored in the WMI repository (OBJECTS.DATA file under C:\Windows\System32\wbem\Repository\). No files on disk, no Registry keys, no service entries - only WMI process behavior reveals the persistence.

Accessibility feature replacement (T1546.008)

Windows accessibility features (Sticky Keys via sethc.exe, Narrator via narrator.exe, On-Screen Keyboard via osk.exe) can be launched from the Windows logon screen before authentication. Attackers replace these binaries with cmd.exe or a custom payload, giving them SYSTEM-level command execution at the logon screen, bypassing authentication entirely. This technique has been used by ransomware operators to maintain backdoor access to systems even after the primary compromise is cleaned up.

AppInit DLL abuse (T1546.010)

The AppInit_DLLs Registry key causes Windows to load specified DLLs into every process that uses user32.dll, which is nearly every GUI application. By placing a malicious DLL in this key, the attacker achieves persistence and code injection simultaneously: every user-mode process loads the attacker's code on startup.

Real-world attacks using T1546

How to detect and investigate T1546 with Log360

Log360 provides two prebuilt rules for the most critical T1546 sub-technique (WMI subscriptions), plus custom rule templates for accessibility feature replacement and AppInit DLL abuse.

Detecting WMI event subscription execution

The Script Event Consumer Spawning Process rule (Trouble, Windows) catches the moment a WMI persistence payload executes. The WMI script event consumer host process (scrcons.exe) is a legitimate Windows binary, but it should rarely spawn child processes in normal operations. When scrcons.exe spawns PowerShell, cmd.exe, or any other executable, the attacker's WMI subscription has triggered and is executing its payload. The analyst sees the parent (scrcons.exe), the child process (the payload), and the command-line arguments, enough context to identify the threat immediately.

Catching the installation phase is equally important. The WMI ActiveScriptEventConsumers Activity rule (Trouble, Windows) detects the creation and activation of ActiveScript event consumers, the WMI consumer type that executes VBScript or JScript payloads. This rule triggers during the persistence installation phase, before the subscription has fired, giving the SOC team an opportunity to remove the persistence before it ever executes.

These two rules together cover both phases of WMI persistence: installation (ActiveScriptEventConsumers Activity) and execution (Script Event Consumer Spawning Process). When both fire on the same host, the investigation is straightforward: an attacker installed WMI persistence and it has already triggered.

Cross-referencing with WMI execution detection

WMI persistence (T1546.003) often overlaps with WMI execution (T1047). When investigating WMI persistence alerts, cross-reference with the T1047 detection rules for wmiprvse.exe behavior anomalies, particularly suspicious parent processes spawning wmiprvse.exe or wsmprovhost.exe. The combination of WMI execution anomalies and WMI persistence alerts on the same host strongly indicates an active WMI-based attack chain.

Custom rule templates for additional T1546 sub-techniques

Accessibility Feature Binary Replacement Monitor

This custom rule monitors Sysmon Event ID 11 (FileCreate) and Event ID 1 (ProcessCreate) for modifications to Windows accessibility binaries. When sethc.exe, utilman.exe, narrator.exe, osk.exe, magnify.exe, or DisplaySwitch.exe are replaced with non-Microsoft-signed binaries, or when cmd.exe or PowerShell.exe are renamed to these filenames, the rule fires with Critical severity.

Detection logic: Monitor file modifications in C:\Windows\System32\ targeting accessibility executable names. Compare file hashes against known-good Microsoft values. Any modification by a non-Windows-Update process indicates tampering.

AppInit DLL Registry Monitor

This custom rule monitors Sysmon Event ID 13 for modifications to the AppInit_DLLs Registry key. Any change to HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs or the LoadAppInit_DLLs value should fire with Trouble severity. While Microsoft has deprecated AppInit_DLLs in favor of Secure Boot, many environments still have it enabled, and attackers actively target it for process injection persistence.

WMI Subscription Audit Rule

Supplement the two prebuilt rules with a proactive monitoring rule: query the WMI repository periodically for all active event subscriptions and alert when new subscriptions appear that were not present in the last audit. Configure Log360 to run a scheduled script that executes Get-WMIObject -Namespace root\subscription -Class __EventFilter and compares results against a known-good baseline.

Investigation workflow in Log360

1. Identify the WMI consumer content: When a Script Event Consumer alert fires, the immediate question is: what script does the consumer execute? Query the WMI repository on the affected host: Get-WMIObject -Namespace root\subscription -Class ActiveScriptEventConsumer to extract the ScriptText property.
2. Decode the payload: WMI consumer scripts frequently contain encoded PowerShell commands. Decode Base64 arguments and analyze the payload for C2 indicators, download cradles, and lateral movement commands.
3. Trace the installation: Search Log360 for the event that created the WMI subscription. Look for PowerShell WMI cmdlets (Set-WMIInstance, Register-WmiEvent) or wmic.exe commands on the affected host in the hours or days before the subscription triggered.
4. Check the trigger condition: Query the WMI event filter: Get-WMIObject -Namespace root\subscription -Class __EventFilter. Understanding what triggers the persistence (boot, logon, timer, specific process) reveals how frequently it executes and what the attacker's operational pattern looks like.
5. Assess lateral reach: WMI subscriptions can be created remotely. Search for the same subscription name or consumer script across all monitored hosts to determine if the attacker deployed WMI persistence network-wide.

How to remediate and prevent T1546 attacks with Log360

Immediate containment

1. Remove the WMI subscription: Delete all three components: the filter, consumer, and binding. Use PowerShell: Get-WMIObject -Namespace root\subscription -Class __EventFilter | Where-Object Name -eq "FilterName" | Remove-WMIObject. Repeat for __EventConsumer and __FilterToConsumerBinding.
2. Kill the consumer process: If the subscription has already triggered, terminate scrcons.exe and any child processes it spawned.
3. For accessibility feature replacement: Restore the original Microsoft-signed binaries from C:\Windows\WinSxS\ (the Windows component store) using SFC (System File Checker).

Root cause remediation

• Trace the installer: WMI subscriptions are installed via PowerShell, wmic.exe, or WMI API calls. Search Log360 for WMI-related PowerShell commands on the affected host to find the installation event and the account that performed it.
• Audit all WMI subscriptions: Run a full WMI subscription audit across the environment: Get-WMIObject -Namespace root\subscription -Class __EventConsumer on every endpoint. Compare against the approved baseline (most environments should have zero custom WMI subscriptions).
• Check for companion mechanisms: WMI persistence is often deployed alongside scheduled tasks (T1053) and services (T1543) for redundancy.

Long-term hardening

• Restrict WMI remote access: Limit remote WMI access to approved administration systems using Windows Firewall rules and DCOM permissions, per CIS Controls guidance.
• Enable Sysmon WMI events: Sysmon Event IDs 19, 20, and 21 log WMI filter, consumer, and binding creation respectively. These provide direct telemetry for WMI subscription installation.
• Disable AppInit DLLs: Set LoadAppInit_DLLs = 0 and enable Secure Boot to prevent AppInit DLL injection. Most modern applications do not require this mechanism.
• Protect accessibility binaries: Use Windows File Protection / Resource Protection and monitor System32 binary integrity per NIST CSF file integrity monitoring guidance.
• Regular WMI audits: Schedule monthly WMI subscription audits using Log360's automated script execution. Any new subscription that does not match a change ticket is an investigation target.

Log360 automated response configuration

Configure automated responses via Log360's SOAR framework:

• WMI execution alert: When Script Event Consumer Spawning Process fires, automatically create a ServiceDesk Plus ticket, capture the WMI repository contents via script, and notify the incident response team.
• Accessibility feature alert: For Critical-severity accessibility feature replacement alerts, automatically isolate the host and escalate to incident response.
• Evidence preservation: Execute a script that exports all WMI event subscriptions, accessibility binary hashes, and AppInit DLL Registry values from the affected host.

Need to explore ManageEngine Log360? Schedule a personalized demo

FAQ