T1691.002: Reporting Message
Adversaries may block or prevent a reporting message from reaching its intended target. In control systems, reporting messages contain telemetry data (e.g., I/O values) pertaining to the current state of equipment and the industrial process. By blocking these reporting messages, an adversary can potentially hide their actions from an operator.
Blocking reporting messages in control systems that manage physical processes may contribute to system impact, causing inhibition of a response function. A control system may not be able to respond in a proper or timely manner to an event, such as a dangerous fault, if its corresponding reporting message is blocked.[1][2]
Analyst context for executives and security teams
Reporting Message is an ICS sub-technique where an adversary prevents telemetry about equipment or process state from reaching operators or control systems. The business issue is not just lost data; it is delayed or incorrect operational decision-making. If I/O values, events, or alerts are blocked, operators may not see a dangerous condition and automated or human response functions may be inhibited.
Executive priority
Treat this as an operational resilience and safety visibility risk. Leaders should ask whether critical telemetry paths between field devices, gateways, controllers, control servers, and HMIs are mapped, monitored, and recoverable during communications failures or data integrity attacks. Priority should go to environments where blocked reporting could affect safety controllers, protection devices, substations, continuous processes, or other physical operations that depend on timely telemetry.
Technical view
ATT&CK provides no official detection text for T1691.002, but it is linked to detection strategy DET0789, Detection of Block Reporting Message. SOC, OT monitoring, and IR teams should validate whether they can identify missing, delayed, or interrupted telemetry between targeted ICS assets including Field I/O, PLCs, RTUs, IEDs, DCS controllers, PACs, data gateways, control servers, safety controllers, and HMIs. Detection should focus on deviations from expected communication patterns and gaps between process state, device events, and HMI/control-server visibility. Historical ATT&CK relationship context includes use by the 2015 Ukraine Electric Power Attack campaign and Industroyer, so this behavior should be considered in ICS incident playbooks without assuming current exposure or activity.
Likely telemetry
- ICS network communications between field devices, controllers, RTUs, data gateways, control servers, and HMIs
- Expected telemetry polling or reporting intervals for automation protocols such as those used by control servers and field devices, where available locally
- HMI and control-server event logs showing stale values, communication loss, bad quality points, or missing updates
- RTU, PLC, IED, safety controller, DCS controller, PAC, and Field I/O diagnostics indicating communication failures or missed reports
- Network device logs or flow records showing blocked, dropped, rerouted, or absent expected connections
Detection direction
- Validate DET0789-aligned coverage for blocked reporting messages, since the object itself has no official detection guidance.
- Baseline normal telemetry sources, destinations, ports, protocols, and timing for critical ICS reporting paths before relying on anomaly detection.
- Tune for missing or stale reporting messages, not only malicious packets; the key signal may be absence of expected telemetry.
- Correlate HMI/control-server visibility with device-side diagnostics and independent process evidence to reduce false positives from maintenance, outages, or planned configuration changes.
- Pay special attention to data gateways and RTUs because they commonly aggregate or forward telemetry and may create a single visibility chokepoint.
Mitigation priorities
- Implement network allowlists where feasible so devices can only communicate over expected IP, MAC, port, and protocol paths, consistent with M0807.
- Use static network configuration where possible to reduce opportunities for dynamic discovery or addressing mechanisms to manipulate message forwarding, consistent with M0814.
- Plan out-of-band communications channels for critical communication requirements during failures or data integrity attacks, consistent with M0810.
- Prioritize controls around telemetry paths that support safety, protection, alarm handling, and operator situational awareness.
- Test mitigation changes carefully in OT environments because static configurations and allowlists can disrupt legitimate industrial communications if asset inventories or dependencies are incomplete.
Analyst notes and limits
This is a sub-technique of Block Operational Technology Message and replaces the revoked Block Reporting Message technique T0804. The asset relationships make the behavior broadly relevant across ICS telemetry chains, including HMIs, PLCs, RTUs, IEDs, control servers, data gateways, safety controllers, Field I/O, DCS controllers, and PACs. ATT&CK references include SCADA attack taxonomy material and analysis of the Ukrainian power grid attack; use that context for scenario planning, not as evidence of activity in any specific environment.
Platforms and tactics are not specified for this object, and MITRE does not provide official detection text. Practical detection and control validation require local engineering diagrams, protocol knowledge, normal polling/reporting baselines, maintenance schedules, and device logging capabilities. The relationships support historical and software context, but they do not establish current exploitation or detection coverage in any environment.
Reporting Message
Adversaries may block or prevent a reporting message from reaching its intended target. In control systems, reporting messages contain telemetry data (e.g., I/O values) pertaining to the current state of equipment and the industrial process. By blocking these reporting messages, an adversary can potentially hide their actions from an operator.
Blocking reporting messages in control systems that manage physical processes may contribute to system impact, causing inhibition of a response function. A control system may not be able to respond in a proper or timely manner to an event, such as a dangerous fault, if its corresponding reporting message is blocked.[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 | T0804 | Block Reporting Message | Block Reporting 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 | 6ff11a0743c4… |
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.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.