T1692: Unauthorized Message
Adversaries may send unauthorized messages to ICS systems and devices to evade defenses or manipulate processes. Unauthorized messages can be categorized as either reporting messages that contain telemetry data about the current state of systems, devices, and processes or as command messages which instruct systems and devices on how to operate. By injecting unauthorized messages, adversaries can make it appear as if everything is working correctly when it isn’t, trigger alarms to misdirect personnel or impact processes, and manipulate controls to disrupt processes.[1]
Adversaries may send unauthorized messages in an ICS environment using software found within the environment (living-off-the-land, vendor-specific interfaces, etc.), custom tooling leveraging OT protocols and libraries, or by positioning themselves between systems and devices and injecting messages into the communications such as the case with an Adversary-in-the-Middle attack.
Analyst context for executives and security teams
Unauthorized Message is an ICS technique where an adversary sends false or unauthorized telemetry or control messages into an operational environment. The business issue is not just network intrusion; it is loss of trust in what operators see and what controllers are told to do. If messages can be spoofed or injected, teams may make decisions from false process data, chase misleading alarms, or experience unauthorized process changes.
Executive priority
Prioritize this as an operational resilience and safety-adjacent control question for ICS environments. Leaders should ask whether critical HMI, PLC, RTU, IED, control server, safety controller, DCS controller, and PAC communications are authenticated, segmented, filtered, and baselined. This technique is material for incident response readiness because responders must be able to distinguish legitimate process behavior from manipulated reporting or command traffic.
Technical view
SOC, OT security, and IR teams should validate visibility and controls around ICS message paths, especially communications involving HMIs, controllers, RTUs, IEDs, control servers, safety controllers, DCS controllers, and PACs. ATT&CK does not provide official detection text for this object, but the relationship to DET0902 indicates a detection strategy exists for unauthorized messages. Detection engineering should focus on whether authorized senders, expected message types, rates, sequences, and process-state preconditions can be verified for command and reporting traffic. Investigations should consider living-off-the-land use of vendor interfaces, custom tooling using OT protocols, and adversary-in-the-middle positioning as described by the source object.
Likely telemetry
- ICS network traffic captures or flow records between control servers, HMIs, RTUs, PLCs, IEDs, safety controllers, DCS controllers, and PACs
- Application-layer automation protocol metadata where available, including message type, source, destination, timing, and sequence patterns
- Controller, HMI, control server, and engineering/workstation logs where they record commands, connections, alarms, telemetry changes, or API access
- Asset inventory and approved communication matrices for IP address, MAC address, port, protocol, and expected device relationships
- Process historian, alarm, and telemetry records that can be compared against expected operational states
Detection direction
- Validate that DET0902 or local detections can identify messages from unauthorized sources, unexpected device pairs, unexpected protocols, abnormal message types, or unusual message rates.
- Tune detections against known operating modes and maintenance windows to reduce false positives from legitimate vendor tools or authorized operational changes.
- Look for mismatches between reporting messages and independent process expectations, since spoofed reporting messages can make operations appear normal when they are not.
- Correlate command messages with expected logical preconditions and authorized operator or control-server activity where such records exist.
- Assess blind spots caused by limited OT protocol parsing, encrypted or proprietary traffic, unmanaged field devices, or lack of passive monitoring in segmented control networks.
Mitigation priorities
- Start with network segmentation to restrict enterprise or non-required network paths to critical process control systems.
- Implement communication authenticity where supported, using secure protocols or mechanisms that authenticate message senders and verify message integrity.
- Require authentication for devices and software processes, including remote device communications and API access where applicable.
- Use network allowlists for permitted IP addresses, MAC addresses, ports, protocols, and device-to-device connections.
- Apply protocol-aware traffic filtering for automation protocols when expected communication sequences, message types, rates, or patterns are well defined.
Analyst notes and limits
The parent technique includes two important defensive branches: unauthorized command messages and spoofed reporting messages. Treat both as separate validation cases because one affects what devices are instructed to do and the other affects what operators and monitoring systems believe is happening. The targeted asset relationships make this especially relevant to OT environments with HMIs, controllers, RTUs, IEDs, control servers, and safety-related control assets.
ATT&CK provides no official detection text, no tactics, and no platform list for the parent technique. The related target assets include embedded, Linux, and Windows platforms, but those should not be treated as exhaustive platform coverage for T1692. Local architecture, protocol support, vendor capabilities, and available OT telemetry are required to determine actual exposure and detection coverage.
Unauthorized Message
Adversaries may send unauthorized messages to ICS systems and devices to evade defenses or manipulate processes. Unauthorized messages can be categorized as either reporting messages that contain telemetry data about the current state of systems, devices, and processes or as command messages which instruct systems and devices on how to operate. By injecting unauthorized messages, adversaries can make it appear as if everything is working correctly when it isn’t, trigger alarms to misdirect personnel or impact processes, and manipulate controls to disrupt processes.[1]
Adversaries may send unauthorized messages in an ICS environment using software found within the environment (living-off-the-land, vendor-specific interfaces, etc.), custom tooling leveraging OT protocols and libraries, or by positioning themselves between systems and devices and injecting messages into the communications such as the case with an Adversary-in-the-Middle attack.
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.002 | Reporting Message Sub-technique | Reporting Message subtechnique of this object. |
| ICS | T1692.001 | Command Message Sub-technique | Command Message subtechnique of this object. |
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 | e0853b732edd… |
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]
mitre-attack T1692Open 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.