During the2015 Ukraine Electric Power Attack,Sandworm Team issued unauthorized commands to substation breaks after gaining control of operator workstations and accessing a distribution management system (DMS) application.^[4]

During the2022 Ukraine Electric Power Attack,Sandworm Team used the MicroSCADA SCIL-API to specify a set of SCADA instructions, including the sending of unauthorized commands to substation devices.^[5]

INCONTROLLER can send custom Modbus commands to write register values on Schneider PLCs.^[6]

INCONTROLLER can send write tag values on OPC UA servers.^[6]

Using its protocol payloads,Industroyer sends unauthorized commands to RTUs to change the state of equipment.^[7]

Industroyer2 is capable of sending command messages from the compromised device to target remote stations to open data channels, retrieve the location and values of Information Object Addresses (IOAs), and modify the IO state values through Select Before Operate I/O, Select/Execute, and Invert Default State operations.^[8][9]

In theMaroochy Water Breach, the adversary used a dedicated analog two-way radio system to send false data and instructions to pumping stations and the central computer.^[10]

In theTriton Safety Instrumented System Attack,TEMP.Veles leveragedTriton to send unauthorized command messages to the Triconex safety controllers.^[11]

Protocols used for control functions should provide authenticity through MAC functions or digital signatures. If not, utilize bump-in-the-wire devices or VPNs to enforce communication authenticity between devices that are not capable of supporting this (e.g., legacy controllers, RTUs).

Perform inline allowlisting of automation protocol commands to prevent devices from sending unauthorized command or reporting messages. Allow/denylist techniques need to be designed with sufficient accuracy to prevent the unintended blocking of valid messages.

Use host-based allowlists to prevent devices from accepting connections from unauthorized systems. For example, allowlists can be used to ensure devices can only connect with master stations or known management/engineering workstations.^[12]

Segment operational assets and their management devices based on their functional role within the process. Enabling more strict isolation to more critical control and operational information within the control environment.^{[13][14][12][15]}

Devices should authenticate all messages between master and outstation assets.

Devices and programs that receive command messages from remote systems (e.g., control servers) should verify those commands before taking any actions on them.

Monitor industrial process history data for events that correspond with command message functions, such as setpoint modification or changes to system status for key devices. This will not directly detect the technique’s execution, but instead may provide additional evidence that the technique has been used and may complement other detections.
Monitor for anomalous or unexpected commands that may result in changes to the process operation (e.g., discrete write, logic and device configuration, mode changes) observable via asset application logs.
Monitor for new or unexpected connections to controllers, which could indicate an Unauthorized Command Message being sent viaRogue Master.
Monitor for anomalous or unexpected commands that may result in changes to the process operation (e.g., discrete write, logic and device configuration, mode changes) observable via asset application logs.
Monitor for unexpected ICS protocol command functions to controllers from existing master devices (including from new processes) or from new devices. The latter is like detection forRogue Master but requires ICS function level insight to determine if an unauthorized device is issuing commands (e.g., a historian).

Monitoring for unexpected or problematic values below the function level will provide better insights into potentially malicious activity but at the cost of additional false positives depending on the underlying operational process.