T1695.003: Wi-Fi
Adversaries may block access to Wi-Fi communications to prevent messages from reaching target systems and devices. Wi-Fi connections allow for communications between IT and OT systems and devices. Blocking Wi-Fi communications may also block command and reporting messages.[1]
An adversary may block Wi-Fi communications by disabling network interfaces, Service Stop, conducting an Adversary-in-the-Middle attack and dropping the network traffic, or by jamming the Wi-Fi signal.
Analyst context for executives and security teams
Wi-Fi communication blocking matters in ICS because it can interrupt the messages operators and systems rely on for command, reporting, telemetry, and situational awareness. If Wi-Fi is part of the path between IT and OT devices, a loss of that channel can look like a network outage while still creating operational and potentially cyber-physical risk.
Executive priority
Prioritize this as an operational resilience issue, not just a wireless security issue. Leaders should ask which critical ICS functions depend on Wi-Fi, whether loss of Wi-Fi affects operator visibility or control, and whether alternate communications and response procedures are tested. The ATT&CK relationships point to broad ICS asset relevance, including HMIs, PLCs, RTUs, IEDs, historians, control servers, gateways, safety controllers, VPN servers, jump hosts, routers, switches, and firewalls.
Technical view
SOC, detection engineering, and IR teams should validate whether DET0912, Detection of Block Wi-Fi, is implemented or mapped to local monitoring. Since the official object provides no detection text and no platform/tactic metadata, coverage should be proven through local evidence: wireless infrastructure logs, endpoint interface and service state, network traffic loss between ICS assets, and operational application symptoms such as missing command or reporting messages. Investigations should distinguish adversary-caused blocking from maintenance, weak signal, equipment failure, environmental interference, or planned network changes. Relationship context also links LockerGoga to this technique, but that should be treated as contextual threat intelligence rather than evidence of activity in any environment.
Likely telemetry
- Wi-Fi access point, controller, and wireless infrastructure availability logs
- Client association/disconnection and connectivity state from Wi-Fi-connected ICS or support systems
- Endpoint network interface status and service stop/start events where available
- Network flow, packet capture, or communications health data showing dropped or missing traffic between IT/OT systems
- RF spectrum or interference monitoring data where jamming risk is relevant
Detection direction
- Confirm whether local detection logic corresponds to DET0912 and whether it can identify blocked Wi-Fi communications rather than only device outages.
- Correlate Wi-Fi loss with endpoint interface changes, service stops, traffic drops, and ICS application communication gaps.
- Baseline normal command and reporting cadence for Wi-Fi-dependent assets so missed messages are visible quickly.
- Tune for benign causes such as planned maintenance, roaming behavior, signal degradation, device replacement, or environmental interference.
- Address blind spots on embedded devices and field assets that may not produce rich endpoint logs.
Mitigation priorities
- Identify and document which ICS assets and functions depend on Wi-Fi communications.
- Implement and test out-of-band communications channels for critical command, reporting, and response requirements, consistent with M0810.
- Use network segmentation to isolate critical systems and limit unnecessary access paths, consistent with M0930.
- Apply network allowlists for required device communications such as IP address, MAC address, port, and protocol where appropriate, consistent with M0807.
- Include Wi-Fi communication loss scenarios in incident response, business continuity, and OT operations exercises.
Analyst notes and limits
This is an ICS sub-technique of Block Communications focused specifically on Wi-Fi. The supplied ATT&CK description lists several blocking mechanisms: disabling network interfaces, Service Stop, adversary-in-the-middle traffic dropping, and jamming. The relationship set indicates many ICS asset types may be targeted, so local architecture is the deciding factor for risk and monitoring priority.
Official detection content, tactics, and platforms are not provided for this object. The guidance above is therefore based on the official description, external references, and stated relationships only. Actual exposure, impact, and detection quality require validation against the organization’s Wi-Fi design, ICS asset inventory, logging coverage, and operational dependency mapping.
Wi-Fi
Adversaries may block access to Wi-Fi communications to prevent messages from reaching target systems and devices. Wi-Fi connections allow for communications between IT and OT systems and devices. Blocking Wi-Fi communications may also block command and reporting messages.[1]
An adversary may block Wi-Fi communications by disabling network interfaces, Service Stop, conducting an Adversary-in-the-Middle attack and dropping the network traffic, or by jamming the Wi-Fi signal.
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 | 0ceb559fa8cc… |
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.003Open 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.