T1691 Block Operational Technology Message: Detecting Blocked Command and Reporting Messages in OT

Block Operational Technology Message (T1691) is the technique where an adversary stops command or reporting messages from reaching the device or operator that needs them, so a control system cannot see or correct what the process is doing. MITRE ATT&CK for ICS v20 created T1691 in April 2026 under the Inhibit Response Function tactic (TA0107), for Embedded, Windows and Linux platforms, with two sub-techniques: Command Message (T1691.001) and Reporting Message (T1691.002). It replaces the earlier Block Command Message (T0803) and Block Reporting Message (T0804), which ATT&CK now marks as revoked. This guide is for OT security engineers, control engineers and SOC analysts who monitor industrial networks. It covers how blocking happens, the real cases ATT&CK records, the v20 detection analytics, the three ATT&CK mitigations and a safe response. For the tactic overview see the ATT&CK for ICS Inhibit Response Function Tactic Guide; this page goes deeper on one technique.

Key takeaways

• Two message types, two harms. Blocked command messages stop a device from acting on an instruction; blocked reporting messages stop operators and control logic from knowing the true state of the process.
• Blocking is an outcome, not one method. ATT&CK lists firmware changes, hooking, rootkits, service stops, denial of service and adversary-in-the-middle positions as ways to achieve it.
• The 2015 Ukraine attack is the reference case. ATT&CK records Sandworm Team rendering serial-to-Ethernet converters inoperable with malicious firmware, blocking both command and reporting messages.
• Silence is the signal. The v20 analytic looks for one traffic type ceasing while the device stays reachable, with no device alarm or maintenance window to explain it.
• Plan for the loss of the channel. ATT&CK's Out-of-Band Communications Channel mitigation (M0810) means operations can still send critical commands when the primary path is blocked.

What T1691 covers

ATT&CK describes OT messages in two categories: reporting messages, which carry telemetry about the current state of systems, devices and processes, and command messages, which carry instructions to control them. Failure of either to reach its destination can inhibit response functions or create an unsafe condition with physical impact. The technique belongs to Inhibit Response Function because its effect is to stop safety, protection and operator responses from working, even when the adversary does not change the process directly.

T1691 sits next to Block Communications (T1695), which ATT&CK v20 uses for blocking a communication channel such as a serial COM port, and next to Alarm Suppression (T0878), which targets alarms rather than ordinary messages. A blocked reporting message often pairs with Manipulation of View (T0832) in the same intrusion. Each has its own page; see the MITRE ATT&CK for ICS Guide for the matrix.

How messages get blocked

ATT&CK groups the methods into changes to software on the devices, changes to services, and interception between devices. The table maps each to the ICS technique ATT&CK links and to the place a defender would look.

The last row is worth noting: v20 analytics expect selective blocking, where a filter drops one ICS traffic type (for example command traffic) while leaving the rest working. That keeps the device looking healthy to basic availability checks.

Real cases recorded by ATT&CK

ATT&CK v20 records procedure examples on the sub-techniques. Both come from the Ukrainian power sector.

• 2015 Ukraine Electric Power Attack (C0028): ATT&CK records that Sandworm Team (G0034) blocked command messages and reporting messages by using malicious firmware to render serial-to-Ethernet converters inoperable, citing the E-ISAC and SANS ICS analysis. Every message that crossed those converters was lost, so the lesson is that small protocol converters are part of the control path. See the Sandworm Threat Actor Profile.
• Industroyer (S0604): ATT&CK records that Industroyer used the first COM port in its configuration for its own IEC 101 communication and opened the other two COM ports so other processes could not use them, letting its payload take over and keep control of the RTU while blocking command and reporting messages from legitimate software. ESET's analysis describes Industroyer as modular malware with payloads for IEC 60870-5-101, IEC 60870-5-104, IEC 61850 and OPC DA, and links it with high probability to the Kyiv outage of 17 December 2016. See the ICS Malware History Guide.

A related effect appeared in Poland: CERT Polska reported that on 29 December 2025 attackers damaged RTU firmware at wind and photovoltaic grid connection points, after which the stations lost communication with the distribution system operator and could not be controlled remotely, while generation continued. ATT&CK files that event under System Firmware (T1693.001) rather than T1691, but the operational result, losing the command and reporting path, is the same one this page is about.

Detection: ATT&CK v20 analytics

MITRE's detection strategy DET0903 has three analytics. All share an OT operational fidelity gate: alert only when the action cannot be attributed to an authorised operator or engineering source for that target and function, and falls outside an approved change or maintenance window or lacks change-control context; suppress activity that fully matches approved maintenance, commissioning, failover, recovery or tested procedures.

Making AN2213 work depends on knowing what normal looks like. For each master and outstation pair, record which protocols, which direction and roughly how often messages flow: polling intervals, unsolicited reporting, integrity polls. An OT network sensor can then alert when one type stops. Correlate with the alarm and event journal from the SCADA system, because many communication failures are genuine faults (a failed radio link, a stuck serial port) and operations will already have an alarm for them. The point is the unexplained gap. See the OT Network Security Monitoring Guide.

CISA's joint advisory on APT tools targeting ICS devices (AA22-103A) gives the operator-side version of the same idea: investigate symptoms such as communication delays, unexpected reboots or slow responses to operator commands, which may indicate denial of service or connection severing.

Prevention: the ATT&CK mitigations in practice

