T1692.002: Reporting Message
Adversaries may spoof reporting messages in control system environments for evasion and to impair process control. In control systems, reporting messages contain telemetry data (e.g., I/O values) pertaining to the current state of equipment and the industrial process. Reporting messages are important for monitoring the normal operation of a system or identifying important events such as deviations from expected values.
If an adversary has the ability to Spoof Reporting Messages, they can impact the control system in many ways. The adversary can Spoof Reporting Messages that state that the process is operating normally, as a form of evasion. The adversary could also Spoof Reporting Messages to make the defenders and operators think that other errors are occurring in order to distract them from the actual source of a problem.[1]
Analyst context for executives and security teams
Reporting Message spoofing matters because ICS operators often make safety and continuity decisions based on telemetry that says what equipment and the process are doing. If those messages are false, defenders may see “normal” conditions during a real issue or chase misleading alarms while the actual problem continues. The business concern is not only cyber intrusion; it is loss of trustworthy operational awareness across HMIs, controllers, RTUs, IEDs, control servers, gateways, and safety-related devices.
Executive priority
Treat this as an operational resilience and cyber-physical risk topic: can the organization prove that critical process telemetry is authentic, expected, and restricted to approved paths? Leaders should ask whether ICS network segmentation, sender/device authentication, protocol filtering, and allowlists are implemented for the control paths that matter most. This also supports audit and incident readiness because response teams need evidence that telemetry shown to operators can be trusted during abnormal events.
Technical view
ATT&CK provides no official detection text for T1692.002, but it is linked to detection strategy DET0746 and mitigations focused on communication authenticity, device/process authentication, allowlisting, segmentation, and traffic filtering. SOC and IR teams should validate visibility into reporting-message flows between field/control assets and operator-facing systems, especially where HMIs, PLCs, RTUs, IEDs, control servers, data gateways, safety controllers, DCS controllers, and PACs exchange telemetry. Detection engineering should focus on unauthorized senders, unexpected message paths, abnormal message types/rates/sequences, and inconsistencies between expected operations and reported I/O or event data.
Likely telemetry
- ICS network traffic containing reporting/telemetry messages between control assets
- Protocol-aware logs or captures for automation protocols where available, such as those referenced in ATT&CK context for control servers and filtering
- HMI and control server event, alarm, and telemetry records
- RTU, PLC, IED, PAC, DCS controller, safety controller, and data gateway communication or event logs where supported
- Network allowlist, firewall, segmentation, and protocol-filter enforcement logs
Detection direction
- Confirm whether DET0746 or an equivalent local analytic exists; ATT&CK does not provide detection implementation detail in the supplied object.
- Baseline legitimate telemetry sources, destinations, ports, protocols, message types, rates, and sequences for critical processes.
- Alert on reporting messages from unauthorized or unexpected devices, networks, or software processes.
- Tune for operational false positives caused by maintenance, commissioning, protocol translation, gateway changes, or failover paths.
- Correlate operator-visible HMI values and alerts with lower-level device or network evidence when available, because spoofed reporting messages may be intended to make the process appear normal or to misdirect personnel.
Mitigation priorities
- Prioritize communication authenticity for untrusted network paths using mechanisms that authenticate the sender and verify message integrity, consistent with M0802.
- Require authentication for devices and software processes where appropriate, especially remote connections and API access, consistent with M0813.
- Restrict which devices can communicate using network allowlists for IP address, MAC address, port, and protocol where feasible, consistent with M0807.
- Segment critical process control systems from enterprise and other non-required networks, using physical/logical segmentation and DMZ patterns where applicable, consistent with M0930.
- Use ingress/egress and protocol-aware filtering, including application-layer allow/deny logic for automation protocols where communication patterns are well defined, consistent with M0937.
Analyst notes and limits
This object is a sub-technique of T1692 Unauthorized Message and supersedes the revoked T0856 Spoof Reporting Message. The supplied relationships show broad ICS asset relevance, including HMIs, PLCs, RTUs, IEDs, control servers, data gateways, safety controllers, DCS controllers, and PACs. The Maroochy Water Breach campaign is listed as using this object, but this take does not infer current activity or broader attribution from that relationship.
The supplied ATT&CK object does not specify tactics, technique platforms, or official detection guidance. Defensive recommendations are therefore based on the official description, cited relationships, and listed mitigations; local engineering diagrams, asset inventories, protocol details, and process-safety requirements are required to determine actual exposure and coverage.
Reporting Message
Adversaries may spoof reporting messages in control system environments for evasion and to impair process control. In control systems, reporting messages contain telemetry data (e.g., I/O values) pertaining to the current state of equipment and the industrial process. Reporting messages are important for monitoring the normal operation of a system or identifying important events such as deviations from expected values.
If an adversary has the ability to Spoof Reporting Messages, they can impact the control system in many ways. The adversary can Spoof Reporting Messages that state that the process is operating normally, as a form of evasion. The adversary could also Spoof Reporting Messages to make the defenders and operators think that other errors are occurring in order to distract them from the actual source of a problem.[1]
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 | T0856 | Spoof Reporting Message | Spoof Reporting Message revoked by this object. |
Groups, software, and campaigns
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]
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 | d73e04ce24f5… |
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 T1692.002Open 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.