Live Active security incident? Get immediate response
MITRE ATT&CK® Detection Strategy

DET0912: Detection of Block Wi-Fi

DET0912 is a detection strategy for identifying attempts to block Wi-Fi communications in ICS environments. The business issue is not simply wireless avail...

ICSDET0912Detection StrategyObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

DET0912 is a detection strategy for identifying attempts to block Wi-Fi communications in ICS environments. The business issue is not simply wireless availability: Wi-Fi may carry command, reporting, or IT/OT communications, so loss or interference can affect operational visibility and response decisions. Because MITRE provides no official detection text or platform scope for this object, organizations should treat it as a prompt to verify whether wireless communications that support operational processes are monitored, baselined, and included in incident response playbooks.

Executive priority

Prioritize this where Wi-Fi supports operational technology, remote monitoring, command delivery, or safety-relevant reporting. Leaders should ask which operational functions depend on wireless connectivity, whether loss of Wi-Fi would degrade production or visibility, and whether SOC/OT teams have evidence to distinguish routine outages from deliberate blocking. The control decision value is in resilience planning: inventory critical wireless dependencies, define escalation paths, and ensure audit-ready evidence that communication-loss events are logged and investigated.

Technical view

This strategy detects the related ICS technique T1695.003, Wi-Fi, where adversaries may block Wi-Fi communications to prevent messages from reaching target systems and devices. SOC, OT, and incident response teams should validate telemetry for Wi-Fi availability, device association state, network interface status, service stoppage indicators where applicable, and gaps in expected command/reporting flows. Because the ATT&CK object does not specify platforms, tactics, or detection logic, local architecture must drive analytic design and thresholds.

Likely telemetry

  • Wireless controller or access point availability, association, authentication, and disassociation logs
  • Signal quality, interference, channel utilization, and radio health metrics where available
  • OT asset, gateway, or engineering workstation network interface status events
  • Service stop or communications-service health events where Wi-Fi connectivity depends on local services
  • Expected command, reporting, polling, or telemetry-flow heartbeat data between IT and OT systems

Detection direction

  • Baseline normal Wi-Fi availability and communications patterns for operationally important wireless segments before alerting on loss alone.
  • Correlate Wi-Fi disruption with affected OT command/reporting flows rather than treating every wireless outage as malicious.
  • Tune for context: maintenance, roaming, weak signal areas, power events, and access point failures can create false positives.
  • Validate whether monitoring covers both infrastructure-side indicators, such as access point/controller health, and endpoint-side indicators, such as disabled interfaces or service stoppage.
  • Create escalation logic for simultaneous loss of connectivity across multiple devices or operational cells, especially when it coincides with missed reporting or command failures.

Mitigation priorities

  • Inventory Wi-Fi dependencies that support ICS communications and classify which are operationally critical.
  • Ensure monitoring exists for wireless infrastructure health, endpoint connectivity state, and expected OT message flows.
  • Define incident response procedures for Wi-Fi loss that include OT operations, network teams, and SOC triage responsibilities.
  • Use change management and maintenance records to provide context for planned wireless interruptions.
  • Where operationally required, design resilience around critical communications paths rather than relying on a single wireless channel.
Analyst notes and limits

The ATT&CK relationship ties DET0912 to ICS technique T1695.003, Wi-Fi, focused on blocking Wi-Fi communications that may carry IT/OT messages, commands, or reporting. The most useful defensive work is validating observability and operational impact mapping, not assuming that any Wi-Fi outage is adversary activity.

The supplied ATT&CK object has no official description, no official detection text, no tactics, and no platform list. Recommendations are therefore conservative and derived only from the detection strategy name, external reference, and relationship to T1695.003. Local wireless architecture, OT process dependencies, and available logging are required to build reliable detections.

Official MITRE ATT&CK definition

Detection of Block Wi-Fi

No official description is available in the imported ATT&CK source object.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

Techniques used

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.

1 rows
Domain ID Name Relationship / procedure
ICS T1695.003 Wi-Fi Sub-technique This object detects Wi-Fi.
Relationship explorer

All related ATT&CK context

Change history

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 .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
9090dc61e329a781...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 9090dc61e329…
Raw source

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.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack DET0912
    Open source URL
Source and licensing

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.