ATT&CK for ICS Execution Tactic Guide: Detecting and Containing Execution in OT

In an industrial network, execution does not only mean a malicious binary on a Windows host: it also means a controller running logic, an operating mode or a task that nobody approved. MITRE ATT&CK for ICS defines the Execution tactic (TA0104) as the adversary "trying to run code or manipulate system functions, parameters, and data in an unauthorized way", and its techniques span engineering workstations, HMIs, SCADA servers and the controllers themselves. This hub covers all 9 techniques and 6 sub-techniques under the tactic in ATT&CK v20, how real intrusions chained them, which ones defenders should prioritise and what telemetry and controls catch them. It is written for OT security engineers, control system owners and SOC teams that monitor OT. For the structure of the matrix itself, see the MITRE ATT&CK for ICS Guide.

Key takeaways

• Execution in OT has two layers. Host-level techniques (scripting, GUI, user execution) run on Windows and Linux systems inside the control network; controller-level techniques (Modify Controller Tasking, Change Operating Mode, Execution through API, Native API) make field devices run attacker logic.
• Scripting dominates the procedure data. Of the 41 procedure examples recorded under the tactic in the v20 dataset, 21 sit under Command and Scripting Interpreter (T1701) and its sub-techniques, with PowerShell (T1701.001) the single most used entry at 7.
• Controller execution uses legitimate engineering functions. Stuxnet, Triton, PLC-Blaster and INCONTROLLER all ran their payloads through the same program, task and mode services that engineers use every day, so detection depends on knowing who is allowed to use them.
• Authorisation and allowlisting carry the mitigation load. Execution Prevention (M0938) is mapped to 10 of the 15 technique entries; Authorization Enforcement (M0800) and Human User Authentication (M0804) protect the controller-side techniques.
• The engineering workstation is the pivot. Most controller-level execution is launched from a host that already holds vendor software and project files, so hardening and monitoring that host removes most of the tactic.

What Execution means in an ICS environment

ATT&CK for ICS notes that execution can rely on "unknowing end users or the manipulation of device operating modes", and that commands may be issued from command-line interfaces, APIs, GUIs or other available interfaces. That breadth is the main difference from Enterprise ATT&CK. On an IT network, the question is usually "which process ran?". In OT the defender must also ask "which logic is the controller running, in which mode, and who changed it?".

Execution rarely stands alone. The tactic description says these techniques are often paired with Discovery, Collection, impact operations and Inhibit Response Function. In practice the adversary needs execution twice: once to run tooling on a Windows or Linux host in the control network, and again to make a controller or safety system run something it should not.

How adversaries chain Execution

The procedure examples in the v20 ICS dataset show three recurring patterns. Counts below were computed from the official ATT&CK v20 ICS STIX data by counting non-revoked "uses" relationships from groups, software and campaigns to each technique in the tactic: 41 procedure examples across 10 software entries, 4 groups and 5 campaigns.

• Scripted operations on SCADA hosts: during the 2016 Ukraine Electric Power Attack, Sandworm Team used VBS and batch scripts as wrappers for PowerShell. In the 2022 Ukraine Electric Power Attack the group used a Visual Basic script to run a batch file that executed a MicroSCADA command, after mapping an ISO image to a SCADA server virtual machine through existing hypervisor access (T0895 Autorun Image). In the 2025 Poland Wiper Attacks the adversaries ran PowerShell on an HMI to enable administrative shares and add a firewall rule, and logged into RTUs over SSH as root to run Unix shell commands.
• Hands-on HMI operation: in the 2015 Ukraine Electric Power Attack, Sandworm Team used HMI GUIs in the SCADA environment to open breakers (T0823). No malware is needed once an operator console is reachable.
• Controller logic execution: Stuxnet infected OB1 so its code ran at the start of each cycle; PLC-Blaster stored its code in a new organisation block that the PLC detected and executed; Triton added its shellcode to the Tricon program table so firmware executed it once each cycle (all T0821). Triton also used the TriStation protocol to halt or run programs (T0858) and to trigger program download and change APIs (T0871). INCONTROLLER can change the operating mode of Omron PLCs over HTTP.

