T1695: Block Communications
Operational technology communications occur over serial COM, Ethernet, Wi-Fi, cellular (4G/5G), and satellite mediums. Adversaries may block communications to prevent reporting messages and command messages from reaching their intended target devices disrupting processes, operations, and causing cyber-physical impacts.[1]
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
Block Communications is an ICS technique where an adversary prevents command or reporting messages from reaching operational technology devices over serial, Ethernet, Wi-Fi, cellular, or satellite communications. The business issue is not just network downtime: blocked OT communications can leave operators blind, prevent control actions, interrupt production, and create cyber-physical risk where HMIs, PLCs, RTUs, IEDs, safety controllers, gateways, routers, switches, firewalls, VPN servers, jump hosts, and historians are part of the control path.
Executive priority
Treat this as an operational resilience and safety-relevant scenario. Leaders should ask whether critical control paths have documented dependencies, whether loss of communications has tested fallback procedures, and whether segmentation, allowlisting, and out-of-band communications are implemented where disruption would affect safety, production, or compliance evidence. This technique is especially material for incident response planning because responders may need to distinguish malicious blocking from equipment failure, service stoppage, network misconfiguration, or degraded communications media.
Technical view
ATT&CK does not provide official detection text for T1695, but the relationship set includes DET0910, Detection of Block Communications, and mitigations for Network Allowlists, Out-of-Band Communications Channel, and Network Segmentation. SOC and OT defenders should validate visibility across the communications paths that support command and reporting traffic, including the subtechnique areas Serial COM, Ethernet, and Wi-Fi. Because the technique can involve firmware modification, hooking, rootkit behavior, service stopping, denial of service, or adversary-in-the-middle positioning, investigation should correlate endpoint/device state, network path health, service status, and expected OT protocol flows rather than relying on a single alert type.
Likely telemetry
- OT network flow records and packet captures for expected command/reporting paths
- Serial COM availability, converter status, and device communication logs where available
- Ethernet interface status, link-state changes, switch/router/firewall events, and access-control decisions
- Wi-Fi association, deauthentication, signal/interference, and access point logs where OT Wi-Fi is used
- Service start/stop and process health logs on workstations, HMIs, control servers, application servers, gateways, jump hosts, and VPN servers
Detection direction
- Baseline normal command and reporting flows between control servers, HMIs, RTUs, PLCs, IEDs, data gateways, historians, and network infrastructure, then alert on unexpected loss, one-way failure, or stale telemetry.
- Correlate communications loss with local service stoppage, interface disablement, firewall or allowlist changes, network device events, and device health to reduce false positives from maintenance or equipment faults.
- Validate coverage separately for Serial COM, Ethernet, and Wi-Fi paths; blind spots often appear where legacy serial links, converters, embedded devices, or unmanaged network segments lack logging.
- Use relationship context from DET0910 as a starting point, but confirm locally that detection content maps to the actual ICS architecture and critical process dependencies.
- Tune detections with operations teams so planned outages, engineering changes, and failover tests do not create excessive noise while still preserving evidence for incident response.
Mitigation priorities
- Prioritize network segmentation for critical process control systems and restrict access to only required systems and services, especially across enterprise-to-ICS boundaries.
- Implement network allowlists for permitted IP addresses, MAC addresses, ports, and protocols where supported; pair this with change control so unauthorized connectivity changes are visible.
- Establish and test out-of-band communications channels for communication failures and data integrity events affecting critical operations.
- Document critical communications dependencies and recovery procedures for targeted assets such as HMIs, PLCs, RTUs, IEDs, control servers, historians, gateways, VPN servers, jump hosts, routers, switches, firewalls, safety controllers, and field I/O.
- Include communication-blocking scenarios in tabletop and technical exercises so SOC, IR, engineering, and operations teams can distinguish cyber activity from normal operational faults.
Analyst notes and limits
This object is an ICS ATT&CK technique, T1695, with no ATT&CK tactics or object-level platforms specified. The relationship data is broad and targets many ICS asset types, indicating that coverage decisions should be asset- and architecture-driven. The strongest defensible emphasis is on resilience of command/reporting paths, communications telemetry, segmentation, allowlisting, and alternative communications.
Official ATT&CK detection guidance is not provided for this object, and the supplied DET0910 relationship does not include detection logic details. No active exploitation, actor attribution, sector prevalence, or guaranteed detection coverage is supplied. Local architecture, communications media, OT protocols, and logging capabilities are required to determine practical exposure and control effectiveness.
Block Communications
Operational technology communications occur over serial COM, Ethernet, Wi-Fi, cellular (4G/5G), and satellite mediums. Adversaries may block communications to prevent reporting messages and command messages from reaching their intended target devices disrupting processes, operations, and causing cyber-physical impacts.[1]
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.
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 | cfdd18aff715… |
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 T1695Open 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.