T1692.001: Command Message
Adversaries may send unauthorized command messages to instruct control system assets to perform actions outside of their intended functionality, or without the logical preconditions to trigger their expected function. Command messages are used in ICS networks to give direct instructions to control systems devices. If an adversary can send an unauthorized command message to a control system, then it can instruct the control systems device to perform an action outside the normal bounds of the device's actions. An adversary could potentially instruct a control systems device to perform an action that will cause an Impact.[1]
In the Dallas Siren incident, adversaries were able to send command messages to activate tornado alarm systems across the city without an impending tornado or other disaster.[2][3]
Analyst context for executives and security teams
Command Message is an ICS sub-technique where an unauthorized command is sent to control system assets, potentially causing equipment, alarms, or safety-related functions to operate outside expected conditions. For leaders, the decision value is simple: if command paths are not authenticated, segmented, filtered, and monitored, a cyber event can become an operational or public-safety event, as illustrated by ATT&CK’s Dallas siren example and related ICS campaign/software relationships.
Executive priority
Prioritize this behavior anywhere digital commands can change physical state or public-facing operations. Executives should ask whether critical command channels are explicitly authorized, whether operators can distinguish legitimate commands from spoofed or out-of-sequence ones, and whether audit evidence exists for authentication, segmentation, allowlisting, and protocol filtering controls. This matters for operational resilience, incident decision-making, compliance readiness, and cyber-physical risk governance.
Technical view
SOC, OT security, and IR teams should validate monitoring around command traffic to targeted ICS assets identified by ATT&CK: HMIs, PLCs, RTUs, IEDs, control servers, safety controllers, DCS controllers, and PACs. MITRE does not provide official detection text for this object, but the related detection strategy is DET0794, Detection of Unauthorized Command Message. Defensive validation should focus on whether command messages are expected for the source, destination, protocol, sequence, rate, and operating state, and whether unauthorized or logically invalid commands generate alerts and investigation evidence.
Likely telemetry
- ICS network traffic containing command messages and automation protocol activity
- Source and destination identity for command paths, including IP address, MAC address, port, and protocol where available
- Application-layer protocol details for control communications such as command type, sequence, rate, and pattern
- HMI, control server, RTU, PLC, IED, safety controller, DCS controller, and PAC logs where available
- Authentication, authorization, and integrity-validation events for devices, software processes, and remote connections
Detection direction
- Confirm DET0794-style coverage exists for unauthorized command messages rather than relying only on generic network availability monitoring.
- Baseline legitimate command sources, destinations, protocols, message types, rates, and operating sequences for critical ICS processes.
- Tune detections for commands that come from unexpected systems, cross segmentation boundaries, fail authenticity checks, violate process logic, or occur without expected operator or system preconditions.
- Account for false positives from maintenance, commissioning, failover, testing, and emergency operations by requiring documented change windows and operator context.
- Look for blind spots where legacy protocols, embedded devices, serial-to-IP gateways, or limited endpoint logging prevent attribution of a command to a specific user, process, or device.
Mitigation priorities
- Start with Communication Authenticity: use secure protocols or compensating controls that authenticate the sender and verify message integrity using mechanisms such as MACs or digital signatures where supported.
- Require Software Process and Device Authentication for devices, remote connections, and software processes that access control APIs or issue commands.
- Apply Network Segmentation to isolate critical process control systems and prevent unnecessary enterprise or external access to command paths.
- Implement Network Allowlists so only required devices, addresses, ports, and protocols can communicate with control assets.
- Use Filter Network Traffic for protocol-aware filtering of automation traffic, especially where expected communication sequences, types, rates, or patterns are well defined.
Analyst notes and limits
This object is a sub-technique of T1692 Unauthorized Message and replaces the revoked T0855 Unauthorized Command Message. ATT&CK relationships show this behavior targets multiple ICS asset classes and is associated with historical campaigns and ICS malware, but those relationships should be used for defensive prioritization and scenario planning rather than assumptions about current activity. The strongest local validation questions are: which systems are allowed to send commands, how are those commands authenticated, and can the SOC prove when a command was unauthorized?
MITRE provides no official detection text, no tactics, and no primary platform list for this specific object. Platform context is available only through related targeted assets and related software, so environment-specific architecture and telemetry are required before making coverage claims. This take does not assert active exploitation, attribution, customer exposure, or guaranteed detection.
Command Message
Adversaries may send unauthorized command messages to instruct control system assets to perform actions outside of their intended functionality, or without the logical preconditions to trigger their expected function. Command messages are used in ICS networks to give direct instructions to control systems devices. If an adversary can send an unauthorized command message to a control system, then it can instruct the control systems device to perform an action outside the normal bounds of the device's actions. An adversary could potentially instruct a control systems device to perform an action that will cause an Impact.[1]
In the Dallas Siren incident, adversaries were able to send command messages to activate tornado alarm systems across the city without an impending tornado or other disaster.[2][3]
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 | T1692 | Unauthorized Message | This object subtechnique of Unauthorized Message. |
| ICS | T0855 | Unauthorized Command Message | Unauthorized Command Message revoked by this object. |
Groups, software, and campaigns
S1045: INCONTROLLER
INCONTROLLER is custom malware that includes multiple modules tailored towards ICS devices and technologies, including Schneider Electric and Omron PLCs as well as OPC UA, Modbus, and CODESYS protocols. INCONTROLLER has the ability to discover specific devices, download logic on the devices, and exploit platform-specific vulnerabilities. As of September 2022, some security researchers assessed INCONTROLLER was developed by CHERNOVITE.[1][2][3][4][5]
S1072: Industroyer2
Industroyer2 is a compiled and static piece of malware that has the ability to communicate over the IEC-104 protocol. It is similar to the IEC-104 module found in Industroyer. Security researchers assess that Industroyer2 was designed to cause impact to high-voltage electrical substations. The initial Industroyer2 sample was compiled on 03/23/2022 and scheduled to execute on 04/08/2022, however it was discovered before deploying, resulting in no impact.[1]
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]
C0020: Maroochy Water Breach
Maroochy Water Breach was an incident in 2000 where an adversary leveraged the local government’s wastewater control system and stolen engineering equipment to disrupt and eventually release 800,000 liters of raw sewage into the local community.[1]
C0030: Triton Safety Instrumented System Attack
Triton Safety Instrumented System Attack was a campaign employed by TEMP.Veles which leveraged the Triton malware framework against a petrochemical organization.[1] The malware and techniques used within this campaign targeted specific Triconex Safety Controllers within the environment.[2] The incident was eventually discovered due to a safety trip that occurred as a result of an issue in the malware.[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.
C0034: 2022 Ukraine Electric Power Attack
The 2022 Ukraine Electric Power Attack was a Sandworm Team campaign that used a combination of GOGETTER, Neo-REGEORG, CaddyWiper, and living of the land (LotL) techniques to gain access to a Ukrainian electric utility to send unauthorized commands from their SCADA system.[1][2]
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 | 21c2ee383d8f… |
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]
Zack Whittaker April 2017
Zack Whittaker 2017, April 12 Dallas' emergency sirens were hacked with a rogue radio signal Retrieved. 2020/11/06
Open source URL -
[3]
Benjamin Freed March 2019
Benjamin Freed 2019, March 13 Tornado sirens in Dallas suburbs deactivated after being hacked and set off Retrieved. 2020/11/06
Open source URL -
[4]
mitre-attack T1692.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.