How T1204 user execution shows up in intrusions and how to detect it
T1204 User Execution is the Execution tactic technique (TA0002) in which an adversary relies on a user to run malicious content, such as a file, link, image, copied text or shared library. In intrusions it usually appears where a phishing message, a poisoned download or a lure document turns one click or double click into the first step of the attack, so it often sits between initial access and the adversary's first command. This page targets Enterprise ATT&CK version 20.0, and T1204 has 5 sub-techniques, each tied to a delivery form. Any detection mapping you write should name the ATT&CK version it targets, because releases can rename, deprecate or revoke techniques, so recheck the sub-technique list whenever you upgrade your mappings. The ATT&CK tactic page for Execution is the natural starting point for that check.
The difficulty for a SOC lead is that the user's action looks normal. Opening a document, running an installer and clicking a link are everyday work, so an alert on the user action alone produces noise. The useful signal is what happens next. Process Creation telemetry can show a document viewer, browser or archive utility as the parent of a script interpreter, an unsigned binary or a process started from a user's download or temporary folder. Application Log Content from browsers and mail gateways can show the download or link that preceded it, and Network Connection Creation can show an outbound connection from the new process shortly afterward. Your first decision is which of these combinations your fleet never produces legitimately, because that baseline determines how noisy the rule will be.
Before writing rules, confirm three things in your own environment. First, check the enterprise-attack 20.0 STIX bundle to confirm the T1204 entry and its sub-techniques, and cite that version in your rule metadata. Second, confirm that endpoints emit the Process Creation and Network Connection Creation data your rules depend on, and that browser and mail logs reach Wazuh or Security Onion in a form you can query. Third, decide which mitigations you will rely on. Execution Prevention and Behavior Prevention on Endpoint are the ATT&CK mitigations mapped to this technique, and you should ask your endpoint vendor which of their controls implement each one. Then rehearse the chain in a private cyber range so you know the alert fires before an actual user is involved.
Which telemetry reveals user execution on each platform
This table maps the data components most tied to T1204 User Execution to the platforms where they matter and the open-source collectors that gather them. Read each row as a question to answer in your own environment: which signal, which collector, and which fields you must confirm before you trust a rule. The main takeaway is that process creation carries most of the weight on endpoints, while application logs and network data cover what a process event alone cannot show.
| Data component | Platforms where it helps | Open-source collectors | Signal to look for (in words) |
|---|---|---|---|
| Process Creation (DC0032) | Linux, macOS, Windows | Wazuh agent, Velociraptor, Sysmon-based pipelines | A user-opened document, archive or script spawning a shell, interpreter or unexpected child process. Confirm parent and child image fields, command line and user context in your collector. |
| Application Log Content (DC0038) | SaaS, IaaS, Office Suite, Linux | Wazuh log collection, Security Onion ingestion of application logs | A user action in a business application followed by an unusual file open or add-in load. Confirm the event identifiers and user fields exposed by each application. |
| Network Connection Creation (DC0082) | Linux, macOS, Windows | Zeek connection logs, Suricata flow records | A process or host that opens an outbound connection shortly after a user opened a file or link. Confirm source process availability, since network sensors usually see hosts, not processes. |
| File Creation (DC0039) | Windows, macOS, Linux | Wazuh file integrity monitoring, Velociraptor artifacts | A new executable, script or archive written to a user profile or temp path just before execution. Confirm monitored paths and whether hash fields are collected. |
| Network Traffic Content (DC0085) | Linux, macOS, Windows | Zeek protocol logs, Suricata alerts with payload inspection | Download content or document-delivered payloads crossing the sensor in plain text or decodable protocols. Confirm payload capture limits and encryption coverage before relying on it. |
Detection logic for user execution that a SOC can tune
The ideas below share one premise: T1204 depends on a person or a trusted application triggering the first malicious step, so the signal is the parent-child relationship between user-facing software and what it launches. Each pattern starts broad, then gets narrowed with allowlists, thresholds and time windows that your SOC owns and reviews.
User-facing app spawning a shell
Alert when a office suite, PDF reader, browser or messaging client creates a shell or script host as a child process. Start with the parent-child pair, not the child alone, because shells are common legitimate children of developer tools. Tuning levers are the parent image path, the command-line pattern, and a short per-host baseline. Expected false positives come from plugin frameworks, macro-driven internal tools and IT remediation scripts launched from a help desk session, so keep a documented exception list tied to signed publisher and install path.
Execution from user-writable paths
Flag processes started from user profile download, temp or cache folders shortly after an archive or document was opened on the same host. The time window between file creation and first execution is the main tuning parameter, and many SOCs begin with a short window and widen it after reviewing hits. Expected false positives include portable software, self-extracting installers and package managers that unpack into temp directories, so check code signature and origin before escalating.
Messaging client child then network
Correlate a browser or chat client that spawns a child process with a new outbound network connection from that child within a short window. Tune on destination reputation, first-seen domains for the host, and the child's binary identity, not on the connection alone. Software updaters, browser helper processes, video conferencing plugins and collaboration tools produce this pattern routinely, so maintain an allowlist keyed to vendor-signed binaries and review it at each release cycle.
Installer and updater suppression
Build a suppression layer for known updaters and installers before tuning detections, since they account for much of the noise in the first patterns. Record the signing identity, the install directory and the expected parent process for each product. Review suppressions quarterly, because an updater that is compromised or replaced will still match a loose path rule, and a narrow rule on signer and directory keeps the exception from becoming a blind spot.
Writing rules in Sigma
Express each pattern as a Sigma rule so the logic can move between SIEM back ends and be reviewed in version control. Map the log source to process creation telemetry on each platform and record the ATT&CK version your mapping targets, since ATT&CK releases can rename or revoke techniques. Ask your SOC to confirm the mapped data components against the ATT&CK STIX bundle for that version before deploying tuned rules to production.
How to confirm the detection fires before relying on it
This sequence proves that each T1204 User Execution detection produces the expected telemetry and alert in your SIEM, measures how quickly and how noisily it fires, and keeps it accurate as ATT&CK versions change.
Inventory the T1204 sub-techniques in scope
The detection owner lists the T1204 sub-techniques that apply to the platforms you run, such as Linux, Windows, macOS, IaaS and the other platforms covered by the technique page, and groups them into emulation families. Each family gets one row in a test register that names the ATT&CK version it targets, the detection strategy identifier and the owner. The step is done when every in-scope detection maps to exactly one family and no family is left without an owner. Confirm the sub-technique list against the ATT&CK version you are targeting, because the MITRE ATT&CK pages for the technique are the authoritative reference.
Define the benign test action for each family
For each family, the red team or cyber range engineer writes a benign test action in plain language, such as an approved test document or a harmless user-initiated launch of a non-malicious test binary inside the range. The action must be safe to run in production-like conditions, reversible, and free of payloads or real credentials. Each definition states the preconditions, the user persona and the cleanup step. The step is complete when a peer reviewer can rerun the definition without asking questions. Illustrative example: a range user opens a signed, harmless test file from a removable-media path, which exercises the same user-driven launch pattern without any malicious behavior.
Document the expected telemetry and SIEM alert
Before the test runs, the detection engineer records which data components should record the action, such as Process Creation, Network Connection Creation and Application Log Content, along with the fields expected in each event. They also write the alert name, severity and the rule or analytic in the SIEM that should fire, along with the triage step an analyst should take. This expectation sheet is the baseline for pass or fail. The step is done when the expectation sheet is signed off by both the detection owner and the SOC lead. Ask your SIEM and endpoint vendors to confirm which fields their products populate for each data component.
Execute the emulation in the cyber range
The red team runs each benign test action inside a private cyber range that mirrors your endpoint agents, logging pipeline and SIEM configuration. The operator records the exact start time, the user account used, the host, and any deviation from the written definition. Running the test on the range rather than production keeps user workflows and business systems out of scope. The step is complete when each family has been executed at least once and every run has a timestamped log bundle stored with the test register. Keep the operator's notes separate from the telemetry so that results can be checked later.
Measure alert latency and match results
The detection engineer compares the timestamp of the test action with the timestamp of the first telemetry event and the timestamp of the SIEM alert. The gap between these timestamps is the alert latency, and it is recorded per family alongside whether the expected fields were present. A run passes only when the expected telemetry arrived, the alert fired with the agreed name, and the analyst triage step could be completed from the alert alone. Any gap is logged as a finding with a root cause, such as a missing log source, a parsing error or a rule filter. Confirm acceptable latency targets with your SOC and record them in your own runbook, because this guide does not set them.
Measure false positives on normal user workflows
The detection owner runs the same detections against a sample of normal user activity in a non-production environment that reflects typical work, such as opening documents, installing approved software and running routine scripts. Each alert raised by normal activity is classified as a true positive for the test, a false positive or an unclear case, and the rate is calculated per family. The result tells you whether the detection is safe to route to analysts in production. The step is done when the classified sample is reviewed and each noisy rule has either a tuning change or a documented accepted risk. Confirm with your business owners which workflows are representative before the sample is built.
Sign off and file the evidence record
The detection owner compiles one evidence record per family containing the test definition, expectation sheet, raw telemetry references, alert screenshots or exports, latency results, false positive classification and the approver's sign-off. The record names the ATT&CK version and detection strategy identifier it validates. The SOC lead and the compliance lead review it before the detection moves into production or the existing detection is marked as validated. The step is complete when the record is stored in the evidence repository with a version number. Auditors reviewing your controls are independent of this work, so the record should be readable without a walkthrough.
Schedule regression runs tied to ATT&CK releases
The detection owner sets a regression schedule that re-runs every family whenever MITRE publishes a new ATT&CK version, and whenever the endpoint agent, SIEM or log pipeline is upgraded. The owner checks each release for renamed, deprecated or revoked techniques and sub-techniques, and for updates to the data components that a detection depends on. Any changed mapping reopens the evidence record for that family. The schedule is written into your change calendar with named owners. The step is done when the next regression trigger is recorded and the previous run results are archived. Use the ATT&CK updates page to watch for new releases and confirm the exact cadence with your own change management team.
Preventive controls that reduce user execution risk
T1204 depends on a person or a process opening something that runs. The six mitigations below act at different points: the user's judgment, the endpoint's allow and block decisions, the behavior of processes after launch, the logs that show what happened, and the accounts that can change what runs. Each card names what the control does and what to confirm with the vendor or your own team before you rely on it.
User training (M1017)
Training teaches staff to recognize lures that ask them to open an attachment, enable macros, accept a prompt or run a pasted command. For T1204 this is the first human decision point, and it works best when exercises use the same file types and lure patterns your environment actually receives. Confirm with your security awareness provider how simulated lures are logged, and whether reported messages feed back into your Audit and detection queues.
Execution prevention (M1038)
Execution prevention blocks unapproved binaries, scripts and installers before they start, based on policy such as allow lists, signer checks or reputation. It is the control most directly aimed at T1204.002 (malicious file) and T1204.003 (malicious image). Confirm with your endpoint vendor which file types it covers in audit mode versus enforce mode, how exceptions are approved, and whether macOS and Linux hosts use the same policy engine as Windows.
Behavior prevention on endpoint (M1040)
Behavior prevention stops a program after it starts when it does something a document viewer or browser should not do, such as spawning a shell, injecting into another process or writing to autorun locations. It catches T1204 cases where the user launched something that passed initial checks. Confirm with your vendor which behavioral rules are on by default, which are in alert-only mode, and how blocked actions appear in the telemetry you forward to your SIEM.
Audit (M1047)
Audit settings decide whether the evidence for a user-initiated execution exists at all. Process creation with command line, application logs and network connection records must be enabled and forwarded before an incident, or the investigation has nothing to show who ran what. Confirm with your platform team that the audit policy is applied on every host class, that retention covers your incident response window, and that log forwarding does not silently drop events during peak load.
User account management (M1018)
Limiting which accounts exist, which are active and which can sign in to workstations reduces what a single user click can reach. Remove shared and dormant accounts, and make sure ordinary users cannot change execution policy or install software without a request. Confirm with your identity provider how account lifecycle events are logged and whether role changes produce alerts that your detection team reviews.
Privileged account management (M1026)
A user execution that runs under a local or domain administrator account has far more reach than one that runs under a standard user. Privileged account management limits who holds elevated rights, uses separate admin accounts for administrative work and reviews privileged sessions. Confirm with your identity vendor how privileged sessions are recorded, how just-in-time elevation is approved and whether elevation events are sent to the same SIEM as your process telemetry.
What the SOC should do in the first hour after a user execution alert
The first hour after a T1204 User execution alert is about establishing whether a person was tricked or induced into running something they should not have, and whether that action has spread. Start by confirming the user and host context: the account that held the session, the device owner, the department, whether the user has elevated rights, and whether the host is a managed endpoint or a shared system. Then compare the alert with what the user was doing at that time. The key question is whether the parent application was expected. A document viewer that launches a script engine, or a browser that spawns a shell, is a different case from a user double-clicking an installer that IT pushed last week. Record your answer in the ticket before moving on, because it drives every decision that follows.
Next, pull the process tree for the activity window and the network connections the new process created. Look at what the child process was, who launched it, and what it did in the first minutes, such as whether it wrote files, modified scheduled tasks or reached out to an external address. Confirm which of these fields your Wazuh or Security Onion deployment actually captures for process creation and network connection events, because gaps in those sources will shape your confidence. Decide on isolation and account actions with the asset owner: isolating the host is the fastest containment step when the process has network reach, while suspending or resetting the user's credentials is warranted when the account may have been used to run the code under its own session. Document who approved each action and when.
Preserve evidence before you clean anything. Use Velociraptor or an equivalent collection tool to capture running processes, the process tree, recent network connections and the relevant user and application logs from the endpoint, and hash any suspicious binary or document you collect. Keep a written chain of custody and avoid rebooting or reimaging the host until collection is complete. Confirm with your legal and privacy team which data you may collect from user devices under your policy, because collection scope in regulated environments is often constrained. Finally, check whether the same file, sender or application appears on other endpoints, since user execution often repeats across a group of users. Whatever the outcome, schedule a short review so the first-hour findings feed the detection tuning and user awareness work described in the mitigations section.
Rehearsing T1204 detection and response in a private cyber range
This segment runs a private range with Windows and Linux endpoints forwarding telemetry to a Wazuh manager and a Security Onion stack. The range should mirror your production build, including the logging policy, agent versions and Sysmon or auditd configuration you actually run. Injects are simulated user actions that lead to a process launch from a document, archive or shortcut, described in words so the blue team must reason from the process tree rather than a known file name.
- Inject design: Plan a user opening a lure from a mail client, a browser download and a file opened from a network share. Vary the parent application so analysts cannot rely on one indicator.
- Good detection: Process Creation events show the user-facing application as the parent of an unexpected child process, and Network Connection Creation events follow within the same session. Alerts should reach an analyst within the time your runbook sets.
- Good response: The analyst isolates the endpoint through the agent, preserves the process tree and confirms the user identity before closing the case.
- Record for review: Timestamps from the endpoint and the Wazuh alert, the Security Onion session identifier, the rule or Sigma logic that fired, and any missed step.
- Confirm first: Check the Wazuh and Security Onion versions you deploy against current vendor documentation before writing the exercise plan.
Check whether the alert fired on the parent-child relationship or only on a file name, because the second is easy to evade.
This segment uses a small set of macOS workstations in the range, enrolled in the same log collection path as the Windows and Linux hosts. macOS endpoints often expose different signals, such as unified logs, Gatekeeper and quarantine decisions and code signing results, so the team needs to confirm what your chosen agent actually collects before scoping injects. Keep the tests on user-initiated paths that a normal employee could take.
- Inject design: Plan a user who opens a downloaded disk image, runs an installer package or launches a script obtained through a chat message. Include one case where the user declines a system prompt to test whether the team can see the decision.
- Good detection: Process Creation or equivalent telemetry shows the launching application and the child process, and the alert references the signing state or quarantine attribute where your tooling records it.
- Good response: The analyst checks whether the application was approved, isolates the workstation if the process is unexpected and reviews other hosts for the same package.
- Record for review: The collection source for each event, any gaps in unified log retention, the time from launch to alert, and whether the analyst needed information the agent did not supply.
- Confirm first: Verify with your endpoint agent vendor which macOS events it collects and at what retention before the exercise.
The review should state clearly which detections were absent on macOS, not only which ones fired.
This segment runs in a non-production cloud account or project, with a few workload instances that represent application servers. User execution in this setting usually begins with an operator or developer running a command or script the attacker has influenced, so the injects focus on what happens after the user acts and on the cloud control plane logs your provider records. Confirm the audit log types enabled in the range account before writing the exercise plan.
- Inject design: Plan a developer running a supplied script from a repository clone, and an operator opening a remote session to an instance using a credential that was not expected for that task.
- Good detection: Process Creation and Command Execution events on the instance are correlated with control plane audit events that show the same identity acting from an unfamiliar source.
- Good response: The team revokes the session or credential, snapshots the instance for forensic review and checks other instances the identity touched.
- Record for review: The audit log entries used, the account identifier of the range, the time to revoke access, and any step that required a manual lookup the runbook did not describe.
- Confirm first: Check which cloud audit and instance logging features your provider and agent support for the account type in use.
Keep the range account isolated so that exercise activity cannot reach production identities.
This tab covers the review that every segment feeds, so the team compares results across Windows, Linux, macOS and IaaS rather than writing four separate reports. Tie each inject to the ATT&CK version the detection mapping targets, and to the detection strategy identifiers for T1204 and its sub-techniques in that version. ATT&CK releases can rename or deprecate techniques, so the review should record the version used.
- Coverage matrix: Map each inject to the sub-technique it simulates, the data component it depended on, and whether the detection fired, fired late or did not fire.
- Mitigation evidence: Record whether Execution Prevention and Behavior Prevention on Endpoint blocked, alerted on or allowed each inject, with the policy version in force.
- Response timing: Note the time from first telemetry to triage, containment and closure, and which step took longest.
- Tuning actions: Assign each gap to an owner, a change request and a retest date in the next exercise.
- Audit trail: Keep the exercise plan, inject log and tuned rules together so an assessor can trace a finding to a change.
Ask the range provider to confirm the format of the exported evidence before the first run.
Questions SOC leads and detection engineers ask about T1204
How do you separate user execution from normal software installs?
Start by treating the user as the trigger, not the verdict. A user opening a file or running an installer is normal, so detections should look at what happens next: a script interpreter or unsigned binary spawned from a document viewer, a browser or a mail client, or an installer that writes to a user profile and then makes outbound connections. Build a baseline of approved installers per device group, using Process Creation events from Wazuh or Sysmon-style telemetry, and alert on deviations such as a parent-child pair that has never appeared in your fleet. Tune with allowlists tied to signed publishers and change tickets, and review every exception on a fixed cadence so the baseline stays current.
How do you close telemetry gaps for T1204 on macOS and Linux?
First, inventory what you actually collect on those hosts before writing rules. Many macOS and Linux fleets send authentication and syslog data but little process lineage, so a user-execution detection can silently fail. Confirm whether your agent records process creation with parent process, command line and user context, and whether it captures file creation in user directories and download locations. Where a gap exists, document it as a known limitation, add a compensating signal such as Network Connection Creation from user-launched processes, and schedule a validation run in your cyber range to prove the gap is closed. Confirm each capability with your chosen agent vendor or project documentation rather than assuming parity with Windows.
How do you map T1204 detections across ATT&CK version changes?
Pin every detection to the ATT&CK version it targets, for example Enterprise ATT&CK 20.0, and store that version in the rule metadata. ATT&CK releases can rename, deprecate or revoke techniques and sub-techniques, and v18 replaced technique-level detections with detection strategies and analytics, so a rule written against the old structure may point to content that no longer exists. Re-check the mapping against each new release using the STIX bundles published in the attack-stix-data repository, diff the sub-technique list for T1204, and record every change in your detection register. Assign an owner to review the diff whenever a new version ships.
How do you measure detection validation coverage for user execution?
Measure coverage per sub-technique rather than per tactic. For T1204, list each of its five sub-techniques, then record for each one which analytics, data components and platforms have a rule, which rules have been validated in a cyber range, and when they were last tested. A rule counts as validated only when a controlled test produced the expected alert in your SIEM or Wazuh manager, with the expected fields populated. Report the proportion of validated sub-techniques per platform, and flag platforms where the data component is missing. Confirm with your own environment which platforms you actually collect telemetry for before reporting a percentage to leadership.
Which mitigations for T1204 can you implement without rebuilding the fleet?
The ATT&CK mitigations mapped to T1204 most relevant here are Execution Prevention and Behavior Prevention on Endpoint. Execution Prevention covers controls that block untrusted code from running, such as application allowlisting or code signing enforcement, and it is usually rolled out in audit mode first to find legitimate software that would break. Behavior Prevention on Endpoint covers blocking suspicious process behavior, typically through endpoint protection policies. Both can be phased by device group. Ask your endpoint platform owner which policies are available on each operating system, and document the audit-to-enforce schedule with exception owners before enabling blocking.
How do you rehearse T1204 detection and response in a private cyber range?
Build a range that mirrors your production endpoint builds, your logging pipeline and your alert routing. Then run scripted scenarios that follow the T1204 sub-technique you are testing, using benign, pre-approved simulation content rather than live malicious code. For each run, record the expected telemetry, the alert produced, the time to triage and whether the response playbook was followed. Repeat runs after every rule change or agent upgrade, and keep the results as evidence. DeployOpen can plan, build and run this kind of exercise as part of a fixed-scope engagement, with scope and deliverables agreed in writing before work starts.
Can our own team run T1204 detection validation without outside help?
Often yes, if you have detection engineering capacity, a lab that matches production logging and a clear test plan. The work breaks into rule authoring, telemetry checks, controlled test runs, tuning and evidence capture. Teams that lack a repeatable range, or that have no one to review ATT&CK version changes, tend to stall after the first pass. Ask yourself who owns each step, how many hours per month that ownership needs, and whether a retainer for ongoing testing would be cheaper than building the capability internally. A written scope from any provider should list which of these steps it performs and which remain yours.
How DeployOpen builds T1204 detections and range scenarios
Detection work for T1204 User execution starts with a written scope agreed before any engineering begins. DeployOpen plans fixed-scope detection engineering around the platforms your organization already runs, such as your Wazuh or Security Onion deployment, your Sysmon or Linux audit telemetry, and your endpoint protection's execution prevention settings. The scope should name which operating systems are in play (Linux, Windows, macOS, and the IaaS control plane), which of the five sub-techniques are covered, and which ATT&CK version the mappings target. Because ATT&CK v18 moved detections into detection strategies and analytics, and later releases can rename or deprecate content, the agreed version should appear in every deliverable. Ask us to confirm how each data component referenced for T1204 is collected in your environment before you accept a scope.
Purple team exercises follow the same written plan. DeployOpen's security testers and your detection engineers work from a shared list of user execution behaviors, such as a user opening a document that launches a child process, a browser download being run directly, or a container image being pulled and started by a person rather than a pipeline. Each behavior is run in a controlled way, and the defenders record whether the expected alert fired, how long the alert took to reach the analyst queue, and which fields were missing. Gaps become tuning tickets with named owners. Your team should decide in advance who approves test activity, which hosts are in scope, and what evidence must be kept for later review.
Range scenarios are prepared as written deliverables in a private cyber range that matches your environment as closely as the agreed scope allows. A typical package includes the scenario narrative, the telemetry expected at each step, the detection logic in Sigma or the platform's native format, the validation checklist, and the response runbook. Ask for the list of hosts, accounts and network segments the range will contain, and confirm that no production credentials or data are used. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so treat our deliverables as inputs to their review.