• M0807 Network Allowlists: ATT&CK's guidance for T1691 is to restrict unnecessary connections to network devices such as comm servers and serial-to-Ethernet converters, especially where devices limit the number of simultaneous sessions. A device that accepts only two sessions can be blocked by an attacker who takes both. See the Industrial Switch and Serial Gateway Hardening Guide.
• M0814 Static Network Configuration: statically define the hosts and ports used for automation protocol connections, so a new host cannot take over a session or redirect traffic unnoticed. Static ARP entries and fixed routes on critical segments follow the same principle.
• M0810 Out-of-Band Communications Channel: provide an alternative way to get critical commands to outstations, which ATT&CK says could include radio or cellular communication to a field technician who performs the control function by hand. CISA, FBI, EPA and DOE list the ability to operate OT systems manually among their primary OT mitigations.

Supporting controls come from the techniques that enable blocking: firmware integrity for converters and RTUs, host hardening and change control on SCADA servers (see the HMI and SCADA Server Hardening Guide), and segmentation so an adversary cannot easily reach a position between master and outstation (see the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide).

Where identity fits

Most blocking methods need privileged access somewhere: administrator rights on a SCADA host to change firewall rules, root on a Linux gateway, or a management login on a serial converter to load firmware. In 2015 the converters' management interfaces were the path. Give gateways and converters named accounts instead of shared vendor defaults, limit their management interfaces to engineering workstations, and log every rule or firmware change against a person and a ticket. See the OT and ICS Identity and Access Guide.

How to implement

1. Map the critical message paths. For each process area, list the master, the outstations, the protocol, the path (including converters, radios and gateways) and what happens to safety if the path is lost.
2. Baseline traffic per path. Use an OT network sensor in passive mode to record which message types flow, in which direction and at what rate, over at least one full operating cycle.
3. Turn on host telemetry. Enable firewall policy change auditing on Windows SCADA and DCS hosts and audit rules for iptables and nftables on Linux gateways, forwarded to central logging.
4. Deploy DET0903-style alerts in alert-only mode for a pilot area, tuned against the alarm journal and maintenance calendar so known faults and planned work are suppressed.
5. Apply allowlists and static configuration on converters, comm servers and protocol gateways during a planned outage, with the previous configuration saved for rollback.
6. Write and exercise the out-of-band procedure: who calls whom, which field actions are allowed by phone or radio instruction, and how they are logged.
7. Review quarterly with operations: alerts raised, how many were real faults, and whether the baselines still match the process.

Decision guidance

• Small sites: start with the SCADA alarm journal and a communications-failure alarm for every outstation, plus a written manual operation procedure. These catch blocking as a symptom even without a sensor.
• Utilities and multi-site operators: a passive OT monitoring platform with per-path baselines is the practical way to see selective blocking across many links.
• Serial and legacy links: where messages cross serial-to-Ethernet converters, the converter is the single point of failure. Prioritise its firmware integrity, management access and spares.
• Inline filtering: protocol-aware filters can protect paths, but a wrongly tuned filter will itself block valid messages. Run in monitor mode first and agree a bypass procedure with operations.

Responding when messages stop

Treat process safety first. Confirm with operations whether the affected area is in a safe state and whether to move to manual or out-of-band operation. Then establish whether the loss is a fault or an attack: check the alarm journal, recent maintenance, and whether other traffic types to the same device still flow. If the evidence points to an attack, preserve gateway and host firewall configurations, audit logs, converter configurations and firmware images, and network captures before changing anything. Contain by isolating the adversary's position (a rogue host, a compromised gateway) at the zone boundary rather than by power cycling field devices mid-process. Restore from known-good configurations and firmware, verify message flow against the baseline, and keep heightened monitoring for repeat attempts. Report to your national authority as your sector rules require. See the OT Incident Response Guide.

Detection and measurement

• Path baseline coverage: percentage of critical master to outstation paths with a recorded message baseline.
• Unexplained communication gaps: number of gaps per month without a matching alarm or maintenance record, and time to explain each.
• Change attribution: percentage of firewall, gateway and converter configuration changes linked to a change ticket.
• Allowlist coverage: percentage of converters and comm servers restricted to approved hosts.
• Out-of-band readiness: date of the last exercised manual or out-of-band operation per critical area.

Framework mapping

Common failure patterns

• Treating every communication loss as a fault: with no baseline or correlation, an attack looks like a bad radio day.
• Availability checks that only ping: a device that answers ping can still have its command traffic filtered.
• Converters left on default management access: serial-to-Ethernet devices are small, forgotten and were the path in the 2015 Ukraine attack.
• No tested manual procedure: an out-of-band channel that has never been exercised fails under pressure.
• Inline filters deployed straight to block mode: the defender causes the outage the technique describes.

Practitioner checklist

• List every critical master to outstation path, including converters, radios and gateways.
• Record a per-path baseline of message types, direction and rate.
• Audit firewall and packet filter changes on SCADA, DCS and gateway hosts.
• Alert on one traffic type stopping while the device stays reachable, correlated with alarms and maintenance.
• Restrict converters and comm servers to approved hosts and static configuration.
• Verify firmware on converters and RTUs and hold known-good images offline.
• Document and exercise an out-of-band and manual operation procedure.
• Write a response runbook that starts with process safety and preserves configurations before restoring.

Standards and references

• MITRE ATT&CK for ICS: Block Operational Technology Message (T1691)
• MITRE ATT&CK: Detection of Block Operational Technology Message (DET0903)
• 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, FBI, EPA and DOE: Primary Mitigations to Reduce Cyber Threats to Operational Technology
• ESET: Industroyer, Biggest Threat to Industrial Control Systems Since Stuxnet
• CERT Polska: Report on the December 2025 Attacks on the Polish Energy Sector

Related NHI Mgmt Group resources: ATT&CK for ICS Inhibit Response Function Tactic Guide · MITRE ATT&CK for ICS Guide · Industrial Switch and Serial Gateway Hardening Guide · OT Network Security Monitoring Guide · IEC 60870-5-104 Telecontrol Security Guide