T1692 Unauthorized Message: Detecting Unauthorised Command and Spoofed Reporting Messages

Unauthorized Message (T1692) is the technique where an adversary sends structurally valid OT protocol messages that no legitimate operator or controller issued, either to command equipment or to feed false telemetry to the people and systems watching it. MITRE ATT&CK for ICS v20 created T1692 in April 2026 under two tactics, Evasion (TA0103) and Impair Process Control (TA0106), for Embedded, Windows and Linux platforms. Its sub-techniques, Command Message (T1692.001) and Reporting Message (T1692.002), replace the revoked Unauthorized Command Message (T0855) and Spoof Reporting Message (T0856). This guide is for OT security engineers, control engineers and SOC analysts. It covers why industrial protocols accept such messages, the cases ATT&CK records, the v20 analytics, protocol-aware inspection and message authentication, and a safe response. For the protocol baseline see the Modbus TCP and Modbus Security Guide; this page focuses on the technique.

Key takeaways

• Valid but unauthorised. The messages are well formed; what is wrong is the source, the timing or the logical preconditions, so signature-style detection rarely helps.
• Commands and lies. Command messages make equipment act; spoofed reporting messages make the process look normal, or raise false alarms to misdirect operators.
• It is the core of most known grid and safety attacks. ATT&CK lists Industroyer, Industroyer2, Triton, INCONTROLLER, the 2015 and 2022 Ukraine attacks and the Maroochy water breach as procedure examples.
• Legitimate tools are often the weapon. ATT&CK records CyberAv3ngers using vendors' own PLC programming software and Sandworm using a SCADA system's own API.
• Know who may talk to whom. The v20 analytic flags valid ICS messages from a source outside the approved communication baseline; authentication and inline allowlisting are the long-term fixes.

What T1692 covers

ATT&CK describes the injected messages in the same two categories it uses across ICS: command messages that instruct devices how to operate, and reporting messages that carry telemetry about the state of systems and the process. Injecting them lets an adversary make it appear that everything is working when it is not, trigger alarms to misdirect personnel, and manipulate controls to disrupt the process. ATT&CK names three ways to send them: software already in the environment (living off the land, vendor interfaces), custom tooling built on OT protocols and libraries, and an adversary-in-the-middle position (T0830) that injects messages into existing communication.

Neighbouring techniques have their own pages: Block Operational Technology Message (T1691) stops messages instead of forging them, and Manipulation of View (T0832) and Alarm Suppression (T0878) target what operators see. For the tactic overview see the ATT&CK for ICS Impair Process Control Tactic Guide.

Why industrial protocols accept these messages

Many widely deployed protocols were designed for closed networks and trust any correctly formatted message that reaches the device. Classic Modbus has no authentication field at all; DNP3 and IEC 60870-5-104 have security extensions that are not always deployed. Where authentication exists but is off, the device cannot tell a historian's poll from an attacker's write. That is why ATT&CK's mitigations focus on authenticity, allowlisting and segmentation, and why detection must use context: who sent it, when, and whether it fits the process.

Real cases recorded by ATT&CK

• 2015 Ukraine Electric Power Attack (C0028): Sandworm Team (G0034) issued unauthorised commands to substation breakers after gaining control of operator workstations and a distribution management system application. The commands came from the operators' own tools. See the Sandworm Threat Actor Profile.
• Industroyer (S0604) and Industroyer2 (S1072): ATT&CK records Industroyer sending unauthorised commands to RTUs through its protocol payloads to change equipment state, and Industroyer2 sending command messages to remote stations to open data channels, retrieve Information Object Addresses and change I/O state values.
• 2022 Ukraine Electric Power Attack (C0034): Sandworm Team used the MicroSCADA SCIL-API to specify SCADA instructions, including unauthorised commands to substation devices.
• Triton Safety Instrumented System Attack (C0030): TEMP.Veles (G0088) used Triton (S1009) to send unauthorised command messages to Triconex safety controllers. See the Safety Instrumented Systems Security Guide.
• INCONTROLLER (S1045): ATT&CK records that it can send custom Modbus commands to write register values on Schneider PLCs and write tag values on OPC UA servers. The joint CISA, DOE, NSA and FBI advisory AA22-103A describes the toolset. See the PIPEDREAM (INCONTROLLER) ICS Toolkit Guide.
• CyberAv3ngers (G1027): ATT&CK records that in its 2026 Iranian Water Campaign the group used manufacturers' commercial PLC programming and maintenance software to send unauthorised command messages to multiple victim controllers. See the CyberAv3ngers Threat Actor Profile Guide.
• Maroochy Water Breach (C0020): the only reporting message example ATT&CK lists: the adversary used a dedicated analogue two-way radio system to send false data and instructions to pumping stations and the central computer.

