T1691: Block Operational Technology Message
Adversaries may block messages between systems and devices in an OT/ICS environment to disrupt processes. Messages typically fall into two categories: (1) reporting messages that contain telemetry data about the current state of systems, devices, and processes and (2) command messages that contain instructions to control systems, devices, and processes. Both types of messages are critical for the proper functioning of industrial control processes and failure of the messages to reach their intended destinations could inhibit response functions or create an unsafe condition that could have physical impacts.[1][2]
Adversaries may block communications by either making modifications to software (System Firmware, Module Firmware, Hooking, and Rootkit) and services (Service Stop, Denial of Service) on systems and devices or by positioning themselves between systems and devices and intercepting and blocking the communications such as the case with an Adversary-in-the-Middle attack.
Analyst context for executives and security teams
Blocking OT messages matters because industrial processes depend on timely command and reporting traffic between HMIs, control servers, PLCs, RTUs, IEDs, safety controllers, field I/O, DCS controllers, and PACs. If command messages do not arrive, operators or control logic may be unable to correct a disruption or unsafe condition. If reporting messages do not arrive, operators may lose visibility into the real state of equipment and the process. The business issue is not just network availability; it is whether the organization can maintain safe operations and make reliable incident decisions when OT communications are degraded or manipulated.
Executive priority
Treat this as an operational resilience and safety-risk scenario for OT/ICS environments. Leaders should ask whether critical control paths have documented message dependencies, whether loss of telemetry or command delivery is distinguishable from normal equipment failure, and whether teams have out-of-band communication options when primary OT communications fail. Control investment should prioritize network allowlisting, static network configuration where feasible, and alternate communications for communication failures or data integrity attacks, as identified by ATT&CK relationships.
Technical view
ATT&CK provides no official detection text for T1691, but it links a detection strategy, DET0903, to this behavior. SOC, OT engineering, and IR teams should validate monitoring around interruption or absence of expected OT command and reporting messages, especially across communication paths involving HMIs, control servers, RTUs, PLCs, IEDs, safety controllers, field I/O, DCS controllers, and PACs. Analysis should consider the related mechanisms named by ATT&CK: firmware or software modification, hooking, rootkits, service stoppage, denial of service, and adversary-in-the-middle positioning. The two sub-techniques are useful triage categories: blocked command messages affect execution of control instructions, while blocked reporting messages affect telemetry visibility and may hide process state from operators.
Likely telemetry
- OT network communication records showing expected connections, IP addresses, MAC addresses, ports, and protocols where available
- Application-layer OT protocol observations where collected, such as command and telemetry message presence or absence
- HMI and control server communication status, alarm, and operator visibility indicators
- PLC, RTU, IED, safety controller, field I/O, DCS controller, and PAC communication health or event logs where available
- Service status and availability evidence on systems participating in control communications
Detection direction
- Validate whether DET0903 or local analytic logic can identify missing, blocked, or unexpectedly interrupted OT messages, not only high-volume denial-of-service conditions.
- Separate command-message failures from reporting-message failures during triage; the operational consequences and response priorities differ.
- Tune detections against known maintenance windows, planned equipment outages, and normal process-state transitions to reduce false positives.
- Look for gaps where OT monitoring sees device reachability but not whether command or reporting messages actually reached the intended destination.
- Correlate network evidence with HMI/control server views and field-device status so blocked telemetry is not mistaken for a stable process condition.
Mitigation priorities
- Implement network allowlists for permitted device connections using supported identifiers such as IP address, MAC address, port, and protocol.
- Use static network configuration where feasible to reduce opportunities for manipulation of dynamic discovery or addressing that could alter message forwarding.
- Plan and test out-of-band communication channels to support operational coordination during communication failures and data integrity attacks.
- Document critical command and reporting paths between HMIs, control servers, RTUs, PLCs, IEDs, safety controllers, field I/O, DCS controllers, and PACs so monitoring and response priorities align to process risk.
- Where application-layer filtering is in scope, evaluate it separately from basic network allowlisting, consistent with the ATT&CK note that application-layer allowlist techniques are addressed under Filter Network Traffic.
Analyst notes and limits
The ATT&CK object is newly defined in the supplied data, has no specified tactics or platforms at the technique level, and does not include official detection guidance. The strongest relationship-driven context is the split between command-message and reporting-message blocking, the targeted ICS asset types, and the mitigations for network allowlists, out-of-band communications, and static network configuration.
This take is limited to the supplied ATT&CK STIX fields, references, and relationships. It does not assert active exploitation, actor attribution, sector exposure, or existing detection coverage. Local engineering knowledge is required to identify normal message timing, critical control paths, acceptable communication loss thresholds, and which assets can support the recommended mitigations.
Block Operational Technology Message
Adversaries may block messages between systems and devices in an OT/ICS environment to disrupt processes. Messages typically fall into two categories: (1) reporting messages that contain telemetry data about the current state of systems, devices, and processes and (2) command messages that contain instructions to control systems, devices, and processes. Both types of messages are critical for the proper functioning of industrial control processes and failure of the messages to reach their intended destinations could inhibit response functions or create an unsafe condition that could have physical impacts.[1][2]
Adversaries may block communications by either making modifications to software (System Firmware, Module Firmware, Hooking, and Rootkit) and services (Service Stop, Denial of Service) on systems and devices or by positioning themselves between systems and devices and intercepting and blocking 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 | T1691.002 | Reporting Message Sub-technique | Reporting Message subtechnique of this object. |
| ICS | T1691.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 | d3399b2f9153… |
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 T1691Open 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.