T1695 Block Communications: Detection, Mitigation and Response

Block Communications (T1695) is an adversary stopping command and reporting messages from reaching the devices that need them, so operators cannot see or steer the process when it matters. MITRE ATT&CK for ICS v20 places T1695 under Inhibit Response Function (TA0107) for Embedded, Windows, Linux and Network Devices platforms, with three sub-techniques by medium: Serial COM (T1695.001), Ethernet (T1695.002) and Wi-Fi (T1695.003). It replaces the older Block Serial COM technique (T0805), which ATT&CK now shows as revoked in favour of T1695.001; blocking of individual command and reporting messages moved to Block Operational Technology Message (T1691). MITRE notes that OT traffic runs over serial, Ethernet, Wi-Fi, cellular and satellite links, and that blocking can be done by changing software and services on devices or by sitting between devices and dropping traffic. This guide is for OT security engineers, control engineers and OT SOC analysts: the procedure examples, the v20 analytics, and how to design communications so a block is noticed fast and the process stays safe. For the tactic overview see the ATT&CK for ICS Inhibit Response Function Tactic Guide.

Key takeaways

• The goal is loss of view and control, not data theft. Blocking reports hides an unsafe state; blocking commands stops operators correcting it.
• There are many ways to cause the same effect. ATT&CK names firmware changes, hooking, rootkits, service stops, denial of service and adversary-in-the-middle as routes to a block; detection should look for the effect as well as the cause.
• Real cases span all three media. Industroyer held serial ports open, LockerGoga disabled every network interface including Wi-Fi, and CyberAv3ngers locked operators out by changing a PLC's IP address.
• Correlation is the core analytic. ATT&CK v20 pairs network or firewall configuration changes from unapproved sources with communication-loss alarms in the same window.
• An independent channel is the main mitigation. Out-of-Band Communications Channel (M0810) sits beside Network Segmentation (M0930) and Network Allowlists (M0807).

What T1695 covers

Related techniques have their own pages: Service Stop (T0881), Denial of Service (T0814), Adversary-in-the-Middle (T0830), Rootkit (T0851) and Modify Firmware (T1693) can all be the mechanism behind a block. Map the block to T1695 and the mechanism to its own ID.

What real cases show

• Industroyer, 2016: ATT&CK records that the IEC 101 payload used the first configured COM port for communication and opened the other two only to stop other processes reaching them, so it could take over and keep control of the RTU. ESET's analysis links Industroyer to the December 2016 outage in part of Kyiv. See the Sandworm Threat Actor Profile and the ICS Malware History Guide.
• 2015 Ukraine Electric Power Attack: ATT&CK records Sandworm Team overwriting serial-to-Ethernet converter firmware, leaving downstream serial devices hard or impossible to reach.
• LockerGoga, 2019: ATT&CK records the ransomware disabling all network interfaces. Dragos describes the Norsk Hydro variant forcing a reboot after disabling network connectivity and changing credentials, and Hydro moving affected production systems to manual control.
• 2025 Poland energy sector attacks: CERT Polska reports that damage to RTUs left stations unable to communicate with the distribution system operator and unable to be controlled remotely, while electricity production continued.
• CyberAv3ngers: ATT&CK records the group locking operators out by changing a PLC's IP address during what ATT&CK calls the 2026 Iranian Water Campaign. See the CyberAv3ngers Threat Actor Profile.

Detection: ATT&CK v20 analytics

ATT&CK gives T1695 the detection strategy DET0910, which synthesises the three sub-techniques, and separate strategies for each medium (DET0797 Serial COM, DET0911 Ethernet, DET0912 Wi-Fi). Each analytic alerts only when the change is not attributable to an authorised operator or engineering source and falls outside an approved change window.

Practical additions that follow from the procedure examples: alert when a controller's IP address or network settings change outside a change window, watch serial device servers for a single client holding every port open, and treat an interface-down event on an HMI or engineering workstation as an OT alarm, not only an IT ticket. See the OT Network Security Monitoring Guide.

Prevention: ATT&CK mitigations in practice

Configuration control on the network itself matters as much: protect switch, firewall and serial server management interfaces with individual accounts, and keep known-good configurations so a malicious change can be reverted quickly.

