Security teams detect execution activity by correlating process creation, script use, command-line content, parent-child process chains and unusual application launches. Look for tools running from temporary locations, encoded commands, office documents spawning shells, and user actions that do not fit normal baselines. Pair endpoint telemetry with identity and network signals to reduce false positives.
What execution activity looks like in ATT&CK data
Execution is easiest to spot when you treat it as a chain of observable behaviors, not a single event. Process creation, script interpreter launch, command-line arguments, and parent-child relationships often reveal the first execution step, while unusual application launches help distinguish legitimate automation from suspicious activity. The strongest detections usually come from combining host telemetry with user and network context so the same event can be judged against the surrounding baseline.
Look for execution that starts from unexpected locations, especially temporary directories, downloads folders, user profile paths, or other writable locations where trusted binaries should not normally run. Encoded or obfuscated command lines, Office documents spawning shells, and tools launched by non-interactive accounts are all strong indicators that execution is being used as an initial foothold, staging step, or living-off-the-land technique. MITRE’s ATT&CK Enterprise Matrix is the natural reference point for mapping those observations to specific execution techniques and downstream behaviors.
Because execution activity is broad, detection works best when you separate normal administrative use from anomalous runtime behavior. A scheduled script, software deployment, or endpoint management tool may be expected in one environment and highly suspicious in another. That is why process lineage, signer reputation, command structure, and the usual execution path for each host role matter more than any single alert field.
Which telemetry is most useful for finding execution
Process creation logs are the core source, but they become far more valuable when paired with script block logging, command-line auditing, file provenance, and application control events. Parent-child chains show whether a browser, document viewer, mail client, or office application is spawning a shell or interpreter, which is often more meaningful than the child process name alone. Script activity should be reviewed for unusual hosts, abnormal parameters, inline download-and-execute patterns, and scripts executed from writable or user-controlled paths.
Application launch telemetry adds another layer of confidence, especially when binaries run from folders that rarely host executables or when a program starts in a way that does not match its standard installation path. On managed endpoints, this kind of signal is often most useful when tied to a known-good baseline for each device class, business unit, and user group. The MITRE D3FEND Guide is useful here because it frames process and script analysis as defensive techniques that can be aligned to ATT&CK execution patterns.
Identity and network context make the difference between a noisy rule and a useful one. If a privileged account, service account, or rarely interactive user suddenly triggers local execution followed by outbound connections, the event deserves a much closer look than the same process launched by a well-understood admin workflow. A detection program that only watches the endpoint will miss that difference.
How to reduce false positives without missing real execution
The main challenge is not spotting every process start, it is deciding which execution events are meaningful enough to investigate. Baselines should account for host role, user role, software stack, and time of day, because execution that is ordinary on a jump host may be abnormal on a finance laptop or kiosk. Good tuning also distinguishes between command lines that are long for benign reasons and command lines that are long because they hide intent, load remote content, or stage the next step in an attack.
False positives are often created when teams key off one signal in isolation, such as a shell launch or a script interpreter. That approach is brittle because legitimate tools, software updates, and automation platforms can use the same primitives. Detection quality improves when you evaluate the full sequence, for example whether the process tree begins in a user document, whether the binary lives in a trusted path, whether the user normally runs that tool, and whether the command is consistent with the host’s expected job function.
For ATT&CK-centric programs, the most practical improvement is to turn execution detections into testable use cases and measure coverage against real telemetry sources. Detection Engineering Guide is a good companion for building, testing, and tuning those rules so execution alerts are both explainable and repeatable.
Risk and Threat Considerations
Execution is often the first stage where malicious activity becomes visible, but it is also easy for attackers to blend into routine administration. The risk is that high-volume, low-fidelity process alerts bury the few executions that actually matter, especially when the activity uses trusted tools, encoded commands, or document-based launch chains.
Failure mechanism: Attackers abuse legitimate process launch paths, script interpreters, and trusted parent processes to make malicious execution look routine. If telemetry is incomplete, poorly baselined, or not correlated with user and network context, the execution step is either missed or triaged too late.
Impact: Missed execution can allow payload staging, privilege escalation, credential access, or follow-on control of the host before defenders intervene. At scale, weak execution detection also reduces confidence in later ATT&CK coverage because the initial foothold is never reliably observed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Execution activity is commonly observed through command-line and script interpreter behavior. |
| T1204 — User Execution | Execution often begins when users open documents or click content that launches code. | |
| T1203 — Exploitation for Client Execution | Suspicious application launches from documents or browsers can indicate exploit-driven execution. | |
| Recommendation — Map process and script telemetry to T1059 sub-techniques and hunt for anomalous interpreter launches. Correlate user action, document opens, and spawned processes to detect user-driven execution chains. Review client-triggered process launches for exploit indicators and unexpected child processes. | ||
| NIST CSF 2.0 | DE.CM-01 — The environment is monitored to detect changes to systems and assets that could indicate cybersecurity events | Execution detection depends on monitored endpoint and process telemetry. |
| Recommendation — Monitor process creation, script activity, and application launches for anomalous execution events. | ||
| NIST SP 800-53 Rev 5 | AU-12 — Audit Record Generation | Execution detection requires host audit records for process and command-line events. |
| SI-4 — System Monitoring | System monitoring supports spotting suspicious execution and follow-on activity. | |
| Recommendation — Generate endpoint audit records for process creation, command lines, and parent-child process chains. Correlate endpoint, identity, and network monitoring to identify anomalous execution. | ||
Practitioner Guidance
What to prioritise: Start with process creation, command-line logging, and parent-child lineage on the hosts most likely to be used for initial execution, then extend coverage to scripts and unusual application launches. If you cannot explain an execution event from the host role and user role alone, treat it as investigation-worthy.
What to verify: Confirm whether the binary path, signer, launch parent, and user context are normal for that endpoint class. A shell started by an office document, a script run from a writable directory, or a tool launched by a non-interactive account should trigger immediate review, not automatic dismissal.
Practitioner takeaway: Reliable execution detection depends less on seeing every process and more on recognizing execution that breaks the expected story for that host, user, and process chain.
Related resources from NHI Mgmt Group
- How should security teams use MITRE ATT&CK in identity programmes?
- How do security teams know if automated MITRE ATT&CK coverage reporting is trustworthy?
- How should security teams use LLMs to map Sigma rules to MITRE ATT&CK?
- How should security teams use MITRE ATT&CK to improve detection coverage without trying to cover every technique?