T0816: Device Restart/Shutdown
Adversaries may forcibly restart or shutdown a device in an ICS environment to disrupt and potentially negatively impact physical processes. Methods of device restart and shutdown exist in some devices as built-in, standard functionalities. These functionalities can be executed using interactive device web interfaces, CLIs, and network protocol commands.
Unexpected restart or shutdown of control system devices may prevent expected response functions happening during critical states.
A device restart can also be a sign of malicious device modifications, as many updates require a shutdown in order to take effect.
Analyst context for executives and security teams
Device Restart/Shutdown matters because a forced or unexpected restart of ICS equipment can interrupt control, monitoring, or safety-related functions at the exact time operators need them. MITRE notes that restart/shutdown can be performed through built-in device functions such as web interfaces, CLIs, or network protocol commands, and that restarts may also indicate device modifications taking effect. For leaders, this is less about a single endpoint event and more about whether critical operational assets can be restarted only by authorized people, systems, and procedures.
Executive priority
Prioritize this behavior where device availability directly affects production, safety, utility delivery, or regulatory evidence. Executives should ask whether restart/shutdown authority is limited, logged, and reviewed across HMIs, PLCs, RTUs, IEDs, safety controllers, control servers, historians, gateways, VPN servers, jump hosts, and routers. The key business decision is whether the organization can distinguish planned maintenance from unauthorized or suspicious device state changes fast enough to protect operations.
Technical view
ATT&CK provides no official detection text for T0816, but the relationship to DET0801 indicates a detection strategy exists for Device Restart/Shutdown. SOC, OT monitoring, and IR teams should validate whether they can observe device uptime changes, restart/shutdown events, administrative sessions through web interfaces or CLIs, and relevant network protocol commands. Because the technique targets many ICS asset classes, detection should be asset-aware: a restart on an engineering workstation, HMI, PLC, RTU, IED, historian, control server, data gateway, safety controller, VPN server, jump host, field I/O device, or router may have different operational meaning and urgency.
Likely telemetry
- ICS device event, alarm, diagnostic, and uptime records showing restart or shutdown conditions
- HMI, workstation, server, jump host, and VPN authentication and administrative session logs
- Web interface and CLI access logs where supported by the device or management system
- Network flow and protocol-aware telemetry for commands or sessions associated with device management
- Historian, control server, and alarm management records that show loss of communications, device state changes, or process interruptions
Detection direction
- Validate that DET0801-style logic is mapped to the local asset inventory and criticality model rather than treated as a generic reboot alert.
- Tune alerts around unexpected restart/shutdown events outside approved maintenance windows, especially for assets supporting control, safety, aggregation, remote access, or network routing functions.
- Correlate restart events with authentication, authorization, remote access, web, CLI, and network command telemetry to determine who or what initiated the action.
- Account for false positives from planned updates, authorized maintenance, power events, hardware faults, and normal device lifecycle behavior.
- Identify blind spots where embedded devices, field equipment, or legacy ICS components do not produce usable logs and require network, historian, or engineering workstation evidence instead.
Mitigation priorities
- Start with authorization enforcement: restrict read, manipulate, and execute privileges to authenticated users who require them under approved policy.
- Use access management controls or gateways where field devices cannot natively support sufficient identification, authentication, or authorization.
- Require human user authentication and, where appropriate, device or software process authentication before accepting commands or API access.
- Use communication authenticity controls for untrusted networks so message sender identity and message integrity can be verified.
- Apply network segmentation, network allowlists, and protocol-aware traffic filtering to limit which systems can reach device management or control interfaces.
Analyst notes and limits
This technique is especially material in ICS because restart/shutdown can affect the physical process, not just IT service availability. The broad target relationships mean coverage should be assessed by asset role and operational consequence. Glexia would treat this as a combined OT security, identity/access, network architecture, and incident response readiness issue: can the organization prove that critical restarts are authorized, expected, and explainable?
The ATT&CK object does not specify tactics, platforms, aliases, or official detection text. Telemetry and control recommendations therefore depend on the related detection strategy, mitigation relationships, targeted ICS asset types, and the local device capabilities. No active exploitation, attribution, sector exposure, or guaranteed detection coverage is implied by the supplied fields.
Device Restart/Shutdown
Adversaries may forcibly restart or shutdown a device in an ICS environment to disrupt and potentially negatively impact physical processes. Methods of device restart and shutdown exist in some devices as built-in, standard functionalities. These functionalities can be executed using interactive device web interfaces, CLIs, and network protocol commands.
Unexpected restart or shutdown of control system devices may prevent expected response functions happening during critical states.
A device restart can also be a sign of malicious device modifications, as many updates require a shutdown in order to take effect.
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]
C0063: 2025 Poland Wiper Attacks
2025 Poland Wiper Attacks is a Russian state-sponsored campaign that conducted destructive cyberattacks against Polish energy infrastructure in December 2025. Targets included more than 30 wind and photovoltaic farms, a combined heat and power (CHP) plant, and a manufacturing sector company. The attacks on the distributed energy resources (DER) disrupted communications between affected facilities and the distribution system operator, but did not impact electricity generation or heat supply. Across the campaign, threat actors deployed two previously undocumented wiper tools, DynoWiper, a Windows-based wiper and LazyWiper, a PowerShell wiper, distributed via malicious Group Policy Objects. At the CHP plant, threat actors had maintained access since at least March 2025, using that foothold to obtain credentials and move laterally before attempting wiper deployment. Some reporting has assessed the activity to be consistent with Russian Federal Security Service (FSB) threat activity group Dragonfly, also tracked as STATIC TUNDRA, while other reporting attributes the destructive wiper activities to the Russian General Staff Main Intelligence Directorate (GRU) threat activity group ELECTRUM, also tracked as Sandworm Team.[1][2][3][4]
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 | e406652f0ba4… |
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]
mitre-attack T0816Open 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.