Device Restart/Shutdown (T0816) uses a control device's own restart or power-off function against it, so the controller, RTU or server is offline exactly when the process needs a response. MITRE ATT&CK for ICS files it under Inhibit Response Function and notes that many devices offer restart and shutdown as built-in features, reachable through web interfaces, command line interfaces and network protocol commands. It also makes a point defenders often miss: an unexpected restart can be the sign of a malicious modification, because many updates need a restart to take effect. This guide is for OT security engineers, control engineers and SOC analysts. It covers the recorded cases, the ATT&CK v20 detection analytics, the nine mitigations ATT&CK maps, and how to respond safely. For the matrix as a whole see the MITRE ATT&CK for ICS Guide.
Key takeaways
- It abuses a legitimate function. Restart and shutdown commands exist for maintenance, so the defence is controlling who can send them and from where, not blocking a malware signature.
- A restart can hide a bigger change. ATT&CK notes updates often need a restart, and in the 2025 Poland attacks corrupted firmware on RTUs produced a reboot loop.
- Support systems count. In the 2015 Ukraine attack, Sandworm Team scheduled UPS units to shut down data and telephone servers through the UPS management interface.
- Change windows are the detection key. All four ATT&CK v20 analytics alert on restart commands from sources or accounts outside the approved list and outside a change window.
- Several devices restarting together is the strongest signal. ATT&CK's embedded analytic looks for restart or offline alarms from more than one device in a short window with no maintenance ticket.
What T0816 covers and how it differs from nearby techniques
ATT&CK defines T0816 as forcibly restarting or shutting down a device in an ICS environment to disrupt and potentially affect physical processes. It applies to embedded devices, Windows, Linux and network devices. The methods are the device's own: a reset button on a web page, a reload command on a switch, a restart service in an industrial protocol, or a power command to a UPS.
| Technique | What the adversary does | How it differs from T0816 |
|---|---|---|
| T0816 Device Restart/Shutdown | Triggers a restart or power-off of the whole device | Device is down for the reboot time or until someone powers it on |
| T0814 Denial of Service | Floods or crashes a device with traffic or malformed input | The device hangs rather than being told to restart; ATT&CK notes a DoS exploit can lead to a restart |
| T0881 Service Stop | Stops a service or process on a host | The host stays up; one function is stopped |
| T0858 Change Operating Mode | Moves a controller to program, stop or similar mode | Device stays powered but the logic stops or becomes writable |
| T1693 Modify Firmware | Replaces or corrupts device firmware | Often followed by a restart to load it, which may be the only visible event |
The siblings are covered in the T0881 Service Stop and ICS T0858 Change Operating Mode guides. The tactic context is in the ATT&CK for ICS Inhibit Response Function Tactic Guide.
Real cases recorded by ATT&CK
ATT&CK v20 lists one piece of software and two campaigns as procedure examples for T0816.
| Case | What happened (as ATT&CK and its cited sources record) | Lesson for defenders |
|---|---|---|
| 2015 Ukraine Electric Power Attack (C0028) | Sandworm Team scheduled uninterruptible power supplies to shut down data and telephone servers via the UPS management interface. The E-ISAC and SANS analysis adds that in at least one case a network-connected UPS was reconfigured so the outage also cut power to buildings or data centres | UPS, power distribution and building systems are part of the control system's attack surface; keep their management off the control network |
| Industroyer (S0604) | The SIPROTEC module exploited CVE-2015-5374; ATT&CK notes it does not restart the relay directly, but the relay must be restarted manually before it resumes operation | A forced manual restart of protection devices is a recovery cost; plan who goes to site and in what order |
| 2025 Poland Wiper Attacks (C0063) | The adversaries corrupted firmware in Hitachi RTUs, producing a fault that triggered a reboot loop | Restarts that repeat or follow a firmware write are a sign of tampering, not a power glitch |
CERT Polska's report on the 29 December 2025 attacks gives more detail. At renewable energy sites the attacker logged in to Hitachi RTU560 units with a default account and uploaded corrupted firmware; secure firmware update was disabled. On two Hitachi Relion 650 protection relays the attacker used a default FTP account to delete essential files, so the devices shut down and could not restart. Moxa NPort serial servers were reset to factory settings with changed passwords and unreachable IP addresses, which slowed recovery. Initial access at the renewable sites came through internet-exposed VPN interfaces without multi-factor authentication. CERT Polska links the infrastructure to the cluster tracked as Static Tundra, Berserk Bear, Ghost Blizzard and Dragonfly, and states that overlaps with Sandworm tooling were too weak to confirm that group's involvement. For the Ukraine actor see the Sandworm Threat Actor Profile.
Detection: the ATT&CK v20 analytics in practice
ATT&CK v20 publishes four analytics for T0816. They share a fidelity gate: alert only when the restart cannot be attributed to an authorised operator or engineering source for that device and function, and it falls outside an approved change or maintenance window or lacks change-control context. Activity that matches approved maintenance, commissioning, failover, recovery or tested procedures is suppressed.
| Platform | What to look for | Log sources named by ATT&CK |
|---|---|---|
| Embedded (PLCs, RTUs, relays) | Industrial protocol restart or reset command from a source not on the engineering workstation list; more than one device raising restart or offline alarms within a short window with no open maintenance ticket; non-standard packets to a diagnostic port just before a device goes offline | OT network sensor content, SCADA alarm and event database |
| Windows (engineering workstations) | Vendor engineering software issuing a device restart outside a maintenance window by an account not on the approved engineer list | Engineering workstation application logs |
| Linux (engineering tools, gateways) | A restart or shutdown command executed outside the change window by a user ID not on the approved list | auditd execve records |
| Network devices | SNMP SET to power or restart objects, or CLI reload commands, from outside the approved network management subnet | SNMP and device logs |
Making the analytics work
- Maintain three lists: ATT&CK names the variables you must supply: the engineering workstation allowlist, the change-control windows, and a bulk restart time window for coordinated events. Keep them in a form the SOC platform can read.
- Join the change calendar: link restart alerts to work orders automatically, so analysts see at once whether a restart was planned.
- Treat reboot loops as their own alert: repeated restarts of the same device in minutes, or a restart following a firmware transfer, should go straight to investigation.
- Cover support systems: add UPS, power distribution units and building management interfaces to monitoring, since the Ukraine case used them.
- Collect device logs centrally: where controllers and relays record restart causes in a diagnostic buffer, collect them on a schedule so evidence survives later restarts.
Sensor placement is covered in the OT Network Security Monitoring Guide and engineering host logging in the Engineering Workstation Security Guide.
Prevention: the nine mitigations ATT&CK maps
ATT&CK v20 maps nine mitigations to T0816. They fall into three groups.
| Group | Mitigation | ATT&CK guidance (paraphrased) |
|---|---|---|
| Who can send the command | M0800 Authorization Enforcement | Restrict program and device changes to specific roles such as engineers and field technicians, ideally role-based |
| M0801 Access Management | Require authentication for all device changes and administrative functions; use access management technology where the device lacks its own | |
| M0804 Human User Authentication | Require authentication for all remote and local management sessions on field controllers | |
| Where it can come from | M0807 Network Allowlists | Host-based allowlists so devices accept connections only from master stations or known engineering workstations |
| M0930 Network Segmentation | Restrict access to critical functions to predetermined management systems | |
| M0813 Software Process and Device Authentication | Authenticate connections from software and devices to protected management functions | |
| M0802 Communication Authenticity | Use protocols with message authentication, or bump-in-the-wire devices or VPNs for legacy controllers and RTUs | |
| Whether the function exists | M0942 Disable or Remove Feature or Program | Disable remote shutdown commands and management functions that are not needed, including protocol restart functions |
| M0937 Filter Network Traffic | Use protocol-aware denylists to block restart and shutdown functions, and traffic exploiting known flaws that trigger restarts |
ATT&CK names DNP3's restart function as an example of a protocol command to filter. Protocol-aware filtering is covered in the DNP3 and DNP3 Secure Authentication Guide and the Modbus TCP and Modbus Security Guide; zone design in the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.
Choosing what to do first
- Default credentials first: every device action in the Poland case started with a default account (RTU, FTP, root SSH, serial server). Changing them is the cheapest control with the largest effect.
- Secure firmware update where the device supports it: CERT Polska records it was disabled on the affected RTUs. Turn it on and keep firmware current.
- Remote access with MFA: the Poland renewable sites were reached through VPN interfaces without it. See the OT Remote Access Guide.
- Then filtering and allowlists: larger operators with protocol-aware firewalls can block restart functions at conduits from anything but the engineering zone.
Where identity fits
T0816 succeeds when someone holds a credential the device accepts. In the Poland case that meant built-in default accounts on RTUs, relays and serial servers, and static VPN accounts. Treat device management accounts as non-human identities: inventory them per device, remove or rename defaults, give each device unique credentials held in a vault, and rotate them after vendor visits. Engineering accounts allowed to issue restarts should be named individuals, not shared logins, so the "account not in the approved engineer list" analytic has meaning. See NHIs in OT and the OT and ICS Identity and Access Guide.
Safety-aware response
- Operations decide the plant state: when devices restart or shut down unexpectedly, the control room chooses manual operation or a safe state.
- Check protection and safety: confirm relays and the safety instrumented system are running and unchanged. See the Safety Instrumented Systems Security Guide.
- Do not simply power it back on: if the restart might have loaded modified firmware or logic, compare firmware and program against known-good copies before returning the device to service.
- Close the path: disable the account or session used, block the source at the zone boundary, and check remote access logs.
- Preserve evidence: capture device diagnostic buffers, firmware version and configuration as found, and network captures.
- Restore and verify: reflash from vaulted firmware where needed, set new unique credentials, and confirm control with operations before automatic mode.
The full process is in the OT Incident Response Guide and recovery in the OT Backup, Recovery and Golden Image Guide.
Metrics that show it is working
- Default accounts remaining: OT devices with vendor default or built-in accounts enabled. Target zero outside documented exceptions.
- Unplanned restarts explained: share of device restarts matched to a work order within one shift.
- Restart function exposure: share of critical devices where remote restart is disabled or filtered to the engineering zone.
- Secure update coverage: share of devices supporting secure firmware update that have it turned on.
- Firmware baseline coverage: share of controllers, RTUs and relays with a recorded known-good firmware version and copy.
Framework mapping
| Control area | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | ATT&CK for ICS mitigation |
|---|---|---|---|
| Who may restart devices | AC-3 Access Enforcement; CM-5 Access Restrictions for Change | PR.AA-05 | M0800, M0801, M0804 |
| Where commands may come from | SC-7 Boundary Protection; IA-3 Device Identification and Authentication | PR.IR-01 | M0807, M0930, M0813, M0802 |
| Remove or filter restart functions | CM-7 Least Functionality | PR.PS-01 | M0942, M0937 |
| Change control for restarts | CM-3 Configuration Change Control | PR.PS-01 | Basis of the ATT&CK change-window analytics |
| Firmware integrity | SI-7 Software, Firmware, and Information Integrity | DE.CM-09 | Not mapped to T0816 in ATT&CK v20 (NHI Mgmt Group addition) |
| Monitoring | SI-4 System Monitoring | DE.CM-01 | Detection strategy for T0816 (four platform analytics) |
For OT tailoring see the NIST SP 800-82 OT Security Guide and the IEC 62443 Guide.
Common failure patterns
- Default accounts left on field devices: RTUs, relays and serial servers in the Poland case were all reached with built-in credentials.
- Restarts written off as glitches: a device that reboots once is power cycled and forgotten; a reboot loop after a firmware write is treated as a hardware fault.
- UPS and building systems on the control network: management interfaces on power equipment let an attacker shut down servers without touching them.
- Remote restart enabled everywhere: protocol restart functions remain reachable from any host because nobody decided whether they were needed.
- No change calendar in the SOC: analysts cannot tell planned maintenance from an attack, so restart alerts are tuned off.
Practitioner checklist
- Inventory device management accounts and remove or change every default credential.
- Enable secure firmware update where supported and record known-good firmware versions.
- Disable remote restart and shutdown functions that are not needed, and filter the rest to the engineering zone.
- Enforce allowlists so field devices accept management traffic only from approved engineering hosts.
- Put remote access behind MFA and remove static VPN accounts.
- Move UPS, PDU and building management interfaces off the control network and monitor them.
- Implement the change-window and bulk-restart analytics with lists the SOC can read.
- Write a response step that checks firmware and logic before a restarted device returns to service.
Standards and references
- MITRE ATT&CK for ICS: Device Restart/Shutdown (T0816)
- MITRE ATT&CK: 2025 Poland Wiper Attacks (C0063)
- NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
- CERT Polska: Energy Sector Incident Report 2025
- E-ISAC and SANS ICS: Analysis of the Cyber Attack on the Ukrainian Power Grid
- ESET: Win32/Industroyer, A new threat for industrial control systems
Related NHI Mgmt Group resources: MITRE ATT&CK for ICS Guide · OT Security Guide · PLC Security Guide · T0826 Loss of Availability · T0813 Denial of Control