The joint DOE, CISA, NSA and FBI advisory AA22-103A on the toolset ATT&CK tracks as INCONTROLLER describes the same pattern: the Omron tool could change operating modes and modify controller tasking, and could load a custom agent that executed code over HTTP and HTTPS. The common step is a host inside the control network with reach to controller management protocols. See the ICS Malware History Guide for the families named here, and the Sandworm Threat Actor Profile for the group behind the Ukrainian attacks.

All Execution techniques in ATT&CK for ICS v20

The table lists every current technique and sub-technique under TA0104, with the number of procedure examples in the v20 dataset and the mitigations ATT&CK maps to it.

ATT&CK v20 deprecated the older ICS techniques Command-Line Interface (T0807) and Scripting (T0853); coverage maps and detection rule tags that still use those IDs should move to T1701 and its sub-techniques. Change Operating Mode is also listed under Evasion, and Hooking under Privilege Escalation.

Which techniques matter most for defenders

• Change Operating Mode (T0858): the gate to most controller-side abuse. ATT&CK notes that Program mode must be enabled before changes can be made to a device's program, and that modes can be selected by a physical key switch or through the controller API. If the key switch is in Run and the API cannot override it, many follow-on techniques fail. It carries the widest mitigation mapping in the tactic (7 mitigations).
• Modify Controller Tasking (T0821): the technique behind the most consequential ICS malware. Task changes alter when and how often logic runs, so they can sit unnoticed alongside legitimate logic. Code Signing (M0945) and Audit (M0947) apply where the platform supports them.
• Command and Scripting Interpreter (T1701): the most frequent technique and the easiest to observe, because the same Windows and Linux telemetry used in IT applies. It is also where Execution Prevention (M0938) through application allowlisting is most practical on fixed-function OT hosts.
• Execution through API (T0871): abuse of the vendor or protocol API that engineering software uses. ATT&CK records CyberAv3ngers using existing PLC management protocols through the manufacturer's engineering tools. The defence is restricting which hosts and identities may call write and control services.
• Graphical User Interface (T0823): ATT&CK maps only M0816, "Mitigation Limited or Not Effective". An HMI is meant to be operated, so the controls move upstream: who can reach the console remotely, with which account, and whether sessions are recorded.

Detection priorities

Every technique in the tactic has an ATT&CK v20 detection strategy. The strategies split cleanly between host telemetry and OT network and device telemetry, and a site needs both.

The practical rule is that controller-level execution is detected on the wire and in the controller, not on the host. Passive OT network monitoring that decodes the vendor protocols (S7comm, EtherNet/IP CIP, Modbus, TriStation, OPC UA) is what sees a mode change or task change. See the OT Network Security Monitoring Guide. On the host side, PowerShell script block logging (Event ID 4104) and process creation logging with command lines are inexpensive and high value on HMIs and SCADA servers, which run a small and stable set of programs.

Mitigation priorities across the tactic

Counting how often each mitigation is mapped to the 15 technique entries in the tactic gives a clear order of work.

The AA22-103A advisory adds concrete host controls for engineering workstations: Device Guard, Credential Guard and Hypervisor Code Integrity, EDR on the OT management subnets, monitoring for unusual driver loading, and installing applications only when necessary. The Engineering Workstation Security Guide covers that host in depth.

Where identity fits

Every controller-level technique in the tactic depends on an identity being allowed to call a privileged engineering function. In many plants that identity is not a person: it is a shared engineering account, a project file with an embedded controller password, a service account used by a historian or OPC UA client, or a vendor's remote support login. Three identity controls cut across the tactic:

• Named engineering access: individual accounts in the engineering software and on the workstation, so that a program or mode change can be tied to a person and a change record.
• Machine client allowlists: OPC UA application authentication with explicit trust lists (recommended in AA22-103A) and protocol allowlists so only known client applications can invoke write and method services.
• Controlled remote access: remote GUI sessions through a monitored jump host with phishing-resistant MFA, not direct RDP or VNC to an HMI.

See the OT and ICS Identity and Access Guide for the wider programme.

How to implement coverage

