Command and Scripting Interpreter (T1701) in ATT&CK for ICS is an adversary using shells and scripting engines on HMIs, SCADA servers, engineering workstations, gateways and controllers to run commands that reach the industrial process. MITRE added T1701 to the ICS matrix in v20 under Execution (TA0104), with six sub-techniques: PowerShell (T1701.001), Windows Command Shell (T1701.002), Unix Shell (T1701.003), Visual Basic (T1701.004), Python (T1701.005) and JavaScript (T1701.006). The older ICS techniques Command-Line Interface (T0807) and Scripting (T0853) are now shown as deprecated. MITRE notes that many controllers also have command-line interfaces for management. The general detection and hardening of interpreters is covered in the T1059 Command and Scripting Interpreter Defensive Guide; this page covers what is different in OT: the procedure examples, the ICS-specific v20 analytics, and how to restrict interpreters on assets where vendor software and engineers depend on them. It is for OT security engineers, control engineers and OT SOC analysts.
Key takeaways
- In OT, the interpreter is often the last step before the process. Sandworm's 2022 attack ran a VBScript and batch file that launched a native SCADA utility to send commands to substations.
- Vendor software makes "normal" hard to define. ATT&CK's v20 analytic looks for shells spawned by ICS vendor applications where that parent-child pair is not documented behaviour.
- Embedded devices have shells too. In the 2025 Poland attacks, ATT&CK records adversaries logging in to RTUs over SSH as root and deleting files with Linux commands.
- Allowlist, do not just block. ATT&CK's sub-technique mitigations repeatedly say to preserve validated vendor and engineering dependencies and prefer explicit allowlists over broad blocking.
- Purpose-built ICS malware still starts from a command line. FrostyGoop is a Windows command-line tool that speaks Modbus; Triton's tool took the target controller's IP address as its one argument.
What T1701 covers in OT
| Sub-technique | Where it appears in OT | ATT&CK v20 procedure example |
|---|---|---|
| T1701.001 PowerShell | Windows HMIs, historians, engineering workstations, jump hosts | 2025 Poland Wiper Attacks (C0063): PowerShell on an HMI to enable administrative shares, add a firewall rule for port 445 and run reconnaissance; TEMP.Veles (G0088) used a PowerShell-based tool during the Triton attack (C0030) |
| T1701.002 Windows Command Shell | Batch files used by vendor software and engineers | 2022 Ukraine Electric Power Attack (C0034): a VBScript ran a batch file that executed the MicroSCADA scilc.exe utility; Industroyer (S0604) took its payload DLL name from a command-line parameter |
| T1701.003 Unix Shell | Linux gateways, RTUs, protocol converters, network devices | 2025 Poland Wiper Attacks: root SSH to RTUs and commands that deleted system files, causing device failure |
| T1701.004 Visual Basic | Office macros and VBS on engineering and business-side hosts | 2016 Ukraine Electric Power Attack (C0025): VBS and batch scripts as wrappers for PowerShell |
| T1701.005 Python | Engineering tools, test scripts, vendor utilities | Triton (S1009): a Python framework implementing the TriStation protocol, packaged as a Windows executable |
| T1701.006 JavaScript | Browser-based HMIs, Windows Script Host | ATT&CK lists IT-origin malware only (REvil) |
Related techniques have their own pages: Execution through API (T0871) covers calling vendor libraries and controller APIs, and Remote Services (T0886) covers the SSH, Telnet and RDP sessions that often carry interactive shells. See the MITRE ATT&CK for ICS T0871 Execution through API.
What real cases show
- Sandworm, Ukraine 2022: Mandiant describes a mounted ISO image whose autorun launched wscript.exe running lun.vbs, which ran n.bat, which ran the MicroSCADA utility scilc.exe with the -do option against a SCIL file. Mandiant assesses the commands probably opened circuit breakers, coinciding with missile strikes on 10 October 2022. The affected system was an end-of-life MicroSCADA version that allowed default access to the SCIL-API. See the Sandworm Threat Actor Profile.
- FrostyGoop (S1165): ATT&CK records it as compiled for Windows and using a Windows command-line interface, with Modbus functionality based on a public repository. Dragos reports it communicates over Modbus TCP port 502 and was likely used against a Ukrainian district energy company, with heating controllers reachable from the internet. See the FrostyGoop Modbus Malware Guide.
- Triton (C0030): ATT&CK records that TEMP.Veles' tool took a single command-line option, the IP address of the target Triconex safety controller.
- Stuxnet (S0603): ATT&CK records Stuxnet using the SQL Server xp_cmdshell facility to extract and run its code.
Detection: ATT&CK v20 analytics
ATT&CK gives T1701 the detection strategy DET0928, Behavioral Detection of Command and Scripting Abuse in ICS, with per-sub-technique strategies (DET0929 PowerShell, DET0930 Windows Command Shell, DET0931 Unix Shell, DET0932 Visual Basic, DET0933 Python and DET0936 JavaScript). Each analytic includes an operational-fidelity gate: alert only when execution falls outside an approved signer, hash, path, account or workflow baseline.
| Platform | Log source | What ATT&CK looks for |
|---|---|---|
| Windows | Sysmon Event ID 1 (process creation) | cmd.exe or PowerShell spawned by an ICS vendor application where that parent-child pair is not documented, or command lines containing ICS protocol or API keywords outside documented automation |
| Linux | auditd execve records | Interpreters spawned by ICS service processes, or interactive shells from unexpected SSH sources or user IDs |
| Network devices | Device CLI command logs | Interface shutdown, ACL or NAT changes from outside the management baseline, or scripted, regular-interval sessions to field devices |
| Embedded | Device CLI and session logs | Sessions from outside the approved admin range followed by configuration mode, firmware operations, config write or erase, or reload; or protocol commands with machine-regular timing and systematic address iteration |
Mandiant's 2022 report adds concrete OT examples: alert on scilc.exe with -do, on wscript.exe launching batch files from mounted ISO or CD-ROM paths, and on new files referencing SCIL on SCADA hosts. The same pattern applies to any vendor's native command utilities: list them per product and watch who runs them. Correlate host events with network monitoring of OT protocols; see the OT Network Security Monitoring Guide.
Prevention: ATT&CK mitigations in practice
| Mitigation | ATT&CK guidance for OT | Practical step |
|---|---|---|
| M0938 Execution Prevention | Restrict interpreters, scripts and child processes to approved paths, parents, accounts and workflows; prefer explicit allowlists on production OT systems | Application control in audit mode on HMIs and SCADA servers, then enforce per role |
| M0942 Disable or Remove Feature or Program | Remove features not needed for an asset's function, but not where vendor support or approved automation depends on them | Disable Windows Script Host and macros on HMIs where the vendor confirms they are unused |
| M0948 Application Isolation and Sandboxing | Restrict operating system interactions, especially when the source of a script is unknown | Keep browsing and email off HMIs and engineering hosts |
| M0945 Code Signing (PowerShell) | Require signed PowerShell scripts where feasible, with exceptions for validated vendor automation | Sign site automation scripts and log script block content |
| M0926 Privileged Account Management (PowerShell) | Separate routine operator activity from privileged maintenance | Operators run HMI sessions without shell rights; engineers elevate through a controlled path |
For host hardening detail see the HMI and SCADA Server Hardening Guide and the Engineering Workstation Security Guide. Mandiant's MicroSCADA advice generalises well: keep SCADA software on supported versions, check whether external scripting APIs have been re-enabled, and disable autorun and removable media on SCADA hosts and hypervisors.
Where identity fits
Interpreters run as an account. On OT hosts these are often shared engineering logins, vendor support accounts and service accounts that run polling or historian scripts, and in the Poland attacks the shell on RTUs was root over SSH. Give scripted automation its own service identity with only the rights it needs, remove interactive shell rights from operator accounts, and route vendor shell access through brokered remote access with individual identities. See the OT and ICS Identity and Access Guide.
How to implement
- Baseline per asset role. For HMIs, SCADA servers, historians, engineering workstations and gateways, record which interpreters, scripts and vendor utilities run, under which accounts and parents. Ask vendors for the documented list.
- Collect telemetry. Enable process creation logging (Sysmon or equivalent) on Windows OT hosts and auditd on Linux, plus CLI logging on network devices, with central collection.
- Write ICS rules for vendor-native command utilities and unexpected shell children of vendor processes; run them in monitor mode for a full operating cycle.
- Apply application control in audit mode on a pilot HMI or engineering workstation, review blocks with the vendor, then enforce. Roll back by returning the policy to audit mode.
- Restrict device shells. Limit SSH and Telnet to controllers and gateways to named management hosts and disable unused management services where the vendor supports it.
- Extend to all sites in rings, with change control for each new script or utility added to the baseline.
Decision guidance
- Block or allowlist: on IT-like hosts in the DMZ, blocking unused interpreters is usually safe; on HMIs and engineering workstations use allowlists that keep vendor dependencies, as ATT&CK advises.
- Python on engineering hosts: where engineers need it, allow approved interpreters and packages only, and alert on new interpreters, as ATT&CK's Python mitigations describe.
- Small sites: start with process logging and removing email and browsing from HMIs; application control can follow.
- Large estates: standardise the baseline per vendor platform so rules travel between sites.
Detection and measurement
- Percentage of Windows and Linux OT hosts with process creation logging centrally collected.
- Percentage of HMIs and engineering workstations with application control enforced.
- Number of undocumented interpreter executions per month, and how many were added to the baseline after review.
- Percentage of controllers and gateways whose shell access is limited to named management hosts.
- Time to triage an alert on a vendor-native command utility.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| ATT&CK for ICS | T1701 and T1701.001 to T1701.006; M0938, M0942, M0948, M0945, M0926; DET0928 | Technique, mitigations, detection |
| ATT&CK Enterprise | T1059 Command and Scripting Interpreter | IT-side equivalent |
| NIST SP 800-53 Rev 5 | CM-7 Least Functionality, CM-6 Configuration Settings, SI-4 System Monitoring, SI-7 Software, Firmware, and Information Integrity, AC-2 Account Management | Remove unneeded interpreters, enforce settings, monitor, integrity |
| NIST CSF 2.0 | PR.PS-01, PR.PS-04, DE.CM-09 | Configuration management, logging, monitoring of computing assets |
| NIST SP 800-82 Rev 3 and IEC 62443 | OT overlay and system hardening requirements | See the NIST SP 800-82 OT Security Guide and IEC 62443 Guide |
Common failure patterns
- Only watching PowerShell: the 2022 Ukraine chain used VBScript, a batch file and a vendor utility, none of them PowerShell.
- No process logging on HMIs: OT Windows hosts often have no telemetry, so the execution chain cannot be seen or reconstructed.
- Ignoring vendor-native utilities: legitimate SCADA command tools are living-off-the-land binaries for OT and need their own rules.
- Root SSH on field devices: open shell access to RTUs and gateways let the 2025 Poland attackers destroy devices with ordinary commands.
- Autorun and removable media left on: Mandiant found the 2022 SCADA host permitted CD-ROM autorun.
Practitioner checklist
- Baseline interpreters, scripts and vendor command utilities per OT asset role.
- Collect process creation and auditd logs from OT hosts centrally.
- Alert on shells spawned by ICS vendor processes outside documented behaviour.
- Write rules for each vendor's native command utilities.
- Pilot application control in audit mode, then enforce with vendor agreement.
- Restrict SSH and Telnet on controllers and gateways to named management hosts.
- Remove email, browsing, macros and autorun from HMIs and SCADA servers.
- Run automation scripts under dedicated, least-privilege service accounts.
Standards and references
- MITRE ATT&CK: Command and Scripting Interpreter (T1701), ICS
- MITRE ATT&CK: PowerShell (T1701.001), ICS
- MITRE ATT&CK: Unix Shell (T1701.003), ICS
- NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
- Mandiant: Sandworm Disrupts Power in Ukraine Using a Novel Attack Against Operational Technology
- Dragos: FrostyGoop ICS Malware Targeting Operational Technology
- CERT Polska: Energy Sector Incident Report
Related NHI Mgmt Group resources: T1059 Command and Scripting Interpreter Defensive Guide · MITRE ATT&CK for ICS Guide · Engineering Workstation Security Guide · OT Incident Response Guide