T0814: Denial of Service
Adversaries may perform Denial-of-Service (DoS) attacks to disrupt expected device functionality. Examples of DoS attacks include overwhelming the target device with a high volume of requests in a short time period and sending the target device a request it does not know how to handle. Disrupting device state may temporarily render it unresponsive, possibly lasting until a reboot can occur. When placed in this state, devices may be unable to send and receive requests, and may not perform expected response functions in reaction to other events in the environment.
Some ICS devices are particularly sensitive to DoS events, and may become unresponsive in reaction to even a simple ping sweep. Adversaries may also attempt to execute a Permanent Denial-of-Service (PDoS) against certain devices, such as in the case of the BrickerBot malware. [1]
Adversaries may exploit a software vulnerability to cause a denial of service by taking advantage of a programming error in a program, service, or within the operating system software or kernel itself to execute adversary-controlled code. Vulnerabilities may exist in software that can be used to cause a denial of service condition.
Adversaries may have prior knowledge about industrial protocols or control devices used in the environment through Remote System Information Discovery. There are examples of adversaries remotely causing a Device Restart/Shutdown by exploiting a vulnerability that induces uncontrolled resource consumption. [2] [3] [4]
Analyst context for executives and security teams
Denial of Service in ICS matters because an attacker does not need to change process logic to create operational risk; making an HMI, PLC, RTU, controller, historian, gateway, firewall, switch, or safety-related device unresponsive can interrupt monitoring, command delivery, telemetry collection, or response functions. The ATT&CK description highlights that some ICS devices may be sensitive even to simple network activity, and that vulnerabilities such as uncontrolled resource consumption can produce DoS or even permanent denial-of-service conditions.
Executive priority
Treat this as an operational resilience and safety-adjacent availability risk, not only a network security issue. Leaders should ask which control-system assets are most critical to continued operations, whether those assets have known DoS-sensitive vulnerabilities, whether recovery requires reboot or replacement, and whether the organization can prove monitoring and incident response coverage for ICS availability events. Budget priority should favor segmentation, vulnerability prioritization for exposed or fragile control assets, tested recovery procedures, and engineering controls such as watchdog timers where appropriate.
Technical view
SOC, detection engineering, and IR teams should validate visibility around abnormal request volume, malformed or unexpected protocol requests, device unresponsiveness, restart/shutdown symptoms, and loss of expected telemetry across the ICS assets named in ATT&CK relationships: HMI, PLC, RTU, IED, historian, control server, data gateway, safety controller, jump host, field I/O, switch, firewall, DCS controller, and PAC. ATT&CK provides a related detection strategy, DET0723, but no detection text in the object, so local detection content must be derived from asset behavior baselines, network monitoring, device diagnostics, and vendor advisories. Historical ATT&CK relationships to campaigns and software such as the 2015 Ukraine Electric Power Attack, Unitronics Defacement Campaign, Industroyer, PLC-Blaster, Backdoor.Oldrea, and Fuxnet make this a credible technique to model, without implying current activity in any environment.
Likely telemetry
- ICS network traffic metadata and packet/protocol observations showing request spikes, repeated connection attempts, malformed requests, or unexpected scanning behavior
- Device heartbeat, watchdog, availability, and health-state telemetry from controllers, field devices, HMIs, servers, and network equipment
- HMI, control server, historian, gateway, jump host, firewall, and switch logs where available
- PLC, RTU, IED, safety controller, DCS controller, PAC, and field I/O diagnostic events or engineering workstation observations
- Restart, shutdown, loss-of-communication, timeout, alarm, and telemetry-gap records
Detection direction
- Validate DET0723-aligned coverage against local ICS architecture, since the ATT&CK object does not provide detailed detection logic.
- Baseline normal polling rates, command patterns, protocol use, and device response behavior; alert on deviations that correlate with device degradation or loss of telemetry.
- Tune carefully for engineering activity, maintenance windows, legitimate scans, backups, failover testing, and vendor support activity, which may resemble high-volume or unusual requests.
- Prioritize monitoring at choke points and critical dependencies: firewalls, switches, data gateways, jump hosts, control servers, historians, HMIs, and network paths to PLCs/RTUs/IEDs/controllers.
- Correlate network anomalies with operational symptoms such as unresponsive devices, missed heartbeats, process alarm changes, or restart/shutdown events to reduce noisy network-only alerts.
Mitigation priorities
- Identify critical ICS assets and rank them by operational consequence if they become unresponsive.
- Use vulnerability management to prioritize DoS-related weaknesses on exposed or highly critical control-system components, including resource-consumption vulnerabilities referenced by CWE-400-style conditions.
- Apply segmentation and traffic restriction so only required systems can send required traffic to sensitive ICS devices and services.
- Implement or validate watchdog timers where suitable, consistent with MITRE mitigation M0815, so devices can detect unresponsive states quickly.
- Establish tested recovery playbooks for reboot, failover, service restoration, and device replacement scenarios, including cases where a device cannot recover without physical intervention.
Analyst notes and limits
This technique is broad and asset-centric. Its business value comes from mapping DoS scenarios to actual plant, utility, manufacturing, or facility operations: which devices can be overwhelmed, what function is lost, how quickly operators notice, and how long restoration takes. Relationship context shows many ICS asset classes can be targets and that ATT&CK links the technique to named campaigns and software, but environment-specific exposure depends on local architecture, vendors, firmware, protocols, and monitoring maturity.
The ATT&CK object does not specify tactics, platforms for the technique itself, or official detection text. Detection and control recommendations therefore must be validated against local ICS asset inventories, vendor documentation, network designs, maintenance practices, and safety/operations requirements. No claim is made that any specific organization is exposed, currently targeted, or already has detection coverage.
Denial of Service
Adversaries may perform Denial-of-Service (DoS) attacks to disrupt expected device functionality. Examples of DoS attacks include overwhelming the target device with a high volume of requests in a short time period and sending the target device a request it does not know how to handle. Disrupting device state may temporarily render it unresponsive, possibly lasting until a reboot can occur. When placed in this state, devices may be unable to send and receive requests, and may not perform expected response functions in reaction to other events in the environment.
Some ICS devices are particularly sensitive to DoS events, and may become unresponsive in reaction to even a simple ping sweep. Adversaries may also attempt to execute a Permanent Denial-of-Service (PDoS) against certain devices, such as in the case of the BrickerBot malware. [1]
Adversaries may exploit a software vulnerability to cause a denial of service by taking advantage of a programming error in a program, service, or within the operating system software or kernel itself to execute adversary-controlled code. Vulnerabilities may exist in software that can be used to cause a denial of service condition.
Adversaries may have prior knowledge about industrial protocols or control devices used in the environment through Remote System Information Discovery. There are examples of adversaries remotely causing a Device Restart/Shutdown by exploiting a vulnerability that induces uncontrolled resource consumption. [2] [3] [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]
S1006: PLC-Blaster
PLC-Blaster is a piece of proof-of-concept malware that runs on Siemens S7 PLCs. This worm locates other Siemens S7 PLCs on the network and attempts to infect them. Once this worm has infected its target and attempted to infect other devices on the network, the worm can then run one of many modules. [1] [2]
S1157: Fuxnet
S0093: Backdoor.Oldrea
Backdoor.Oldrea is a modular backdoor that used by Dragonfly against energy companies since at least 2013. Backdoor.Oldrea was distributed via supply chain compromise, and included specialized modules to enumerate and map ICS-specific systems, processes, and protocols.[1][2][3]
C0031: Unitronics Defacement Campaign
The Unitronics Defacement Campaign was a collection of intrusions across multiple sectors by the CyberAv3ngers, where threat actors engaged in a seemingly opportunistic and global targeting and defacement of Unitronics Vision Series Programmable Logic Controller (PLC) with Human-Machine Interface (HMI). The sectors that these PLCs can be commonly found in are water and wastewater, energy, food and beverage manufacturing, and healthcare. The most notable feature of this attack was the defacement of the PLCs' HMIs.[1][2]
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.
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 | 609b4502d875… |
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]
ICS-CERT April 2017
ICS-CERT 2017, April 18 CS Alert (ICS-ALERT-17-102-01A) BrickerBot Permanent Denial-of-Service Attack Retrieved. 2019/10/24
Open source URL -
[2]
ICS-CERT August 2018
ICS-CERT 2018, August 27 Advisory (ICSA-15-202-01) - Siemens SIPROTEC Denial-of-Service Vulnerability Retrieved. 2019/03/14
Open source URL -
[3]
Common Weakness Enumeration January 2019
Common Weakness Enumeration 2019, January 03 CWE-400: Uncontrolled Resource Consumption Retrieved. 2019/03/14
Open source URL -
[4]
MITRE March 2018
MITRE 2018, March 22 CVE-2015-5374 Retrieved. 2019/03/14
Open source URL -
[5]
mitre-attack T0814Open 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.