Denial of Service (T0814) in an industrial network means a protection relay, PLC, gateway or SCADA service stops answering at the moment the process needs it to respond. MITRE ATT&CK for ICS places it in the Inhibit Response Function tactic: the aim is not only an outage but to stop safety and protection functions doing their job during an abnormal event. ATT&CK lists it against embedded devices, Windows, Linux and network devices. This guide is for OT security engineers, control system engineers and SOC analysts working on OT. It covers the recorded cases, the ATT&CK v20 detection analytics, the single mitigation ATT&CK maps and the wider controls that make devices harder to knock over, and how to respond without making the process situation worse. For the matrix as a whole see the MITRE ATT&CK for ICS Guide.
Key takeaways
- Two routes, one effect. ATT&CK describes floods of requests and requests a device cannot handle, including exploited flaws, and both end with a device that may stay unresponsive until it is rebooted.
- Protection relays were the documented target. Industroyer's SIPROTEC module used CVE-2015-5374 to make Siemens relays stop responding to any command until manually rebooted, according to ESET.
- Fragility is a design fact, not a bug report. Many field devices were never built to cope with unexpected traffic, so your own scanners can cause T0814. Treat active scanning in OT as a change, not a routine task.
- Detection needs correlation. ATT&CK v20 analytics pair a traffic or malformed-packet spike with a matching effect: a device dropping out of the poll cycle, a historian gap or a service crash.
- Recovery may mean a site visit. Permanent denial of service, as with the bricked gateways in the Fuxnet and 2015 Ukraine cases, turns an outage into a hardware and firmware logistics problem.
What T0814 covers in an OT environment
ATT&CK defines T0814 as performing denial-of-service attacks to disrupt expected device functionality. Its description gives three forms, and each looks different on the wire and on the device.
| Form | What ATT&CK describes | Typical OT symptom | Recorded example |
|---|---|---|---|
| Volume | Overwhelming the target with a high volume of requests in a short time | Polls time out, interface errors and discards climb on the switch port, device CPU saturates | Fuxnet continuously sending frames on the Meter-Bus serial channel, per Claroty Team82 |
| Malformed or unexpected input | Sending a request the device does not know how to handle, or exploiting a programming error | Device hangs after a single packet, stays down until power cycle | Industroyer SIPROTEC module (CVE-2015-5374) |
| Permanent (PDoS) | Leaving the device unusable rather than temporarily unresponsive; ATT&CK cites the BrickerBot malware | Device will not boot or cannot be reached even after restart | 2015 Ukraine serial-to-ethernet firmware overwrite; Fuxnet gateway destruction |
ATT&CK also notes that adversaries may learn which protocols and devices are present through Remote System Information Discovery (T0888) first, and that exploiting a flaw that causes uncontrolled resource consumption (CWE-400) can produce a Device Restart/Shutdown (T0816). Where the result is lost operator control or visibility, the impact techniques T0813 Denial of Control and T0815 Denial of View describe the outcome; T0814 describes the action against the device. The tactic context is in the ATT&CK for ICS Inhibit Response Function Tactic Guide.
Why OT devices are more exposed than IT servers
- Protocols without authentication: in NHI Mgmt Group's view, many field protocols accept any well-formed request from any host that can reach the port, so the network path is the only barrier. See the Modbus TCP and Modbus Security Guide.
- Long patch cycles: fixed firmware may wait for an outage window, so a known DoS flaw can stay present for years.
- Reboot is not free: some devices need a manual restart on site, and restarting a protection device may need operations to change the plant state first.
Real cases recorded by ATT&CK
ATT&CK v20 lists four pieces of software and two campaigns as procedure examples for T0814. They show the range from a single crafted packet to bricked hardware.
| Case | What happened (as ATT&CK and its cited sources record) | Lesson for defenders |
|---|---|---|
| Industroyer (S0604), Ukraine 2016 | A dedicated module sent crafted UDP packets to port 50000 on Siemens SIPROTEC relays, exploiting CVE-2015-5374; ESET reports the device then stopped responding to any commands until rebooted manually | Protection relays need the same patch tracking and network filtering as controllers; a relay that cannot trip is a safety issue |
| 2015 Ukraine Electric Power Attack (C0028) | Call centre operators were hit with a telephone denial of service; serial-to-ethernet converters had firmware overwritten, bricking them | Plan for the loss of both communication paths and customer contact channels; keep spare gateways and known-good firmware |
| Fuxnet (S1157) | Shut down SSH, HTTP, telnet and SNMP on sensor gateways and deleted routing tables; Claroty also describes Meter-Bus flooding and NAND memory wear | Out-of-band recovery and spare hardware decide how fast remote sites come back |
| PLC-Blaster (S1006) | Research worm for Siemens S7-1200; its authors show that an endless loop violating the cycle time limit stops the PLC program, a DoS | Logic changes can cause DoS from inside the controller, so program integrity monitoring matters here too |
| Backdoor.Oldrea (S0093) | Its OPC scanning caused multiple common OPC platforms to crash intermittently | Even reconnaissance can take down fragile OT services; the same applies to careless defensive scanning |
| Unitronics Defacement Campaign (C0031) | CyberAv3ngers defaced Unitronics HMIs so operators could not run devices normally, and caused a communications failure at a remote pumping station | Internet-exposed PLCs with default or no passwords turned a political defacement into an operational outage |
The CISA-led advisory AA23-335A records that the Unitronics actors reached internet-connected Vision Series PLCs on the default TCP port 20256 using default or absent passwords, and that at least 75 devices were compromised, including at least 34 in the US water and wastewater sector. Actor background is in the CyberAv3ngers Threat Actor Profile Guide and the Sandworm Threat Actor Profile. For the malware families see the ICS Malware History Guide.
Detection: the ATT&CK v20 analytics in practice
ATT&CK v20 publishes a detection strategy for T0814 with four analytics, one per platform. Each has the same "operational fidelity gate": alert only when a device-specific threshold is exceeded and the same window shows an effect such as failed polling, a device alarm or restart, resource exhaustion or out-of-spec protocol behaviour. Planned load tests, maintenance, network failover and known equipment faults are suppressed after operator confirmation.
| Platform | Cause signal | Effect signal | Log sources named by ATT&CK |
|---|---|---|---|
| Embedded (field devices) | Malformed or high-volume ICS protocol traffic to one device from a source not on the approved SCADA server list | Device drops out of the supervisory poll cycle; no new historian value within 1.5 times the expected poll interval | Flow records (NetFlow/IPFIX), OT network sensor content, process historian, SCADA communication-loss alarms |
| Windows (OPC, historian, SCADA polling servers) | Inbound connection rate to the ICS application port above threshold from unexpected sources | Service consumes abnormal CPU or memory and stops; Service Control Manager events 7034 and 7036 | Sysmon Event ID 3 (network connection), Windows System log |
| Linux (historian daemons, OPC gateways) | Sustained high-rate inbound connections | ICS service process killed or crashing; daemon log shows connection limit, out of memory or watchdog timeout | auditd, syslog |
| Network devices | Spike in discarded or errored packets on an ICS-facing interface | Switch or router CPU above baseline and loss of reachability to downstream devices | SNMP interface counters (ifInErrors, ifOutDiscards), flow records |
Tuning values you have to set
ATT&CK leaves the thresholds to the defender and names them: a connection threshold derived from the device's real scan rate, a malformed packet threshold above the device's documented error tolerance, the expected poll interval per device, an interface error baseline, a CPU threshold for network devices, and a correlation window of typically one to five minutes. In practice:
- Baseline from the poll schedule: export the SCADA polling configuration and set per-device expected rates; OT traffic is regular enough that deviations stand out.
- Build an approved talker list: the SCADA servers, engineering workstations and gateways allowed to speak each protocol to each device. Anything else talking to a relay or PLC is worth an alert regardless of volume.
- Feed operational alarms to security: communication-loss alarms usually stay in the control room. Forwarding them to the OT SOC provides the effect half of the correlation.
- Watch for known exploit traffic: where a device has a published DoS flaw that cannot be patched yet, write a sensor rule for the vulnerable service and port, as ATT&CK's embedded analytic does for the SIPROTEC case.
Sensor placement is covered in the OT Network Security Monitoring Guide and running alerts in the OT Security Operations Centre Guide.
Prevention: the mapped mitigation and the controls around it
ATT&CK v20 maps one mitigation to T0814: Watchdog Timers (M0815), with the guidance that system and process restarts should be performed when a timeout condition occurs. The controls below come from the CISA-led advisory AA23-335A and the E-ISAC and SANS Ukraine analysis, and are NHI Mgmt Group's grouping rather than ATT&CK mappings for this technique.
| Control | What it stops | Notes for OT |
|---|---|---|
| Remove internet exposure of controllers and HMIs | Direct floods and exploit packets from anywhere | AA23-335A: disconnect PLCs from the public internet or put them behind a firewall and secure gateway |
| Allowlists of hosts per device and protocol | Traffic from unapproved sources reaching field devices | AA23-335A recommends allowlists so only known workstations connect; enforce at zone boundaries |
| Segmentation into zones and conduits | A flood or worm in one zone reaching another | See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide |
| Rate limits and protocol filtering at conduits | High-volume and out-of-spec requests | Industrial firewalls with protocol awareness can drop malformed PDUs before they reach the device |
| Patching known DoS flaws in relays and PLCs | Single-packet exploits such as CVE-2015-5374 | Track vendor advisories; see the ICS Advisory Triage and OT Vulnerability Management Guide |
| Disabling unneeded remote management of field devices | Firmware overwrite leading to permanent DoS | The E-ISAC and SANS report recommends disabling remote management when not needed and watching for firmware uploads outside downtime |
| Spares, vaulted firmware and cold-standby hardware | Long outages after permanent DoS | Both AA23-335A and the Ukraine analysis call for spares and known-good copies |
Choosing what to do first
- Small utility or single site: remove internet exposure, change default passwords, keep one spare of each critical gateway and a copy of its firmware. These steps address the cases above at low cost.
- Multi-site operator: add per-device allowlists at site firewalls, central OT network monitoring with the correlated analytics, and an out-of-band path to remote sites so a frozen gateway can be reached.
- Grid and protection-heavy environments: prioritise relays and IEDs: patch status, protocol filtering on IEC 61850 and vendor service ports, and redundancy in protection schemes. See the IEC 61850 Substation Communications Security Guide.
Testing without causing the outage
ATT&CK's warning that a ping sweep can disable some devices applies to defenders too. Build the inventory from passive monitoring (see the OT Asset Visibility Guide), run load tests on a bench unit with the same firmware, and treat any unavoidable live test as a change with operations present and a restart plan. The traffic level that degrades each device type on the bench becomes your detection threshold.
Safety-aware response
- Let operations lead: when a protection or control device goes silent, the control room decides whether the process must move to a safe state or manual operation. Security supports that decision.
- Check the protection and safety layers: confirm whether protective relays and the safety instrumented system can still act. A DoS on a relay during a fault is the scenario that makes T0814 an Inhibit Response Function technique. See the Safety Instrumented Systems Security Guide.
- Block the source at the nearest conduit: drop traffic from the offending host or segment; do not shut down shared network equipment without operations agreeing.
- Preserve evidence before restart: capture traffic and device diagnostics where it is safe, since a reboot clears the device state that shows what happened.
- Restart or replace in a controlled order: restart hung devices as operations direct; for bricked devices, reflash from vaulted firmware or swap in spares, then verify configuration.
- Check for a second stage: in the Industroyer and Ukraine cases DoS ran alongside switching commands and wipers, so treat a DoS as possible cover for other activity.
The full process is in the OT Incident Response Guide and recovery planning in the OT Backup, Recovery and Golden Image Guide.
Metrics that show it is working
- Internet-exposed OT devices: count of controllers, HMIs and gateways reachable from the internet. Target zero.
- Allowlist coverage: share of critical field devices protected by a per-device allowlist at a zone boundary.
- Known DoS flaws open: number of devices with an unpatched, published denial-of-service vulnerability, and their age.
- Spare and firmware coverage: share of critical device types with a spare unit and a vaulted firmware copy.
- Correlated alert quality: share of T0814 alerts that matched a real device effect, and mean time from communication loss to security triage.
Framework mapping
| Control area | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | ATT&CK for ICS mitigation |
|---|---|---|---|
| Denial of service protection and capacity | SC-5 Denial-of-service Protection; SC-6 Resource Availability | PR.IR-04 | M0815 Watchdog Timers (mapped to T0814) |
| Fail in a known, safe state | SC-24 Fail in Known State | PR.IR-03 | M0815 Watchdog Timers (mapped to T0814) |
| Boundary protection and allowlists | SC-7 Boundary Protection; AC-17 Remote Access | PR.IR-01 | M0930 Network Segmentation, M0807 Network Allowlists (NHI Mgmt Group addition; not mapped to T0814 in ATT&CK v20) |
| Least functionality | CM-7 Least Functionality | PR.PS-01 | M0942 Disable or Remove Feature or Program (NHI Mgmt Group addition) |
| Monitoring and correlation | SI-4 System Monitoring | DE.CM-01; DE.AE-02 | Detection strategy for T0814 (four platform analytics) |
| Recovery from permanent DoS | CP-9 System Backup; CP-10 System Recovery and Reconstitution | PR.DS-11; RC.RP-01 | No ATT&CK mitigation mapped for T0814 |
NIST SP 800-82 Rev 3 is the tailoring guide for these controls in OT; see the NIST SP 800-82 OT Security Guide, and for zone design the IEC 62443 Guide.
Common failure patterns
- Active scanning treated as harmless: a routine vulnerability scan or discovery sweep crashes a fragile device and is logged as a fault, not a lesson.
- Relays left out of patching: protection devices sit outside the PLC patch programme, so single-packet DoS flaws like the one Industroyer used stay open.
- Flat networks: any compromised host can reach every device's service port, so a flood or exploit has no barrier.
- No spares or firmware copies: permanent DoS turns into days of downtime while hardware is sourced, as the bricked gateways in Ukraine and the Fuxnet case show.
- Operational alarms never reach security: the device dropping out of the poll cycle is visible in the control room but never correlated with the traffic spike.
Practitioner checklist
- Remove internet exposure of PLCs, HMIs, relays and gateways, and change all default passwords.
- Enforce per-device allowlists for each industrial protocol at zone boundaries.
- Track and patch published denial-of-service flaws in relays, PLCs and gateways, with interim filtering where patching waits.
- Deploy passive OT network monitoring and implement the correlated cause-and-effect analytics with tuned thresholds.
- Forward communication-loss alarms and historian gaps to the OT SOC.
- Configure watchdog restarts where devices and services support them, and test the behaviour.
- Keep spares and vaulted firmware for critical device types, and an out-of-band path to remote sites.
- Write a response runbook that puts operations first and preserves evidence before restart.
Standards and references
- MITRE ATT&CK for ICS: Denial of Service (T0814)
- MITRE ATT&CK for ICS: Watchdog Timers (M0815)
- NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
- CISA, FBI, NSA, EPA and partners: AA23-335A, IRGC-Affiliated Cyber Actors Exploit PLCs in Multiple Sectors
- ESET: Win32/Industroyer, A new threat for industrial control systems
- E-ISAC and SANS ICS: Analysis of the Cyber Attack on the Ukrainian Power Grid
- Claroty Team82: Unpacking the Blackjack Group's Fuxnet Malware
- Spenneberg, Bruggemann and Schwartke: PLC-Blaster, A Worm Living Solely in the PLC
Related NHI Mgmt Group resources: MITRE ATT&CK for ICS Guide · OT Security Guide · DDoS Protection Guide · T0826 Loss of Availability · T0881 Service Stop