T0813: Denial of Control
Adversaries may cause a denial of control to temporarily prevent operators and engineers from interacting with process controls. An adversary may attempt to deny process control access to cause a temporary loss of communication with the control device or to prevent operator adjustment of process controls. An affected process may still be operating during the period of control loss, but not necessarily in a desired state. [1] [2] [3]
In the 2017 Dallas Siren incident operators were unable to disable the false alarms from the Office of Emergency Management headquarters. [4]
Analyst context for executives and security teams
Denial of Control matters because it can leave operators and engineers unable to adjust or regain control of an active industrial or public-safety process. The process may keep running, but not necessarily in the intended or safe state. For leaders, this is an operational resilience issue: the key question is whether the organization can keep communicating, make safe decisions, and recover control when normal control paths fail.
Executive priority
Prioritize this for environments where temporary loss of control could affect safety, public services, production, utilities, or emergency response. ATT&CK cites the 2017 Dallas Siren incident, where operators could not disable false alarms from headquarters, and relationships include the Maroochy Water Breach and Ukraine electric power attack campaigns. Executives should ask whether critical processes have alternate communication paths, redundant services, exercised recovery plans, and evidence that SOC/IR teams can recognize loss-of-control conditions quickly.
Technical view
ATT&CK provides no official detection text, platforms, or tactics for T0813, but it links a detection strategy named DET0786, Detection of Denial of Control. SOC and IR teams should validate monitoring around loss of operator-to-control-device communication, inability to issue or confirm process control changes, abnormal controller/service availability, and discrepancies between expected operator actions and process response. Detection engineering should treat this as an ICS availability/control-integrity condition rather than only a conventional endpoint alert.
Likely telemetry
- ICS/HMI and engineering workstation event logs showing operator commands, failed control attempts, session loss, or command timeouts
- Controller, RTU, PLC, or control service status and availability indicators where collected
- Network flow and protocol telemetry between operator workstations, control servers, and control devices
- Alarm, historian, and process event records showing continued process operation without expected operator adjustment
- Communications failure logs and records from out-of-band operational channels
Detection direction
- Confirm whether DET0786 or local detection content covers temporary loss of control, not just complete device outage.
- Correlate operator command attempts with device acknowledgements and process state changes; a command issued without expected response may be more meaningful than a single network alert.
- Tune for maintenance windows, planned failovers, network work, and known control-system latency to reduce false positives.
- Look for blind spots where ICS networks are segmented but not monitored, where HMI logs are not centralized, or where process historians are treated as operational-only data.
- Use relationship context from Maroochy Water Breach, the 2015 Ukraine Electric Power Attack, and Industroyer as validation prompts for incident playbooks, not as proof of current exposure.
Mitigation priorities
- Establish and exercise out-of-band communications channels for communication failures and data-integrity attacks, consistent with M0810.
- Provide redundancy for critical ICS devices and services, including backup devices or hot-standby approaches where appropriate, consistent with M0811.
- Maintain hardened, separated backups and gold-copy images/configurations for key systems, and exercise incident response plans for recovery from loss of control, view, or availability, consistent with M0953.
- Test operational decision-making during control loss: who can declare a safe state, how operators communicate, and how recovery is verified before returning to normal operations.
Analyst notes and limits
This take is based on ATT&CK T0813 Denial of Control, its official description, external references, and stated relationships. The most decision-useful point is not the adversary mechanism, which is not specified here, but the resilience gap created when operators cannot interact with process controls during an active condition.
ATT&CK does not provide official detection guidance, tactics, platforms, aliases, or labels for this object. Local engineering diagrams, control-system architecture, logging coverage, safety procedures, and incident response evidence are required to determine actual risk and detection coverage.
Denial of Control
Adversaries may cause a denial of control to temporarily prevent operators and engineers from interacting with process controls. An adversary may attempt to deny process control access to cause a temporary loss of communication with the control device or to prevent operator adjustment of process controls. An affected process may still be operating during the period of control loss, but not necessarily in a desired state. [1] [2] [3]
In the 2017 Dallas Siren incident operators were unable to disable the false alarms from the Office of Emergency Management headquarters. [4]
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]
C0028: 2015 Ukraine Electric Power Attack
2015 Ukraine Electric Power Attack was a Sandworm Team campaign during which they used BlackEnergy (specifically BlackEnergy3) and KillDisk to target and disrupt transmission and distribution substations within the Ukrainian power grid. This campaign was the first major public attack conducted against the Ukrainian power grid by Sandworm Team.
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 | 5ef52a93413d… |
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]
Mark Loveless April 2017
Mark Loveless 2017, April 11 THE DALLAS COUNTY SIREN HACK Retrieved. 2020/11/06
Open source URL -
[5]
mitre-attack T0813Open 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.