Execution is the ATT&CK tactic for an adversary running code on a target system. Attackers use scripts, command shells, scheduled tasks or malicious documents to start payloads and move from initial access to active compromise. Defenders watch for unusual process creation, script execution, child process chains and blocked application control events that indicate unauthorised code launch.
What Execution Means in ATT&CK Terms
Execution is the point where an adversary turns access into action. It covers the techniques used to run code, launch scripts, invoke interpreters or start malicious binaries on a target, often as the step that makes later persistence, discovery, credential access or lateral movement possible. The important distinction is that ATT&CK treats execution as observable adversary behaviour, not just a malware file sitting on disk.
That matters because execution can happen through many normal-seeming launch paths. A document macro, a command shell, a scheduled task, a WMI event subscription or another built-in execution mechanism may all be abused to make attacker-controlled code run in the host context that was already available.
For defenders, the tactic is useful because it helps you organise telemetry around process creation, script hosts, parent-child process chains and application control outcomes. The question is not only whether code ran, but whether the launch path, signer, user context and execution timing fit the environment’s expected pattern.
How Adversaries Turn Access Into Code Execution
Execution techniques usually sit close to the beginning of an intrusion lifecycle. After initial access, the adversary wants a reliable way to start payloads, load modules, or invoke tooling without relying on a single brittle method. That is why execution often combines with masquerading, living-off-the-land binaries, scheduled job abuse or script interpreters that already exist in the environment.
ATT&CK’s value is that it breaks this behaviour into technique-level patterns you can map to telemetry and detections. A suspicious PowerShell launch, a command shell started by an office process, or a scheduled task that unexpectedly spawns a payload all point to execution activity even if the payload itself has not yet been identified.
Many execution paths are chosen because they blend into legitimate administration. Others are chosen because they evade application controls or reduce the need to drop an obvious executable. That is why execution analysis often overlaps with process ancestry, script block logging, allowlisting and controls that restrict which binaries may run.
For a practical ATT&CK reference point, the MITRE ATT&CK Enterprise Matrix is the authoritative place to connect the tactic to specific enterprise techniques and their related detections.
What Good Detection Looks Like for Execution
Good execution detection starts with baselining ordinary launch behaviour. You want to know which parent processes normally spawn shells, which scripts are approved, which automation accounts run scheduled jobs, and which hosts should never execute user-generated content. Without that baseline, execution alerts tend to be noisy or too generic to action.
The strongest signals usually come from combinations rather than a single event. A rare child process, a script launched from a suspicious path, a binary executed from a user-writable directory, or blocked application control events all become more meaningful when tied to host role, user identity and expected admin activity. That is also where command-line parameters and process lineage matter, because the adversary often hides in the way something was launched rather than in the filename alone.
Detection engineering is the difference between seeing one strange process and building repeatable coverage for the tactic. A practical mapping process is easier when you work from a structured detection library such as MITRE D3FEND, because it helps connect execution behaviour to concrete defensive countermeasures like process lineage analysis, script execution analysis and executable denylisting.
Risk and Threat Considerations
Execution is high-risk because it is where intrusion becomes active compromise. If attackers can reliably launch code, they can stage payloads, establish persistence, disable tooling, and pivot to later techniques that deepen their control of the environment.
Failure mechanism: Weak execution controls, permissive scripting, overtrusted admin tooling, or poor application control allow attacker-controlled code to run in a legitimate user or service context. That can turn a single foothold into a working intrusion path even when the original access method was limited.
Impact: Once code execution is established, defenders lose containment leverage quickly. The attacker can change system state, deploy follow-on tooling, manipulate logs, harvest data, and create the conditions for lateral movement or ransomware staging.
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 CIS Controls v8 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 tactics often use shells and scripts to run attacker code. |
| T1204 — User Execution | Malicious documents and user-triggered launch paths commonly enable execution. | |
| T1053 — Scheduled Task/Job | Scheduled tasks are a common execution mechanism for running payloads later. | |
| Recommendation — Map suspicious shell and script activity to T1059 and alert on unusual parent-child process chains. Track user-triggered launches from documents and shorten the path from click to code run. Hunt for abnormal task creation or modification that starts payloads on a timer. | ||
| CIS Controls v8 | CIS-10 — Malware Defenses | Execution abuse is often detected and contained through malware and script controls. |
| Recommendation — Apply malware defenses to block or contain unapproved code execution paths. | ||
| NIST SP 800-53 Rev 5 | SI-3 — Malicious Code Protection | Execution control depends on blocking or limiting malicious code launch on hosts. |
| Recommendation — Enforce malicious code protection to prevent or contain unauthorized execution. | ||
Practitioner Guidance
What to verify: Confirm which execution paths are actually allowed in each environment, then compare them with observed parent-child process chains, script hosts and scheduled job behaviour. Treat unexpected launch paths as a control-validation problem, not just an alert triage issue.
What good looks like: Execution that is routine should be explainable by host role, user role and change record. Execution that is not routine should either be blocked or produce enough telemetry to show exactly what ran, under what context, and from which parent process.
Common mistake: Teams often focus on the payload and ignore the launcher. In ATT&CK terms, that loses the earlier, more actionable signal, especially when the attacker uses built-in tools or script interpreters instead of dropping a visible binary.
Practitioner takeaway: The real control objective is not to eliminate every execution path, but to make unexpected code launch both difficult and unmistakable when it happens.