ATT&CK also cites the 2017 Dallas siren incident, where command messages activated the city's tornado sirens with no emergency. The common thread is that the receiving equipment had no way to reject a message from the wrong sender.

Detection: ATT&CK v20 analytics and deep packet inspection

MITRE's detection strategy DET0902 has three analytics, each with the OT operational fidelity gate (alert only when the activity cannot be attributed to an authorised operator or engineering source and falls outside approved change context; suppress approved maintenance, commissioning, failover and recovery).

The communication matrix is the foundation: a record of which hosts may send which message types to which devices. Protocol-aware deep packet inspection on an OT sensor adds the detail the matrix needs, decoding reads versus writes, program and mode changes, and the target addresses or tags. Useful detections built on it include: write or control operations from a host that has only ever read; any write to a safety controller outside a maintenance window; control commands outside operator shift patterns; and reported values that contradict physics or a redundant sensor. Process-aware checks catch spoofed reporting, which no network rule will. For the 2015 and 2022 cases, the process on the operator workstation was legitimate, so host analytics (AN2283) must also consider who was logged on and from where. See the OT Network Security Monitoring Guide.

Prevention: the ATT&CK mitigations in practice

• M0802 Communication Authenticity: ATT&CK says control protocols should provide authenticity through MAC functions or digital signatures, and where devices cannot, bump-in-the-wire devices or VPNs can enforce it for legacy controllers and RTUs.
• M0813 Software Process and Device Authentication: devices should authenticate all messages between master and outstation assets.
• M0807 Network Allowlists: host-based allowlists so devices accept connections only from master stations or known engineering workstations. CISA's AA22-103A gives the same advice: limit ICS connections to specifically approved management and engineering workstations.
• M0937 Filter Network Traffic: inline allowlisting of automation protocol commands, designed accurately enough not to block valid messages.
• M0930 Network Segmentation: segment operational assets and their management devices by functional role, with stricter isolation for the most critical control. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.

Many controllers also have a physical or software run mode that prevents program changes. Keeping safety controllers in run mode outside maintenance closes one path Triton relied on; see the safety guide above for detail.

Where identity fits

Several cases used legitimate software on legitimate hosts, so the question becomes who was operating it. Shared operator and engineering accounts make that impossible to answer. Use named accounts on HMIs and engineering workstations, phishing-resistant MFA for remote access into OT, and separate accounts for remote vendors with time-bound access. In protocols that support it, device and application credentials (DNP3 Secure Authentication keys, OPC UA application certificates) are non-human identities that need an owner, a store and a rotation plan. See the OT and ICS Identity and Access Guide.

How to implement

1. Build the communication matrix from passive monitoring over a full operating cycle, then review it with control engineers to remove anything unexpected.
2. Classify message types per device: read only, operator control, engineering (program, configuration, firmware), safety. Agree which hosts may send each.
3. Deploy DET0902-style alerts in alert-only mode, starting with writes and engineering operations from unapproved sources and any engineering operation on safety controllers.
4. Add host analytics on HMIs, engineering workstations and SCADA servers: allowlist the processes that may speak ICS protocols and alert on others.
5. Enable device allowlists (permitted master IPs) and protocol authentication where devices support them, during planned outages and with tested rollback.
6. Pilot inline command filtering in monitor mode on one conduit, review false positives with operations, then enforce.
7. Add process plausibility checks with control engineers, comparing redundant measurements to catch spoofed reporting.

