T1695.002: Ethernet
Adversaries may block access to Ethernet communications to prevent instructions or configurations messages from reaching target systems and devices. Ethernet connections allow for communications between IT and OT systems and devices. Blocking Ethernet communications may also block command and reporting messages.[1]
An adversary may block Ethernet communications by disabling network interfaces, Service Stop, or conducting an Adversary-in-the-Middle attack and dropping the network traffic.
Analyst context for executives and security teams
Ethernet blocking in ICS is material because it can prevent commands, configuration changes, telemetry, alarms, and reporting messages from moving between IT, OT, and field devices. For leaders, the issue is not just “network outage”; it is whether operators can still see and control the process when Ethernet paths are disabled, interrupted, or traffic is dropped.
Executive priority
Prioritize this where business operations depend on Ethernet-connected HMIs, PLCs, RTUs, control servers, historians, gateways, switches, routers, firewalls, VPN servers, jump hosts, or safety-related controllers. The executive question is whether the organization has evidence that critical OT communications are segmented, allowlisted where appropriate, monitored for loss or dropping, and supported by out-of-band communication options for failure scenarios.
Technical view
ATT&CK provides no official detection text for T1695.002, but the relationship to DET0911 indicates a detection strategy exists for Block Ethernet. SOC and IR teams should validate visibility around loss of Ethernet communications, disabled network interfaces, service stops related to communications, and adversary-in-the-middle conditions where traffic may be dropped. Because this is an ICS sub-technique of Block Communications, detection should be tested against command-message loss, telemetry/reporting gaps, and abnormal communication failures across the related ICS assets.
Likely telemetry
- Network device logs from switches, routers, firewalls, and gateways
- Interface status and link-state changes on hosts and network devices
- OT network traffic metadata showing dropped, missing, or interrupted communications
- HMI, control server, historian, RTU, PLC, IED, PAC, DCS controller, and safety controller communication/alarm logs where available
- Service status logs related to communication services
Detection direction
- Confirm whether DET0911 or local analytics identify Ethernet communication blocking rather than only generic device-down events.
- Tune for correlated loss of command and reporting messages between known OT peers, not just high-volume network outages.
- Validate coverage for disabled interfaces, stopped communication services, and traffic dropping consistent with adversary-in-the-middle behavior.
- Account for false positives from maintenance windows, cabling faults, switch changes, segmentation changes, and planned service restarts.
- Map detections to the specific ICS assets in scope, especially HMIs, PLCs, RTUs, control servers, historians, gateways, switches, routers, firewalls, VPN servers, jump hosts, and safety-related controllers.
Mitigation priorities
- Use network segmentation to isolate critical systems, functions, and resources and restrict access to required systems and services.
- Implement network allowlists where feasible using permitted IP addresses, MAC addresses, ports, and protocols for device communications.
- Establish out-of-band communication channels to support operational communication requirements during failures or data integrity attacks.
- Document and test incident procedures for loss of Ethernet communications affecting operator visibility, command paths, telemetry, alarms, and remote access.
Analyst notes and limits
The relationship set is broad: this sub-technique targets many ICS asset classes and is mitigated by Network Allowlists, Out-of-Band Communications Channel, and Network Segmentation. LockerGoga is listed as software using this object, but the supplied data does not justify broader attribution or active-exploitation claims.
ATT&CK does not specify tactics, platforms, aliases, or official detection guidance for this object. Local architecture, process criticality, network paths, and available OT telemetry are required to determine actual exposure and detection coverage.
Ethernet
Adversaries may block access to Ethernet communications to prevent instructions or configurations messages from reaching target systems and devices. Ethernet connections allow for communications between IT and OT systems and devices. Blocking Ethernet communications may also block command and reporting messages.[1]
An adversary may block Ethernet communications by disabling network interfaces, Service Stop, or conducting an Adversary-in-the-Middle attack and dropping the network traffic.
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 | T1695 | Block Communications | This object subtechnique of Block Communications. |
Groups, software, and campaigns
S0372: LockerGoga
LockerGoga is ransomware that was first reported in January 2019, and has been tied to various attacks on European companies, including industrial and manufacturing firms.[1][2]
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 | 278461955c7f… |
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 T1695.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.