1. Inventory execution paths: list every host that can talk to controllers with engineering protocols, the vendor software installed, and which interpreters (PowerShell, cmd, Python, Windows Script Host) each host actually needs.
2. Set physical and logical mode controls: put key switches in Run where the platform supports it, record the expected position per controller, and turn on controller access protection (passwords or role-based access) for program and mode services. Test on one cell during a planned window.
3. Baseline logic and tasks: take a golden copy of each controller's program, task configuration and firmware version, store it offline, and schedule comparisons. This is your detection for T0821 and your recovery point. See the OT Backup, Recovery and Golden Image Guide.
4. Deploy allowlisting in audit mode first: run application control in audit mode on HMIs and engineering workstations for at least one full operating cycle, including maintenance tasks, then enforce on one site or line before wider rollout. Keep a documented break-glass procedure to switch a host back to audit mode if an operator function is blocked.
5. Turn on host logging: process creation with command line, PowerShell module and script block logging, and auditd execve on Linux SCADA components, forwarded off the host.
6. Add protocol-aware monitoring: alert on mode changes, program downloads, task changes and API write calls from any source not on the engineering allowlist.
7. Exercise it: during a maintenance window, perform an approved mode change and logic edit and confirm the alerts fire and are triaged correctly.

Small sites versus large estates: a single plant with one engineering workstation can get most of the benefit from key switch discipline, controller passwords, allowlisting on that workstation and a weekly logic comparison. Multi-site operators should centralise protocol monitoring and golden copies, and standardise the allowed engineering hosts per site so alerts are comparable.

Detection and measurement

• Controller mode coverage: percentage of safety and critical controllers whose operating mode is known, monitored and in the expected position.
• Logic baseline age: percentage of controllers with a verified golden copy less than 90 days old, and the time since the last automated comparison.
• Allowlisting enforcement: percentage of HMIs, SCADA servers and engineering workstations with application control in enforce mode.
• Unapproved engineering actions: count of program, task or mode change events per month without a matching change record (target: zero, each one investigated).
• Script telemetry coverage: percentage of OT Windows hosts sending PowerShell Event ID 4104 and process creation events to central logging.

Common failure patterns

• Key switches left in Program or Remote: convenient for engineers, but it hands Change Operating Mode to anyone who reaches the controller on the network.
• Allowlisting deployed on IT but not on OT hosts: HMIs and engineering workstations are often excluded because of vendor support concerns, which leaves the hosts with the most dangerous software unprotected. Agree a tested exclusion list with the vendor instead.
• Monitoring only the host layer: EDR on the workstation does not see a task modification sent over the vendor protocol from a compromised laptop. Protocol-aware network monitoring is needed for controller execution.
• No golden copy of logic: without an offline baseline there is nothing to compare running logic against, and no clean state to restore after an incident.
• Shared engineering credentials: a single controller password known to every integrator makes Authorization Enforcement meaningless and leaves no attribution. See the OT Third-Party and Integrator Access Guide.

Framework mapping

NIST SP 800-82 Rev. 3, the Guide to Operational Technology Security, provides the OT overlay for applying these SP 800-53 controls in industrial environments. For IEC 62443 zone and system requirements, see the IEC 62443-3-3 and 4-2 Security Levels Guide.

Practitioner checklist

• Map every host that can send engineering commands to controllers and remove that ability from any host that does not need it.
• Record and monitor the expected operating mode and key switch position of each critical and safety controller.
• Enable controller access protection for program, task and mode services where the platform supports it.
• Hold offline golden copies of logic, tasks and firmware and compare running state on a schedule.
• Enforce application allowlisting on HMIs, SCADA servers and engineering workstations after an audit-mode period.
• Turn on PowerShell script block logging, process creation with command lines and Linux execve auditing on OT hosts.
• Deploy protocol-aware monitoring that alerts on mode changes, downloads and API writes from unapproved sources.
• Replace shared engineering logins with named accounts and route remote HMI access through a monitored jump host with MFA.
• Remap any detection or coverage content still tagged T0807 or T0853 to T1701.

Standards and references

• MITRE ATT&CK: Execution, Tactic TA0104 (ICS)
• MITRE ATT&CK: Change Operating Mode (T0858)
• MITRE ATT&CK: Modify Controller Tasking (T0821)
• MITRE ATT&CK: Command and Scripting Interpreter (T1701, ICS)
• CISA, DOE, NSA and FBI: APT Cyber Tools Targeting ICS/SCADA Devices (AA22-103A)
• NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls
• Microsoft Learn: about_Logging_Windows (PowerShell script block logging)

Related NHI Mgmt Group resources: MITRE ATT&CK for ICS Guide · Engineering Workstation Security Guide · OT Network Security Monitoring Guide · ICS Malware History Guide · OT Incident Response Guide