Where identity fits

Most block methods need privileged access to a network device, gateway, controller setting or host firewall. The accounts that can change those settings, including shared switch logins and service accounts on polling servers, are the identities to restrict and monitor. Default or hardcoded credentials on communication devices are a recurring entry point; see the OT and ICS Identity and Access Guide.

How to implement

1. Map critical communication paths. For each safety-relevant or production-critical loop, record the medium, every hop (switch, serial server, radio, cellular modem) and the management interface of each hop.
2. Define loss-of-communication behaviour. With process engineers, confirm what each controller does on communication loss (hold last state, fail safe) and that operators get a clear alarm.
3. Add or test the out-of-band path for the alarms and commands operators need during an upset, and test it on a schedule.
4. Lock down configuration rights on network devices, serial servers and controller network settings; log every change centrally.
5. Deploy the correlation analytic in monitor-only mode first, tune against planned changes, then promote to alerting.
6. Rehearse response with operations: manual operation, reverting a network configuration and restoring a converter or gateway from a known-good image. Rollback for any new allowlist is the previous configuration saved before change.

Responding to a communication block

• Process safety first: operations decide whether to move to manual or local control; security supports that decision.
• Find the break: compare which devices went silent and when against recent configuration changes, interface events and device reboots.
• Preserve evidence: collect network device configuration and logs, firewall rule history, serial server session tables and firmware images before reverting where safe.
• Restore: revert to known-good configurations or images, then verify polling and alarms end to end before returning to remote control. See the OT Incident Response Guide.

Decision guidance

• Small sites: start with a tested manual fallback and a simple out-of-band alarm path; centralised correlation may be beyond reach.
• Large or distributed estates: remote substations and lift stations depend on cellular and radio links; monitor link health centrally and alert on simultaneous loss across many sites.
• Redundancy versus independence: a second network path managed by the same accounts and devices can be blocked the same way; an out-of-band channel should not share management or credentials with the primary.

Detection and measurement

• Percentage of critical communication paths with a tested out-of-band channel.
• Percentage of network and serial devices whose configuration changes are logged centrally.
• Mean time from first communication-loss alarm to identifying the cause.
• Unapproved network configuration changes detected per quarter, and how many matched a change ticket after review.
• Time to restore polling from a known-good configuration in exercises.

Framework mapping

Common failure patterns

• Treating comms loss as a maintenance fault: a silent RTU is ticketed to telecoms and nobody checks for a configuration change.
• Serial servers left out of scope: converters were targets in both Ukraine 2015 (firmware overwritten) and the 2025 Poland attacks (ATT&CK records default credentials used on serial device servers), yet they are often missing from inventories and change logging.
• Redundant paths with shared management: both paths fail together when the same switch credentials are abused.
• IT ransomware on OT hosts: LockerGoga showed that commodity malware disabling interfaces can cut an HMI off without targeting OT at all.
• No tested manual fallback: when communications drop, operators cannot run the process locally for long enough to recover.

Practitioner checklist

• Document every critical communication path and its management interfaces.
• Confirm and test loss-of-communication behaviour for safety-relevant controllers.
• Provide an independent out-of-band path for critical alarms and commands.
• Restrict serial servers and switches to named polling hosts.
• Log and alert on network, firewall and controller IP changes outside change windows.
• Correlate configuration changes with communication-loss alarms.
• Keep known-good configurations and firmware for network and serial devices.
• Exercise manual operation and restore with operations at least yearly.

Standards and references

• MITRE ATT&CK: Block Communications (T1695)
• MITRE ATT&CK: Serial COM (T1695.001)
• MITRE ATT&CK: Ethernet (T1695.002)
• NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
• CERT Polska: Energy Sector Incident Report
• ESET: Industroyer, Biggest Threat to Industrial Control Systems Since Stuxnet
• Dragos: Spyware Stealer Locker Wiper, LockerGoga Revisited

Related NHI Mgmt Group resources: ATT&CK for ICS Inhibit Response Function Tactic Guide · OT Network Security Monitoring Guide · OT Incident Response Guide · OT Cyber Physical Risk and Safety Guide