System Binary Proxy Execution (T0894) is an adversary using trusted, often signed, binaries already on a host, including the vendor's own SCADA utilities, to run their commands so that allowlisting and signature checks see nothing unusual. In OT the most dangerous trusted binaries are not Windows utilities but the application tools that can already send commands to substations and controllers. MITRE ATT&CK for ICS lists T0894 under the Evasion tactic (TA0103) for Embedded, Linux and Windows platforms, with one mitigation, M0938 Execution Prevention. This guide is for OT security engineers, control system engineers and OT SOC analysts. It covers the 2022 Ukraine case, ATT&CK's v20 analytics, and how to restrict and monitor trusted binaries without blocking legitimate engineering work. For the Windows and Linux mechanics in IT environments, see the T1218 System Binary Proxy Execution Defensive Guide.
Key takeaways
- Vendor tools are trusted binaries too. ATT&CK's ICS entry extends the technique to application binaries supplied by device vendors that can send commands to devices, not only to signed operating system files.
- Sandworm used a native SCADA utility. In the 2022 Ukraine Electric Power Attack (C0034), Sandworm ran MicroSCADA's own scilc.exe to send a prepared list of SCADA instructions to remote substations.
- Allowlisting alone does not stop it. The binary is approved; what is abnormal is who launched it, from what parent, with which arguments and input file.
- Remove capabilities you do not use. Mandiant's guidance after the attack was to update MicroSCADA, require authentication, and where feasible prevent external SCIL-API programs such as scilc.exe from running.
- Ask your vendors the same question. Mandiant advised asking OEMs of installed SCADA software for similar code execution paths in their products and their mitigations.
What T0894 covers in OT
ATT&CK for ICS describes two kinds of proxy binary. The first is familiar from IT: Microsoft-signed binaries native to Windows, and trusted Linux binaries, that can run other files or commands. The second is specific to OT: application binaries installed by the device or system vendor for configuration, management and operation, which can send commands to local or networked devices through defined APIs or application languages such as MicroSCADA's SCIL. Operators and monitoring tools are used to seeing these binaries, and there may be no alternative to them. ATT&CK gives the example of a SCADA server binary that can already send IEC 104 command messages to substation devices.
| Proxy binary type | Examples ATT&CK names | Why it evades |
|---|---|---|
| Signed Windows system binaries | Microsoft-signed files native to Windows, catalogued by the LOLBAS project; ATT&CK's analytic lists certutil.exe, regsvr32.exe, mshta.exe and rundll32.exe | Pass signature validation and are present on most hosts |
| Trusted Linux binaries | split, and in ATT&CK's analytic bash, python, perl, awk and dd | Normal administrative tools on Linux SCADA and historian hosts |
| Vendor application binaries | MicroSCADA scilc.exe executing SCIL programs | Built to send commands to devices, so the traffic they generate is legitimate in form |
The command the binary sends is a separate step: ATT&CK v20 maps the use of the device interface to T0871 Execution through API. T0894 is the evasion that hides who issued it.
The case: 2022 Ukraine Electric Power Attack
Mandiant's report on the incident describes Sandworm reaching the hypervisor that hosted a MicroSCADA management virtual machine for a substation environment. On 10 October 2022 an ISO image mounted on that machine ran a VBS launcher, which ran a batch file that likely called MicroSCADA's native scilc.exe utility with a SCIL program file supplied by the attacker. Mandiant assessed that the SCIL commands were likely meant to open circuit breakers, relayed by the MicroSCADA server to RTUs over IEC 60870-5-104 or 60870-5-101, and the event coincided with an unplanned power outage. Mandiant noted the victim ran an end-of-life MicroSCADA version that allowed default access to the SCIL-API, which Mandiant says has been disabled by default since MicroSCADA 9.4 in 2014. How the image came to run is covered in the MITRE ATT&CK for ICS T0847 Replication Through Removable Media guide; Mandiant mapped that step to T0847, and ATT&CK v20 also maps it to T0895 Autorun Image.
The lesson is that no custom OT malware was needed. The attacker used a feature the SCADA system shipped with, from a host that was entitled to talk to the substations. See the Sandworm Threat Actor Profile.
Detection: ATT&CK v20 analytics and vendor guidance
ATT&CK v20's detection strategy for T0894 applies an OT operational fidelity gate: alert only when execution breaks an approved signer, hash, path, parent process or tool allowlist, or comes from an unauthorised user or tool, and is tied to an OT asset or follow-on OT action. Suppress vendor-signed software, approved engineering utilities, diagnostics, patching, backup and documented maintenance.
| Platform | What the analytic looks for | Data needed |
|---|---|---|
| Windows | A trusted signed system binary on an ICS host run with arguments inconsistent with its administrative purpose, such as payload decoding, remote content execution or script invocation | Process creation with command line (Sysmon Event ID 1), scoped to the ICS workstation inventory |
| Linux | System binaries on ICS Linux assets run with arguments that pipe or decode external content, from an ICS service account UID | Linux audit execve and socket records |
| Embedded | ICS protocol messages using built-in device utilities or vendor diagnostic tools to run payloads, from sources not on the approved engineering workstation list | OT network monitoring with protocol decoding |
For vendor binaries, Mandiant's monitoring recommendations after the Ukraine attack apply to any SCADA platform:
- Command-line execution of native SCADA binaries that can run programs or commands, for MicroSCADA scilc.exe and others; Mandiant published a hunting rule for scilc.exe launched with its program execution option.
- Files transferred onto SCADA hosts, and newly created files containing SCADA application or scripting language references.
- Network and process telemetry to and from the SCADA host, correlated together.
- Unauthorised changes to SCADA system configuration and data.
The most useful signal is parent and context. A vendor utility launched by the operator interface during a logged task is normal; the same utility launched by a script interpreter or a batch file from removable media is not. See the HMI and SCADA Server Hardening Guide.
Prevention: M0938 Execution Prevention in practice
ATT&CK's mitigation is to disallow applications and programs not required for normal system functions, including specific command-line arguments that allow proxy execution. In OT that means four things:
- Application allowlisting by path, signer and parent: allow vendor utilities to run only from their install path and only from expected parents, and block script hosts that the SCADA application does not need. See the Application Allowlisting Guide and, for Linux hosts, the fapolicyd and Linux Application Allowlisting Guide.
- Disable unused vendor interfaces: Mandiant's MicroSCADA hardening advice was to update to supported versions, require authentication with least privilege permissions, and where feasible run the base system in read-only mode with no external SCIL-API programs allowed, following the vendor's security deployment guideline.
- Remove unneeded Windows proxy binaries from reach: block LOLBAS binaries the SCADA software does not use, after testing with the vendor.
- Segment the hosts that can command field devices: keep SCADA management hosts strongly separated from IT, as Mandiant recommends, and keep their hypervisor management interfaces out of reach of IT. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.
Where identity fits
A trusted binary runs with the rights of the account that launched it. SCADA service accounts and shared operator logins that can run vendor command utilities give an attacker the same reach. Restrict which accounts may launch command-capable vendor tools, require authentication in the SCADA application itself, and protect hypervisor administrator credentials as tightly as the SCADA host, since Sandworm reached the SCADA machine through its hypervisor. See the OT and ICS Identity and Access Guide.
How to implement
- Inventory command-capable binaries. With each SCADA and engineering vendor, list the utilities that can execute programs or send commands to devices, and their normal parents and users.
- Collect process telemetry. Turn on process creation logging with command lines on SCADA, HMI and engineering hosts, and Linux audit rules on Linux hosts.
- Baseline and alert. Record normal launches over a full operational cycle, then alert on vendor utilities launched by script hosts, unusual parents or unapproved accounts.
- Allowlist in audit mode first. Run application control in audit mode and review blocks with operations before enforcing.
- Harden vendor interfaces. Apply vendor guidance to disable unused APIs and require authentication, on a test system before production.
- Keep a rollback. Record each policy change and keep a tested way to revert allowlisting rules quickly if a legitimate operator function is blocked.
Decision guidance
- Supported SCADA versions: use the vendor's own hardening options to disable external program interfaces; this removes the proxy path rather than watching it.
- End-of-life systems: rely on allowlisting, strict segmentation and process monitoring while planning upgrade, since vendor hardening may not exist.
- Small sites: process logging on a handful of SCADA hosts and a short list of alerting rules for vendor utilities is achievable without an OT SOC.
- Large sites: combine host analytics with protocol-aware monitoring so a command sent by an unexpected process can be tied to traffic to RTUs and controllers. See the OT Security Operations Centre Guide.
Responding to suspected proxy execution
If a command-capable vendor utility ran unexpectedly, start with operations: check the process state and whether breakers, setpoints or modes changed. Preserve the process tree, command line, input files and network captures before cleaning anything. Contain by blocking the host's path to field devices at the conduit, in coordination with operators, rather than shutting down a supervisory system they rely on. Then trace how the launcher arrived on the host. See the OT Incident Response Guide.
Detection and measurement
- Inventory coverage: share of SCADA platforms with command-capable binaries documented with the vendor.
- Telemetry coverage: share of SCADA, HMI and engineering hosts sending process creation with command lines.
- Enforcement coverage: share of those hosts with application control in enforce mode.
- Interface hardening: number of SCADA systems with unused external program interfaces disabled.
- Alert outcomes: unexpected vendor utility launches investigated and the share matched to change records.
Framework mapping
| Framework | Reference | How it applies |
|---|---|---|
| MITRE ATT&CK for ICS v20 | T0894; M0938; C0034; related T0871, T0895 | Technique, mitigation, campaign and related steps |
| MITRE ATT&CK Enterprise | T1218 System Binary Proxy Execution | IT equivalent technique |
| MITRE D3FEND | D3-EAL Executable Allowlisting, D3-PSA Process Spawn Analysis | Allowlisting and parent-child analysis |
| NIST SP 800-53 Rev. 5 | CM-7 Least Functionality, AC-6 Least Privilege, SI-4 System Monitoring, AU-2 Event Logging | Remove unneeded functions, restrict and monitor execution |
| NIST CSF 2.0 | PR.PS-05, DE.CM-09 | Prevent unauthorised execution, monitor platforms |
Common failure patterns
- Allowlisting by name or signer only: the vendor utility is approved, so its misuse is never blocked or flagged.
- End-of-life SCADA with open interfaces: the Ukraine victim's MicroSCADA version allowed default SCIL-API access.
- No command-line logging on SCADA hosts: the process launch happens but nobody can see its arguments or parent.
- Hypervisor management reachable from IT: the path Sandworm used to reach the SCADA machine.
- Vendor not asked: teams do not know which of their own SCADA binaries can execute arbitrary programs.
Practitioner checklist
- Ask each SCADA vendor which binaries can execute programs or send device commands.
- Log process creation with command lines on all SCADA, HMI and engineering hosts.
- Alert on vendor command utilities launched by script hosts or unusual parents.
- Enforce allowlisting by path, signer and parent after an audit-mode period.
- Disable unused external program interfaces and require authentication in SCADA software.
- Upgrade or isolate end-of-life SCADA versions.
- Separate hypervisor management for OT virtual machines from IT.
- Monitor files arriving on SCADA hosts and configuration changes.
Standards and references
- MITRE ATT&CK for ICS: System Binary Proxy Execution (T0894)
- MITRE ATT&CK: 2022 Ukraine Electric Power Attack (C0034)
- Mandiant: Sandworm Disrupts Power in Ukraine Using a Novel Attack Against Operational Technology
- LOLBAS Project: Living Off The Land Binaries, Scripts and Libraries
- NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
- MITRE D3FEND: Executable Allowlisting
Related NHI Mgmt Group resources: MITRE ATT&CK for ICS Guide · T1218 System Binary Proxy Execution Defensive Guide · Living off the Land Guide · HMI and SCADA Server Hardening Guide · Sandworm Threat Actor Profile