T0815: Denial of View
Adversaries may cause a denial of view in attempt to disrupt and prevent operator oversight on the status of an ICS environment. This may manifest itself as a temporary communication failure between a device and its control source, where the interface recovers and becomes available once the interference ceases. [1] [2] [3]
An adversary may attempt to deny operator visibility by preventing them from receiving status and reporting messages. Denying this view may temporarily block and prevent operators from noticing a change in state or anomalous behavior. The environment's data and processes may still be operational, but functioning in an unintended or adversarial manner.
Analyst context for executives and security teams
Denial of View matters because ICS operators can lose trustworthy visibility into plant or process status while the environment may still be running, possibly in an unintended or adversarial state. For leaders, the core issue is not only system availability; it is whether operators and responders have independent ways to know what is happening when normal control-room views, status messages, or reporting paths fail.
Executive priority
Treat this as an operational resilience and safety-relevant visibility problem. Executives should ask whether critical processes can be monitored and coordinated during communication failures or data integrity attacks, whether redundant services and out-of-band communications exist, and whether recovery plans include tested gold-copy configurations for key ICS systems. ATT&CK links this behavior to ICS incidents/software context, including Maroochy Water Breach and Industroyer, so it should inform tabletop exercises and evidence for continuity and incident response readiness.
Technical view
SOC, OT, and IR teams should validate how they would identify a loss or degradation of operator view when the underlying process may continue operating. Because the ATT&CK object does not specify platforms or tactics and provides no official detection text, detection engineering should start from local ICS architecture: normal status/reporting message flows, device-to-control-source communications, HMI/operator interface health, and discrepancies between displayed state and independent process indicators. The related DET0769 strategy indicates detection content exists for Denial of View, but its detailed logic is not supplied here, so teams should not assume coverage without reviewing local telemetry and rule behavior.
Likely telemetry
- ICS status and reporting messages between devices and control sources
- HMI/operator interface availability and communication health events
- Network telemetry showing interruptions, loss, or degradation of ICS communications
- Independent process or device state indicators that can be compared against operator displays
- Logs and configuration records from critical servers, engineering systems, and end-user systems supporting control or view
Detection direction
- Validate alerts for temporary communication failure or loss of reporting paths that affect operator oversight, not just complete outages.
- Correlate operator interface loss with independent device/process state where available to identify visibility gaps or state discrepancies.
- Tune for expected maintenance, planned network changes, and transient reliability issues to reduce false positives while preserving escalation for critical assets.
- Do not limit scoping to a single platform; the technique has no specified platforms, although one related software object, Industroyer, is listed with Windows.
- Use the Maroochy Water Breach and Industroyer relationships as exercise context, not as proof of current activity in any environment.
Mitigation priorities
- Prioritize out-of-band communications channels so operators and responders can coordinate during communication failures or data integrity attacks.
- Provide redundancy for critical ICS devices and services, including backup devices or hot-standby capabilities where appropriate.
- Maintain hardened, separated backups for end-user systems and critical servers that support control, view, or availability.
- Exercise incident response plans, including restoration from gold-copy images and configurations for key systems.
- Confirm that continuity plans address loss of view specifically, not only loss of control or loss of availability.
Analyst notes and limits
This Glexia take is based only on the supplied ATT&CK technique T0815, its external references, and listed relationships. The object describes adversaries disrupting operator visibility by blocking status and reporting messages; it does not provide a tactic, platform list, or official detection procedure. Defensive value therefore depends heavily on local OT architecture, communications design, and available independent process visibility.
No active exploitation, customer exposure, attribution, or guaranteed detection coverage can be concluded from the supplied fields. Detection detail for DET0769 is not provided, and platform information is absent for the technique itself. Local validation is required to determine which systems, logs, and process indicators can actually evidence Denial of View.
Denial of View
Adversaries may cause a denial of view in attempt to disrupt and prevent operator oversight on the status of an ICS environment. This may manifest itself as a temporary communication failure between a device and its control source, where the interface recovers and becomes available once the interference ceases. [1] [2] [3]
An adversary may attempt to deny operator visibility by preventing them from receiving status and reporting messages. Denying this view may temporarily block and prevent operators from noticing a change in state or anomalous behavior. The environment's data and processes may still be operational, but functioning in an unintended or adversarial manner.
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.
Groups, software, and campaigns
S0604: Industroyer
Industroyer is a sophisticated malware framework designed to cause an impact to the working processes of Industrial Control Systems (ICS), specifically components used in electrical substations.[1] Industroyer was used in the attacks on the Ukrainian power grid in December 2016.[2] This is the first publicly known malware specifically designed to target and impact operations in the electric grid.[3]
C0020: Maroochy Water Breach
Maroochy Water Breach was an incident in 2000 where an adversary leveraged the local government’s wastewater control system and stolen engineering equipment to disrupt and eventually release 800,000 liters of raw sewage into the local community.[1]
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.1 | Current bundle | a78ff9ffbaa3… |
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]
Corero
Corero Industrial Control System (ICS) Security Retrieved. 2019/11/04
Open source URL -
[2]
Michael J. Assante and Robert M. Lee
Michael J. Assante and Robert M. Lee SANS Industrial Control System (ICS) Security; The Industrial Control System Cyber Kill Chain Retrieved 2024/11/25
Open source URL -
[3]
Tyson Macaulay
Tyson Macaulay Michael J. Assante and Robert M. Lee Corero Industrial Control System (ICS) Security Retrieved. 2019/11/04 The Industrial Control System Cyber Kill Chain Retrieved. 2019/11/04 RIoT Control: Understanding and Managing Risks and the Internet of Things Retrieved. 2019/11/04
Open source URL -
[4]
mitre-attack T0815Open 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.