TA0104: Execution
The adversary is trying to run code or manipulate system functions, parameters, and data in an unauthorized way.
Execution consists of techniques that result in adversary-controlled code running on a local or remote system, device, or other asset. This execution may also rely on unknowing end users or the manipulation of device operating modes to run. Adversaries may infect remote targets with programmed executables or malicious project files that operate according to specified behavior and may alter expected device behavior in subtle ways. Commands for execution may also be issued from command-line interfaces, APIs, GUIs, or other available interfaces. Techniques that run malicious code may also be paired with techniques from other tactics, particularly to aid network Discovery and Collection, impact operations, and inhibit response functions.
Analyst context for executives and security teams
Execution in ICS ATT&CK is the point where an adversary causes code to run or manipulates system functions, parameters, or data without authorization. For security leaders, this matters because execution is often where an intrusion can begin to affect operational technology behavior, not just IT systems. The business question is whether the organization can see, control, and investigate unauthorized code, commands, project files, API actions, GUI-driven changes, or operating-mode manipulation across critical industrial assets.
Executive priority
Treat this tactic as a resilience and governance priority for industrial environments: leadership should ask whether OT/ICS teams can prove who is allowed to execute commands or change device behavior, what evidence is retained, and how quickly unauthorized execution would be escalated to operations, engineering, SOC, and incident response. Because MITRE provides no specific detection guidance or platform scope for this tactic object, prioritization should be driven by local asset criticality, safety/availability consequences, and the systems where unauthorized execution would create the greatest operational risk.
Technical view
For SOC, detection engineering, and IR teams, validate coverage around adversary-controlled code execution and unauthorized manipulation of system functions, parameters, data, project files, commands, APIs, GUIs, and device operating modes. The official ATT&CK object notes that execution may support Discovery, Collection, impact operations, and inhibition of response functions, so investigations should not treat execution alerts in isolation. Confirm whether telemetry can connect an execution event to preceding access and subsequent changes in device or process behavior. Platforms are not specified in the supplied object, so teams must map this tactic to their own ICS asset inventory and control interfaces.
Likely telemetry
- Command-line interface activity where available
- API activity and administrative/control interface logs
- GUI-driven operator or engineering workstation actions where logged
- Project file transfer, load, or execution evidence
- Device operating mode change records
Detection direction
- Validate that authorized engineering, maintenance, and operations activity can be distinguished from unauthorized execution or manipulation.
- Correlate execution-like activity with asset criticality, user identity, source system, timing, and approved change windows.
- Look for follow-on context related to Discovery, Collection, impact activity, or inhibited response functions, as noted in the tactic description.
- Tune carefully for legitimate operations activity; false positives are likely where routine engineering changes, operator actions, or maintenance scripts are not well documented.
- Identify blind spots where command, API, GUI, project file, or operating-mode activity is not logged or not forwarded to the SOC.
Mitigation priorities
- Start with asset and interface inventory: identify where code, commands, project files, parameters, data, and operating modes can be changed.
- Enforce least privilege and approval paths for users and systems that can execute code or manipulate ICS functions.
- Strengthen change control so authorized execution and device behavior changes are documented and auditable.
- Prioritize logging and monitoring on high-consequence assets and remote/control interfaces first.
- Ensure incident response playbooks include coordination between SOC, OT engineering, operations leadership, and safety stakeholders when unauthorized execution is suspected.
Analyst notes and limits
This is a tactic-level ICS ATT&CK object, not a specific technique. It provides strategic context for adversary execution behavior but does not include platform details, procedure examples, mitigations, detections, or relationships in the supplied data. The most useful analysis comes from mapping this tactic to local ICS assets, control interfaces, engineering workflows, and approved change processes.
The supplied object has no official detection section, no platforms, no relationships, no aliases, and no linked techniques or groups in the provided context. This take therefore avoids claims about active exploitation, attribution, guaranteed detection, or specific technologies. Local telemetry, architecture, and operational process evidence are required to assess real coverage.
Execution
The adversary is trying to run code or manipulate system functions, parameters, and data in an unauthorized way.
Execution consists of techniques that result in adversary-controlled code running on a local or remote system, device, or other asset. This execution may also rely on unknowing end users or the manipulation of device operating modes to run. Adversaries may infect remote targets with programmed executables or malicious project files that operate according to specified behavior and may alter expected device behavior in subtle ways. Commands for execution may also be issued from command-line interfaces, APIs, GUIs, or other available interfaces. Techniques that run malicious code may also be paired with techniques from other tactics, particularly to aid network Discovery and Collection, impact operations, and inhibit response functions.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 7081a05e9653… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack TA0104Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.