T1691.001: Command Message
Adversaries may block a command message from reaching its intended target to prevent command execution. In OT networks, command messages are sent to provide instructions to control system devices. A blocked command message can inhibit response functions from correcting a disruption or unsafe condition.[1][2]
Analyst context for executives and security teams
Command Message is an ICS sub-technique where an adversary blocks control instructions from reaching OT devices. The business significance is not just lost network traffic: blocked commands can prevent operators or automated systems from correcting a disruption or unsafe condition. For leaders, this makes command-path resilience, out-of-band communications, and OT network control evidence important to operational continuity and safety readiness.
Executive priority
Prioritize this behavior where HMIs, control servers, RTUs, PLCs, IEDs, safety controllers, DCS controllers, PACs, and Field I/O support critical operations. Ask whether the organization can prove that command messages reach intended targets, whether alternate communications exist during failures or integrity attacks, and whether allowlisting/static network configuration are governed as resilience controls rather than only security controls. This is also useful audit and incident-response evidence for demonstrating OT communication dependency management.
Technical view
MITRE does not provide detection text for T1691.001, but the relationship to DET0784 indicates a detection strategy for Block Command Message. SOC and OT defenders should validate visibility across command paths between operator/control systems and field/control devices, especially HMI-to-control-server and control-server/RTU-to-controller paths. Detection engineering should focus on discrepancies between issued operator or control commands and expected device receipt/execution, abnormal communication failures, and network controls that could block forwarding. Treat this as an OT process-integrity and communications-availability problem, not only a packet-drop problem.
Likely telemetry
- OT network traffic captures or metadata for command paths between HMIs, control servers, RTUs, PLCs, IEDs, safety controllers, DCS controllers, PACs, and Field I/O
- Firewall, switch, router, or segmentation-device logs showing allowed, denied, or failed connections by IP address, MAC address, port, and protocol
- HMI operator action logs and control server command/event logs that show commands issued
- Controller, RTU, IED, safety controller, or PAC logs/events showing command receipt, rejection, timeout, or execution state where available
- Protocol-aware OT monitoring evidence for automation protocols referenced in related asset/mitigation context, such as Modbus or DNP3 where used locally
Detection direction
- Validate DET0784-aligned coverage by testing whether monitoring can distinguish a command issued from a command received or executed.
- Correlate HMI/control-server command records with downstream device observations; a command with no corresponding receipt, response, or process change may require investigation.
- Tune for expected maintenance, communications failures, device outages, and network changes to reduce false positives.
- Review blind spots on embedded assets and safety/field devices where endpoint logging may be limited and network telemetry may be the primary evidence.
- Confirm monitoring covers both IT-hosted OT systems, such as HMIs/control servers where applicable, and embedded controller/field-device communication paths.
Mitigation priorities
- Implement and govern Network Allowlists (M0807) for approved device communications using relevant connection attributes such as IP address, MAC address, port, and protocol.
- Maintain Out-of-Band Communications Channels (M0810) so operators have alternative methods during communication failures or data-integrity attacks.
- Use Static Network Configuration (M0814) where feasible to reduce manipulation of dynamic discovery/addressing that can affect message forwarding.
- Document critical command paths and recovery procedures for HMIs, control servers, RTUs, PLCs, IEDs, safety controllers, DCS controllers, PACs, and Field I/O.
- Test mitigations during OT-safe exercises, because local device capability and operational constraints may limit how controls can be applied.
Analyst notes and limits
This object is a sub-technique of T1691 Block Operational Technology Message and replaces revoked technique T0803 Block Command Message. It targets multiple ICS asset types and is related to mitigations for allowlisting, out-of-band communications, and static network configuration. The supplied relationships also connect it to the 2015 Ukraine Electric Power Attack and Industroyer for historical threat-informed context.
ATT&CK does not specify tactics, platforms for the technique itself, or official detection text. Telemetry and control recommendations therefore require validation against the local OT architecture, protocols, device capabilities, logging availability, and safety constraints.
Command Message
Adversaries may block a command message from reaching its intended target to prevent command execution. In OT networks, command messages are sent to provide instructions to control system devices. A blocked command message can inhibit response functions from correcting a disruption or unsafe condition.[1][2]
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.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| ICS | T0803 | Block Command Message | Block Command Message revoked by this object. |
| ICS | T1691 | Block Operational Technology Message | This object subtechnique of Block Operational Technology Message. |
Groups, software, and campaigns
S0604: Industroyer
Industroyer is a sophisticated malware framework designed to cause an impact to the working processes of Industrial Control Systems (ICS), specifically components used in electrical substations.[1] Industroyer was used in the attacks on the Ukrainian power grid in December 2016.[2] This is the first publicly known malware specifically designed to target and impact operations in the electric grid.[3]
C0028: 2015 Ukraine Electric Power Attack
2015 Ukraine Electric Power Attack was a Sandworm Team campaign during which they used BlackEnergy (specifically BlackEnergy3) and KillDisk to target and disrupt transmission and distribution substations within the Ukrainian power grid. This campaign was the first major public attack conducted against the Ukrainian power grid by Sandworm Team.
All related ATT&CK context
Mitigation direction
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 | 055412b7447d… |
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]
Bonnie Zhu, Anthony Joseph, Shankar Sastry 2011
Bonnie Zhu, Anthony Joseph, Shankar Sastry 2011 A Taxonomy of Cyber Attacks on SCADA Systems Retrieved. 2018/01/12
Open source URL -
[2]
Electricity Information Sharing and Analysis Center; SANS Industrial Control Systems March 2016
Electricity Information Sharing and Analysis Center; SANS Industrial Control Systems 2016, March 18 Analysis of the Cyber Attack on the Ukranian Power Grid: Defense Use Case Retrieved. 2018/03/27
Open source URL -
[3]
mitre-attack T1691.001Open 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.