This site has been deprecated in favor of and will remain in place until 11/1/22.

Device Restart/Shutdown

From attackics
Jump to navigation Jump to search

To visit this technique’s new page please go to and update your links to

Device Restart/Shutdown
ID T0816
Tactic Inhibit Response Function
Data Sources Network Traffic: Network Traffic Content, Application Log: Application Log Content, Operational Databases: Device Alarm
Asset Field Controller/RTU/PLC/IED


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.

Procedure Examples

  • In the 2015 attack on the Ukrainian power grid, the Sandworm Team scheduled disconnects of uninterruptable power supply (UPS) systems so that when power was disconnected from the substations, the devices would shut down and service could not be recovered.1
  • The Industroyer SIPROTEC DoS module exploits the CVE-2015-5374 vulnerability in order to render a Siemens SIPROTEC device unresponsive. While the vulnerability does not directly cause the restart or shutdown of the device, the device must be restarted manually before it can resume operations.2


  • Disable or Remove Feature or Program - Ensure remote commands that enable device shutdown are disabled if they are not necessary. Examples include DNP3's 0x0D function code or unnecessary device management functions.
  • Authorization Enforcement - All field controllers should restrict the modification of programs to only certain users (e.g., engineers, field technician), preferably through implementing a role-based access mechanism.
  • Communication Authenticity - Protocols used for control functions should provide authenticity through MAC functions or digital signatures. If not, utilize bump-in-the-wire devices or VPNs to enforce communication authenticity between devices that are not capable of supporting this (e.g., legacy controllers, RTUs).
  • Network Allowlists - Use host-based allowlists to prevent devices from accepting connections from unauthorized systems. For example, allowlists can be used to ensure devices can only connect with master stations or known management/engineering workstations.3
  • Access Management - All devices or systems changes, including all administrative functions, should require authentication. Consider using access management technologies to enforce authorization on all management interface access attempts, especially when the device does not inherently provide strong authentication and authorization functions.
  • Network Segmentation - Segment operational network and systems to restrict access to critical system functions to predetermined management systems.3
  • Filter Network Traffic - Application denylists can be used to block automation protocol functions used to initiate device shutdowns or restarts, such as DNP3's 0x0D function code, or vulnerabilities that can be used to trigger device shutdowns (e.g., CVE-2014-9195, CVE-2015-5374).