Detecting and Mitigating Event Triggered Execution (T1546)

Event Triggered Execution (MITRE ATT&CK T1546) is a persistence and privilege escalation technique. It covers Linux, macOS, Windows, SaaS, IaaS and Office Suite. The idea is to attach malicious code to something that happens often, so the system itself keeps running it.

Operating systems let programs subscribe to events such as logons, or to user activity such as launching a specific application. Cloud environments offer functions and services that react to cloud events. Each of those hooks is a place an adversary can park code.

How attackers use it

After gaining access to a system, an adversary creates or edits event triggers to point at malicious content. Whenever the trigger fires, the content runs. That gives repeated execution without the adversary needing to come back.

There is a privilege angle too. Execution may be proxied by an account with higher permissions, such as SYSTEM or a service account, so an adversary can use a trigger to escalate.

The parent technique has many sub-techniques, and grouping them by platform makes them easier to hold in your head:

• Windows. Default file associations (T1546.001), screensavers (T1546.002), WMI event subscriptions (T1546.003), accessibility features (T1546.008), AppCert DLLs (T1546.009), AppInit DLLs (T1546.010), application shimming (T1546.011), Image File Execution Options (T1546.012), PowerShell profiles (T1546.013), COM hijacking (T1546.015) and Netsh helper DLLs (T1546.007).
• Linux and macOS shells. Unix shell configuration (T1546.004) and trap (T1546.005).
• macOS. LC_LOAD_DYLIB addition (T1546.006) and emond (T1546.014).
• Linux. Udev rules (T1546.017).
• Cross platform. Installer packages (T1546.016) and Python startup hooks (T1546.018).

How to detect it

MITRE's detection strategy for the parent has a separate analytic for each environment:

• Windows. Correlate unexpected changes to WMI event filters, scheduled task triggers or registry autorun keys with later execution of non-standard binaries by SYSTEM level processes.
• Linux. Look for inotify or auditd configuration changes that watch system files, combined with script interpreters or binaries run by cron or systemd timers.
• macOS. Correlate launchd plist changes with later unauthorized script execution or odd parent and child process trees involving user agents.
• Cloud functions. Watch for function creation triggered by specific audit log events, such as IAM changes or object creation, followed by anomalous behavior from new service accounts.
• SaaS workflows. Watch for Power Automate or similar logic app workflows triggered by file uploads or email rules that go on to forward data or access it in unusual ways.
• Office. Detect macros or VBA triggers set to run when a document opens or closes, often followed shortly by embedded payloads or command and control traffic.

The pattern holds across all of them. Find the configuration that defines a trigger, then watch what runs when it fires. A change to the trigger that nobody approved is the first signal, and a trigger that launches an unusual binary or script is the second.

How to reduce the risk

MITRE lists two mitigations for the parent, and the sub-technique pages add platform specific ones:

1. Manage privileged accounts. Control the creation, modification, use and permissions of privileged accounts, including SYSTEM and root. Since triggers often execute under those accounts, this narrows what a hijacked trigger can do.
2. Update software. Patch regularly to reduce exploitation risk.

At the sub-technique level, the common controls are application control to block unexpected binaries, code signing, restricted file and registry permissions, and disabling features you do not use.

Check your own environment

Read-only starting points, by platform:

# Windows: WMI permanent event subscriptions (PowerShell)
Get-CimInstance -Namespace root\subscription -ClassName __EventFilter
Get-CimInstance -Namespace root\subscription -ClassName CommandLineEventConsumer
Get-CimInstance -Namespace root\subscription -ClassName __FilterToConsumerBinding

# Linux and macOS: shell startup files for unexpected lines
grep -nE 'trap|curl|wget|nc ' ~/.bashrc ~/.bash_profile ~/.profile ~/.zshrc 2>/dev/null

# macOS: launch plists
ls -la /Library/LaunchDaemons /Library/LaunchAgents ~/Library/LaunchAgents

Then use this short list:

• Do you have a baseline for each trigger type on your standard builds?
• Are trigger locations covered by file and registry monitoring?
• Do cloud function and workflow creation events go to a log someone reads?
• Can you name an owner for every trigger that exists today?

Quick check

Sources

• MITRE ATT&CK T1546, Event Triggered Execution