---
{
  "title": "Event Triggered Execution",
  "summary": "Event-triggered execution connects code to a system or application event.",
  "topic": "soc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    2
  ],
  "aliases": [
    "T1546"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1546: Event Triggered Execution",
      "url": "https://attack.mitre.org/techniques/T1546"
    }
  ],
  "editorialVersion": 2
}
---

## An event can become a recurring trigger

Event-triggered execution connects code to a system or application event. Ordinary software uses such mechanisms for automation and integration. An actor can abuse them so an action runs when a chosen condition occurs, potentially providing repeated execution without an obvious continuously running process.

The triggering event and registered action are both important. A suspicious program executing once does not prove an event subscription exists, while a registered action does not establish that its trigger occurred or that execution succeeded.

## An unexpected action follows a routine event

In a fictional endpoint case, an unfamiliar program appears after a common user activity. The analyst reviews event-related configuration, registration history, the creating principal, referenced code, and process evidence around the trigger.

A legitimate automation tool may explain the behavior. The team checks the application's owner, documented purpose, expected scope, and deployment history. A registration with a familiar name should still be checked against its actual target and conditions.

Different operating systems and applications implement event-driven behavior differently. Use the mechanism supported by the evidence rather than applying a Windows-specific explanation to every platform or treating every scheduled action as event-triggered execution.

## Review the relationship between editor and executor

Determine who can register or modify the action and which identity executes it. A configuration writable by one trust level but executed by another can create an important permission boundary. The actual authority and restrictions depend on the mechanism.

Preserve the trigger definition and referenced artifact before removal where practical. Runtime records may show only the resulting process, while configuration explains why it appeared. Combining those views can distinguish an active mechanism from an unused or failed registration.

[[scheduled-task-job]] describes time-based or scheduled execution mechanisms. [[boot-or-logon-initialization-scripts]] covers startup and sign-in scripts. The boundaries can overlap operationally, so map the specific behavior rather than adding labels indiscriminately.

## Remove the repeatable path

Restrict unauthorized registrations or configuration changes and review the access that created them. Terminating the resulting process alone may leave the trigger available to run again. Coordinate with the application owner because removing legitimate event integrations can break normal workflows.

For practice, compare a documented automation rule with a fictional event registration pointing to an unexplained program. Identify the creator, trigger, target, execution context, and completion evidence needed for a decision. Then consider a registration that never fired. Explain why it still deserves review but does not prove completed execution. [[persistence]] and [[incident-reporting]] help describe that distinction accurately.

## Related concepts

- [[mitre-attack]]
- [[logs-and-telemetry]]
- [[incident-response]]