Decision guidance

• Passive DPI or inline filtering: start passive everywhere; enforce inline only on conduits where the command set is well understood and a false block is tolerable or bypassable.
• Native protocol security or bump-in-the-wire: prefer native authentication when devices support it; use bump-in-the-wire devices or VPNs for legacy RTUs and controllers, accepting added latency and another device to manage.
• Small sites: device-level master IP allowlists, segmentation and a strict list of engineering workstations give most of the benefit without a monitoring platform.
• Safety systems: treat any unexpected message to a safety controller as an incident, not a tuning question.

Responding to unauthorised messages

Bring operations in at once: confirm the actual process state from local indication or field checks, not from a screen that may be spoofed, and move to manual or safe-state operation if needed. Identify the sending host and account. Preserve network captures, HMI and engineering workstation logs, controller logs and the current controller program before changes. Contain by blocking the source at the conduit and disabling the account or remote session, rather than shutting down supervisory systems operators need. Verify controller programs and setpoints against known-good copies, restore where they differ, and keep monitoring for repeat attempts. Report to your national authority as your sector rules require. See the OT Incident Response Guide.

Detection and measurement

• Matrix coverage: percentage of control-relevant devices with an approved communication matrix entry.
• Unauthorised source alerts: number per month of ICS messages from sources outside the matrix, and time to triage each.
• Authentication coverage: percentage of capable devices with protocol authentication or a bump-in-the-wire control turned on.
• Allowlist coverage: percentage of controllers and RTUs restricted to approved master IPs.
• Engineering operations attributed: percentage of program, mode or configuration changes linked to a named user and change ticket.

Framework mapping

Common failure patterns

• Trusting valid syntax: monitoring that only flags malformed packets misses every case on this page.
• Flat control networks: any host that reaches the control VLAN can send writes, which is what the INCONTROLLER tooling relied on.
• Shared engineering accounts: when the legitimate tool sends the command, an unnamed account leaves nothing to investigate.
• Trusting the HMI during an incident: if reporting may be spoofed, decisions need local or redundant indication.
• Authentication bought but not turned on: devices that support DNP3 Secure Authentication or OPC UA security left in unsecured mode.

Practitioner checklist

• Build and approve a communication matrix of who may send which message types to which devices.
• Alert on ICS writes and engineering operations from sources outside the matrix.
• Allowlist the processes that may speak ICS protocols on HMIs, SCADA servers and engineering workstations.
• Turn on protocol authentication where supported; plan bump-in-the-wire or VPN controls for legacy devices.
• Restrict controllers and RTUs to approved master IPs.
• Keep safety controllers out of program mode outside maintenance and alert on any engineering traffic to them.
• Use named accounts and MFA for operator, engineering and vendor access.
• Exercise a response that verifies process state locally before trusting screens.

Standards and references

• MITRE ATT&CK for ICS: Unauthorized Message (T1692)
• MITRE ATT&CK: Detection of Unauthorized Message (DET0902)
• NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
• CISA, DOE, NSA and FBI: APT Cyber Tools Targeting ICS/SCADA Devices (AA22-103A)
• CISA and partners: IRGC-Affiliated Cyber Actors Exploit PLCs in Multiple Sectors (AA23-335A)
• ESET: Industroyer, Biggest Threat to Industrial Control Systems Since Stuxnet
• CISA, FBI, EPA and DOE: Primary Mitigations to Reduce Cyber Threats to Operational Technology

Related NHI Mgmt Group resources: Modbus TCP and Modbus Security Guide · ATT&CK for ICS Impair Process Control Tactic Guide · MITRE ATT&CK for ICS Guide · DNP3 and DNP3 Secure Authentication Guide · PIPEDREAM (INCONTROLLER) ICS Toolkit Guide