Why T1546 event triggered execution matters for privilege escalation
The SOC lead's problem with T1546 is that the adversary does not need to be running anything when the privilege gain happens. Under the Privilege Escalation tactic, TA0004, ATT&CK defines the adversary goal as trying to gain higher-level permissions, and T1546 Event Triggered Execution achieves this by registering code or configuration that waits for a system event, such as a logon, a service start, a file association being opened or a shell starting, and then runs under the context of whatever process or user triggers it. Because the trigger is a normal operating system event, the resulting activity often looks like routine administration or user behavior. The practical consequence is that a process-name alert alone will miss much of it, and detection has to look at what was registered, by whom, and what ran as a result.
T1546 is a technique with 18 sub-techniques spread across Linux, macOS, Windows and SaaS and other platforms, so the detection inventory you need depends heavily on which estate you operate. In intrusions, the technique tends to show up after an initial foothold, when an adversary wants a mechanism that survives reboots or user sessions and that can elevate when a privileged user logs in or an application starts. Your first decision is therefore scope: confirm which platforms and sub-techniques are relevant to your environment, and map the data you already collect, such as process creation, command execution and file metadata, against them. Ask your detection engineers to document the gaps before you commit to a coverage target.
Target ATT&CK version 20.0 for the mappings in this page. Technique and sub-technique mappings change between releases, and MITRE can rename, deprecate or revoke entries, so any detection content you build should record the version it was written against and be rechecked when the knowledge base is updated. Confirm the current version in your own tooling and in the MITRE ATT&CK updates page before you freeze your rule set. A quarterly review of the T1546 mappings against the latest release is a reasonable starting point for most teams, and the cadence should be agreed with your detection owners rather than assumed.
Which telemetry reveals T1546 activity
This table maps the ATT&CK data components most relevant to T1546 to the signal a defender should look for and the open-source collector that can gather it. Coverage differs by operating system and by how each collector is configured, so treat each row as a starting point to confirm in the client's own environment. The main takeaway is that no single data source covers all eighteen sub-techniques, so process, file and registry telemetry should be combined.
| Data component | Signal to look for | Open-source collector |
|---|---|---|
| Process Creation (DC0032) | Processes launched from shell profile, init or event-hook contexts, with unexpected parent-child pairs and command arguments | Sysmon-based pipeline, auditd, Wazuh agent |
| Command Execution | Commands run at logon, logoff, shell start or after a configured event, recorded with the triggering context | auditd, Wazuh log collection, Velociraptor artifacts |
| File Metadata (DC0059) | Creation or modification of profile files, startup scripts, configuration hooks and their owner, permissions and timestamps | Wazuh file integrity monitoring, auditd file watches, Velociraptor |
| Windows Registry Key Modification (DC0063) | Writes to registry keys that trigger execution at events such as logon, Explorer start or COM object load | Sysmon registry events, Wazuh Windows event collection, Velociraptor |
| Logon Session Metadata (DC0088) | Logon and session events that precede event-triggered launches, including account, source and session type | Windows Security event logs via Wazuh, auditd login records, Zeek for remote session context |
| Network traffic (where event triggers call out) | Outbound connections initiated shortly after a logon or startup event from an unexpected process | Zeek connection logs, Suricata alerts, Security Onion |
Detection logic for T1546 on each platform
T1546 hides behind legitimate event hooks, so detection depends on knowing which hooks exist on each platform and which changes to them are normal. The cards below pair a change or event to correlate with a baseline and the false positive sources that usually explain it away. Sigma rule concepts are described in words so each team can translate them into its own SIEM.
Linux shell profile and init changes
On Linux, event-triggered hooks often live in shell startup files, dynamic loader configuration and init or systemd unit definitions. Correlate file creation or modification in these locations with the process that made the change and the user session that owned it. Baseline which files configuration management writes and on what schedule, then alert on edits made by interactive sessions or by processes with no package or deployment parent. Expect false positives from configuration management runs and package post-install scripts, and tune by allowlisting known deployment service accounts rather than by suppressing the path.
macOS launch agent and daemon writes
On macOS, launch agents, launch daemons and login items are the common event-triggered locations to watch. Use File Metadata or file integrity telemetry to flag new property list files in these directories, and compare the writing process against the software that installed it. Helper tools from software installers and MDM enrollment routinely create these files, so build an allowlist keyed on signed installer identity and MDM management profile rather than on file name. Review new entries that reference unsigned binaries or user-writable paths first.
Windows registry and startup folder changes
On Windows, the sub-techniques with the most ground to cover include Windows Management Instrumentation event subscriptions, registry run keys and Image File Execution Options, along with startup folders. Correlate Windows Registry Key Modification events on these keys with the creating process and its parent, and watch for WMI consumer and filter creation. Software installers, endpoint agents and administrator scripts create many of these entries, so maintain a baseline per host role and tune thresholds by how often a key changes across the fleet, not by a fixed count.
Process creation tied to hook execution
Process Creation telemetry shows when a hook actually runs, which is often more useful than the configuration change itself. Correlate a child process started by a shell, service host or scheduler with a recent hook modification on the same host within a short window. Thresholds should reflect normal boot and logon volume for each host group. Expect noise from login scripts, scheduled maintenance and update agents, so record the expected parent and command context in the baseline and alert only on deviations from it.
SaaS admin and automation hooks
On SaaS platforms, event-triggered execution appears as workflow rules, webhooks, connected applications and automation triggers created or edited by a user. Ingest the platform's administrative audit log and alert on new triggers created outside change windows, triggers that call external endpoints, and changes made by accounts that normally do not administer automation. Integration onboarding and approved low-code builders produce much of this activity, so confirm with each vendor which audit events are exposed and how long they are retained before setting thresholds.
Baselines and change correlation
Across all platforms, the common control is a documented baseline of expected hooks per host role, refreshed after each approved change. Store that baseline in version control so that configuration management, installer and administrator changes carry a ticket reference. Alerts that cannot be matched to an approved change are the priority, and unmatched changes can be routed to a Sigma rule that fires on the absence of a matching change record. Confirm with your change management system whether it can supply these records to the SIEM.
How to validate the T1546 detection in a lab
This sequence turns T1546 detection rules into measured results by planning a controlled emulation, recording the telemetry each detection should produce, and documenting where alerts fire, arrive late or do not fire at all. The output is a validation record that the detection team can rerun after every rule change or platform upgrade.
Fix the target ATT&CK version
The test plan names ATT&CK v20.0 as the target version, because release notes show that MITRE can rename, deprecate or revoke techniques between versions and sub-technique mappings must match the version your rules were written against. The detection lead records the version in the plan header and confirms that every T1546 sub-technique in scope exists in that version's Enterprise bundle. Done means the plan lists the version, the bundle reference and any sub-techniques flagged as changed since the previous version you tested.
Agree scope and rules of engagement
The security lead, system owners for each in-scope Linux, macOS, Windows and SaaS platform, and the range operator sign a written scope that names the hosts, accounts, tenants and time window allowed for the exercise. The document also states who can halt the exercise, how the SOC is informed, and which actions are off limits, such as touching production identity providers. Done means a signed scope document exists and the SOC on-duty lead has confirmed the notification path in writing.
Select sub-techniques to cover
The team chooses which of the 18 T1546 sub-techniques to test, ranked by platform relevance, data source coverage and the rules already deployed in Wazuh, Security Onion, Sigma or other tools in use. Coverage gaps where no telemetry exists are recorded as gaps rather than tested blindly. Done means a coverage matrix maps each selected sub-technique to its platform, data component and the rule identifiers that should respond.
Define expected telemetry per detection
For each selected rule, the detection engineer writes down the data components expected to carry evidence, such as Process Creation, Command Execution or File Metadata, the log source that should contain them, and the fields the rule reads. This sets the pass criteria before the exercise starts, so the team cannot judge results after the fact. Done means every rule in the matrix has an expected-telemetry entry reviewed by a second analyst.
Run the emulation in the private range
A trained operator runs an agreed emulation plan inside the private cyber range, using the approved tooling and a fixed sequence, while an observer logs start and end times for each action. The operator does not improvise outside the plan, and the observer keeps a timeline that can later be compared against alert timestamps. Done means the timeline records every action with a time, host and account, and the operator signs that the run followed the plan.
Record fire rates, latency and gaps
The detection team compares the observer timeline with the SIEM and EDR alert queues, recording for each sub-technique whether an alert fired, how long it took from action to alert, and whether the telemetry was present but unread or absent altogether. Partial matches, such as an alert that fires on a different sub-technique, are logged separately. Done means a results table exists with fire rate, latency and gap cause for every row in the coverage matrix.
Fix gaps and rerun the affected tests
Each gap is assigned an owner and a category, such as missing log source, parser error, rule logic or tuning noise, and the fix is applied in a change record. The affected sub-techniques are rerun in the range, and the results are compared against the original run to confirm the fix worked without raising false positives in the rule's test data. Done means every gap has a closed change record and a rerun result that the detection lead accepts.
Archive the validation record
The team stores the scope, coverage matrix, expected telemetry, timeline, results table and change records together under the ATT&CK v20.0 version label so the evidence can be reproduced and shown to auditors or assessors. The record also notes the date each detection was last validated, so the next upgrade or rule change triggers a targeted retest. Done means the package is in the agreed evidence repository and the detection lead has signed the summary.
How T1546 detections map to ATT&CK data components
ATT&CK v18 changed how detections are expressed. Technique pages no longer carry the detection guidance themselves. Instead, the detections are described as detection strategies identified by DET IDs, each broken into analytics, and those analytics are anchored to data components identified by DC IDs. For T1546 Event triggered execution, this means a detection for a specific sub-technique (for example, a rule watching for changes to a profile file or a registry run key) should be traced to the detection strategy that covers it, then to the data components that strategy depends on. Data components such as Process Creation (DC0032), File Metadata (DC0059) and Windows Registry Key Modification (DC0063) are the telemetry anchors most often referenced by Privilege Escalation techniques, so they are where your collection gaps will show up first. Confirm the current DET and DC identifiers against the ATT&CK v18 release notes and the STIX bundle for the version you target, since data sources were deprecated in that release and older mappings may still point to them.
Record each mapping as a row you can audit. A usable register has one row per technique or sub-technique, with columns for the parent technique (T1546), the sub-technique ID, the DET ID, the data component IDs, the log source that supplies each component (for example, Linux audit records, Sysmon events, or macOS unified logs, depending on your estate), the detection rule that implements the analytic, the ATT&CK version targeted, and the date of last validation. Keep the ATT&CK version in the record itself, because releases such as v19 and v20 can rename, deprecate or revoke techniques and the mapping must be re-checked against each one. Store the register in version control next to your rule repository so that a change to a rule and a change to its mapping land in the same review.
Use the register to drive the update cycle. When a new ATT&CK release is published, diff the STIX bundle for the enterprise domain against your previous version and filter for the T1546 entries and their sub-techniques. Any changed DET ID, retired data component or revoked sub-technique becomes a ticket with an owner. Ask your detection engineering team to confirm, for each row, whether the required log source is still being collected in every in-scope platform, since a data component that is mapped but not ingested gives you no coverage. Keep the register as evidence of coverage decisions, and treat it as a living document rather than a one-time deliverable.
Preventive controls that reduce T1546 exposure
T1546 depends on attackers finding a place to register a trigger, such as a startup hook, a configuration file or a subscription, and having that trigger run with higher privileges. The two ATT&CK mitigations below reduce that exposure by controlling what code runs with elevated rights and who can change the components that events invoke.
Keep trigger-bearing software patched
Many T1546 sub-techniques abuse legitimate components that already run at boot, at logon or on a schedule, such as shell profiles, service components, and event handlers in the operating system and its utilities. Mitigation M1051 (Update Software) reduces the chance that a known flaw in those components is used to write a trigger in the first place. Ask each platform team to list the agents, hypervisor tools, administration frameworks and shells that register event hooks on your hosts, then confirm the patch source and the window for each. Check the vendor advisory feed for those products, not only the operating system.
Limit who holds privileged accounts
Mitigation M1026 (Privileged Account Management) addresses the step after a trigger is planted, when a standard account or process would otherwise be able to register something that runs as an administrator or root. Restricting administrative rights to named, time-limited accounts means fewer identities can write to startup locations, service definitions or event subscriptions. Review which accounts can edit system-wide profiles, scheduled task definitions and service configuration, and confirm that changes to those objects require an approved privileged session.
Separate build and admin write access
Trigger locations often sit in directories that build pipelines and configuration management tools write to on every run. If a pipeline account can change a system-wide startup file or a shared profile, a compromise of that pipeline becomes a privilege escalation path. Confirm that deployment identities hold write access only to the paths they manage, and that changes to shared startup or event configuration pass through a reviewed change process. This is a configuration question to answer in your own environment, not a product feature to purchase.
Baseline startup and event locations
A preventive control only holds if the owners of trigger locations know what normal looks like. Record the expected contents of system-wide shell profiles, service directories, scheduled task folders and cron locations on a reference build, and compare future hosts against that baseline. Deviations found during change windows should be reviewed as possible T1546 activity, not silently accepted. Ask your configuration management team which files they already own and which are changed by hand.
Triage and response when a T1546 alert fires
Start by deciding whether the alert describes a real trigger or a known administrative change, because that decision determines whether the rest of the response is containment or routine closure. Confirm which event trigger fired (for example, a Linux service or shell profile file being written, a Windows registry run key or WMI subscription being created, or a SaaS automation rule being added or edited) and record the affected host, account or tenant, the time window and the process or identity that made the change. Then check the change against your approved change records and configuration management system. An alert that matches a ticket, the author named in that ticket and the expected file or key content can usually be closed with notes. An unmatched change, or a matching ticket whose content differs from what was written, should be treated as suspicious until proven otherwise.
Once the host or tenant is confirmed, scope the same configuration across the estate. Query your EDR, Wazuh or Security Onion data for the same trigger type, file path, registry key or SaaS rule name across all hosts and tenants in the same time window, and check whether the same identity or build image created them. Preserve evidence before you change anything: capture the triggered file or key, its hash and metadata, the process tree that wrote it, and the relevant logs, and keep a chain of custody record. Snapshot a virtual machine before isolating it when the platform allows this without destroying volatile data. Decide on containment based on the evidence you have, such as isolating a single host, disabling a SaaS automation or revoking a session token, and document the decision and its owner.
Coordinate early with the system owners who run the affected platform, because they can confirm intended changes, approve containment steps that affect service availability and restore known-good configuration. Follow your incident response procedure for severity, escalation, legal or privacy notification and communications, and assign a single incident lead. Confirm with your platform team who holds the authority to disable a SaaS integration or pause a deployment pipeline, and rehearse that handoff in your cyber range so it is not first tested during a live alert. After containment, feed the outcome back into the detection: record whether the alert was a true positive, tune the allow list only against documented change records, and update the runbook for the ATT&CK version you target.
Rehearsing T1546 detection in a private cyber range
On Linux, the range should mirror the hosts your organization actually runs: a small set of representative servers, a workstation image and at least one host with the audit and log shipping agents your production build uses. The facilitator plans injects around event triggers that persist across reboots or user logins, such as shell profile files, scheduled jobs, service unit definitions and dynamic loader configuration, all described at a conceptual level for the blue team. Detection should show that the file or configuration change was observed, that the process started by the trigger was linked to its parent, and that the alert reached an analyst within the timeframe your runbook defines. Good response means the analyst can tell a legitimate administrative change from an unexpected one, preserves the affected file, and routes the case to the platform owner.
- Environment: Use hosts built from the same configuration management code as production, with the Wazuh agent or equivalent collector enabled.
- Injects: Plan changes to login and startup configuration in separate waves, so the team sees how alerts differ by trigger type.
- Detection check: Confirm that file integrity events and process creation records both reach the SIEM and can be correlated by host and time.
- Response check: Verify that the analyst can compare the changed file against a known-good baseline before deciding on containment.
- Scope note: Confirm with your platform team which Linux distributions and init systems are in production before building the range.
Check that every Linux inject has a documented expected outcome and a named owner who will review the result.
The macOS range is most useful for teams that manage a fleet of endpoints and need to see how event triggers appear across user and system scopes. Facilitators should build a standard workstation image, enroll it in the management tooling your organization uses, and confirm that the endpoint telemetry agent reports launch configuration and login item changes. Injects should focus on how a trigger is registered, how it fires on login or on a schedule, and whether the change is attributed to a user or to a system process. Detection should answer three questions quickly: what changed, which account made the change, and whether the launched process has a plausible business purpose. Response should emphasize isolating the endpoint without destroying the evidence that the trigger left behind.
- Environment: Use managed workstation images with the same security baseline as production, including the endpoint agent and log forwarding.
- Injects: Separate user-scope triggers from system-scope triggers, since they usually need different owners and different approvals.
- Detection check: Confirm that the telemetry shows the registration event and the later execution event as linked records.
- Response check: Verify that the analyst can capture the relevant configuration files before remediation changes them.
- Vendor confirmation: Ask your endpoint vendor which launch and login item events their product records and at what level of detail.
Check that the range results distinguish between user-level and system-level triggers so the response runbook can be split accordingly.
Windows is where most event triggered execution detection programs spend the most effort, because the platform offers many trigger types across services, scheduled tasks, registry-based startup entries, WMI subscriptions and COM handlers. The range should include a domain-joined workstation, a member server and a domain controller or a close equivalent, with event collection configured to match the audit policy in production. Facilitators plan injects that alter a registry startup location, a scheduled task definition and an event subscription, then observe which of these produced telemetry in the SIEM. Good detection correlates the configuration change with the later execution and with the account context. Good response includes checking whether the same trigger has appeared on other hosts through the central management tooling.
- Environment: Configure audit policy and Sysmon or an equivalent source to match production, and document any gaps in writing.
- Injects: Cover at least three distinct trigger families so the detection coverage is measured across them, not just one.
- Detection check: Confirm that registry modification and process creation events from the same host can be joined in the SIEM.
- Response check: Verify that the analyst can enumerate the same trigger across the fleet within the runbook's expected window.
- Confirm: Check with your Windows administration team which event subscriptions and logging policies are already enforced by group policy.
Check that each inject records which telemetry source produced the first useful signal, since that determines where detection engineering effort goes next.
SaaS platforms expose event triggered behavior through automation rules, workflow triggers, webhooks, integrations and scheduled actions. The range for this tab is a sandbox tenant of the SaaS product your organization uses, configured with the same administrative roles and integrations as production, and with audit logs exported to the central log platform. Injects should model a change to an automation rule or integration that runs with elevated permissions when a specific event occurs, such as a record update or a user sign-in. Detection depends on whether the SaaS audit log records who created or changed the rule, what the rule runs, and which service account it uses. Response should focus on disabling the trigger, reviewing the actions it performed, and rotating any credentials it could have used.
- Environment: Use a sandbox tenant with production-equivalent roles, connected integrations and audit log export enabled.
- Injects: Include one trigger tied to a privileged service account and one tied to an ordinary user, so the team can compare alert severity.
- Detection check: Confirm that the SaaS audit records for rule creation and modification reach the SIEM with the actor identity.
- Response check: Verify that the analyst can list every action a suspicious trigger performed over its active period.
- Confirm: Ask each SaaS vendor which audit events their product records for automation and integration changes, and how long those logs are retained in your plan.
Check that the SaaS tab results are reviewed by the application owner as well as the security team, since they know which automations are expected.
Questions detection engineers ask about T1546
How do we handle the false positives from routine startup and automation changes?
Expect them, and tune for them before you alert on them. Most noise comes from legitimate software that writes startup entries, scheduled automation, profile scripts or service helpers during installs and updates. Build an allowlist from your own baseline rather than from generic examples, keyed on the signer, the installing package manager or configuration management job, and the host role. Route unmatched events to a review queue first, then promote stable patterns to alerting. Track how many alerts each rule produces per week so you can see whether tuning is working. Confirm with your change management team which deployment tools write these locations so the allowlist reflects real change windows.
How should we version detections against ATT&CK releases?
Pin every detection to the ATT&CK version it was written against, and record that version in the rule metadata. MITRE releases changes on a regular cadence, and its update pages note that releases can rename, deprecate or revoke techniques and sub-techniques. The current releases the pillar research covers are v18 (October 28, 2025), v19 (April 28, 2026) and v20 (October 13, 2026). When a new version lands, diff the technique and sub-technique IDs against your mapping, review changed data components, and retire or re-map rules that no longer match. Keep the mapping in version control so audits can see what changed and when.
Which T1546 sub-techniques should we cover first?
Start with the sub-techniques your own environment exposes most and that your sensors can observe well. Rank them by three factors: whether the platforms you run are in scope, whether you already collect the needed telemetry such as process creation, file metadata or registry changes, and how much legitimate change happens in that location. A practical first pass is to cover the platforms with the highest privilege exposure, such as domain controllers or cloud-hosted Linux fleets, before the long tail. Document the reasoning so that coverage decisions can be reviewed later. The full sub-technique list should be confirmed against the ATT&CK version you target.
How do we test detections without disrupting production?
Test in a private cyber range or isolated staging environment that mirrors your production logging pipeline, not in production itself. Replay recorded or simulated telemetry through your SIEM or Wazuh rules, confirm the alerts fire with the right fields, and check that allowlists suppress known benign changes. Where you run controlled simulations, limit them to agreed hosts and time windows, record every action, and have a rollback plan. Written rules of engagement and a named approver should exist before any exercise. Confirm with your security testing provider how they scope and log such exercises.
How do we measure detection coverage for T1546?
Measure coverage at the level of detection analytics, not just technique names. For each T1546 sub-technique you target, record which data components feed the rule, whether the telemetry is present on the relevant hosts, whether the rule has been tested, and the date of the last successful test. Tools like the ATT&CK Navigator can show mapped and tested coverage across the matrix. Report gaps as telemetry gaps, rule gaps or validation gaps, since each needs a different fix. Ask your team to define these three states in writing so coverage numbers are comparable across reviews.
Which telemetry do we need before writing T1546 rules?
Confirm that you collect process creation events, file metadata for startup and configuration locations, and registry key modification events on Windows, where those data components apply. On Linux and macOS, check that you capture process execution, file change events for profile, service and scheduling paths, and authentication context. Map each sub-technique to the data components listed for it in the ATT&CK version you use, then verify coverage on sample hosts. Missing telemetry is the most common reason a rule looks correct on paper but never fires in production.
Does a single detection rule cover all of T1546?
No. T1546 is a broad technique with many sub-techniques across platforms, and each one uses different locations and triggers. A single rule usually covers one behavior on one platform, such as changes to a particular startup mechanism or a particular event subscription. Plan a set of rules per sub-technique and platform, supported by baselines and allowlists. Expect the set to change as ATT&CK releases update the sub-techniques, so review it on each version change.
How DeployOpen builds T1546 detections and range scenarios
DeployOpen works on T1546 Event triggered execution as a fixed-scope engagement inside the client's own infrastructure, with detection content mapped to the ATT&CK version agreed in writing. Each step produces documented logic, tested telemetry and range exercises that the client's team can rerun.
How we scope
- Confirm which T1546 sub-techniques apply to the platforms the client actually runs, such as Linux, macOS, Windows or SaaS.
- Inventory the telemetry sources available, including process creation, file metadata and registry modification, and note any gaps.
- Record the target ATT&CK version and the mitigations in scope, including Update Software and Privileged Account Management, in the written scope.
How we build
- Write detection logic for the agreed sub-techniques in Sigma and translate it to the client's SIEM or Wazuh rule format.
- Test each rule against benign administrative activity such as service installs and profile changes to measure false positives.
- Build a private cyber range scenario that triggers each event-based persistence path in a controlled, non-production environment.
How we hand over
- Deliver a detection catalog that maps each rule to its T1546 sub-technique, data components and version of ATT&CK.
- Provide range runbooks describing expected alerts, analyst steps and evidence to capture during each exercise.
- Document configuration, known gaps and tuning decisions so the client's team can maintain the content after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the initial engagement.
- Re-validate rules when ATT&CK releases rename, deprecate or revoke techniques, and confirm the impact with the client.
- Ask any support provider to confirm response times, coverage and handover terms in writing before work starts.
