Powering a host off is the bluntest way to stop an attack in progress, and the hardest one to undo: it ends every process, the attacker's included, and every byte of volatile evidence with them. MITRE D3FEND names this countermeasure Host Shutdown (D3-HS) and defines it as "Initiating a host's shutdown sequence to terminate all running processes." It sits under the Evict tactic as a child of Process Eviction (D3-PE), and it is the parent of Host Reboot (D3-HR). This card covers when a shutdown is the right response, which ATT&CK techniques D3FEND relates it to, how shutdown behaves on Windows, Linux and cloud instances, how to preserve what you can, and how to verify the host is safe before it is ever powered back on. It is written for incident responders, SOC leads and infrastructure teams who carry out containment.
Key takeaways
- Isolation first, power off second. CISA's ransomware guidance tells responders to power devices down only when they cannot be disconnected from the network, because doing so loses artefacts and evidence held in volatile memory.
- A shutdown stops harm; it does not clean the host. D3FEND notes the technique may not be effective against an attacker with persistence. Anything on disk starts again at the next boot.
- The host stays off until it is verified or rebuilt. That is the practical difference from a reboot, and it is why shutdown suits hosts you no longer trust.
- Know what each platform's shutdown destroys. On Amazon EC2, for example, a stop erases instance store data and does not save memory, and the instance usually comes back on a new host with a new public IPv4 address.
- Unresponsive hosts are a signal. D3FEND warns that compromised systems may ignore remote shutdown commands; plan an out-of-band or physical route.
D3-HS at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-HS (d3f:HostShutdown) |
| Tactic | Evict |
| Parent technique | Process Eviction (D3-PE): "Process eviction techniques terminate or remove running process." |
| Child technique | Host Reboot (D3-HR) |
| Sibling techniques | Process Suspension (D3-PS), Process Termination (D3-PT), Session Termination (D3-ST) |
| Digital artefact | Process (D3FEND relation: terminates Process) |
| Trigger methods named by D3FEND | Physical power functions, a remote user interface, or an installed EDR agent that offers the function |
| D3FEND reference | Botacin, Grégio and Zanata Alves, "Near-Memory & In-Memory Detection of Fileless Malware" |
| Main cost | Loss of volatile evidence and loss of service until the host is restored or replaced |
How it works
D3FEND's description matches its child technique: the shutdown is initiated in the physical presence of the device, remotely through a user interface, or through an installed EDR agent. Shutting down terminates every process, which may remove fileless malware and prevents further damage, with D3FEND's example being a host that is part of a botnet. Its considerations are persistence (the technique may not be effective), unresponsive hosts that need physical intervention, loss of memory state that can matter for forensics, and disruption for legitimate users.
What D3-HS adds over Host Reboot is time. A host that is off cannot run boot-time persistence, cannot beacon and cannot encrypt, so responders gain a window to image its disks, decide whether to rebuild, and rotate any credentials it held, without the attacker regaining control in the meantime. The cost is that service is gone for as long as the host stays down, and that the memory state is lost at the moment of power-off.
Shutdown, isolation or reboot
| Action | Stops running malware | Keeps volatile evidence | Attacker persistence | Service impact | Use when |
|---|---|---|---|---|---|
| Network isolation (EDR or switch level) | No, but cuts its network reach | Yes | Untouched, inert while isolated | Host unusable on the network | Default containment while evidence is collected |
| Process Termination (D3-PT) | One process | Mostly | Untouched | Minimal | A single known-bad process on a host you otherwise trust |
| Host Reboot (D3-HR) | All processes | No | Reloads at boot | Minutes | Memory-resident threat with persistence already removed |
| Host Shutdown (D3-HS) | All processes | No (hibernation is a partial exception, below) | Dormant until next boot | Until restored or rebuilt | Active harm that isolation cannot stop, or a host that must not run again before rebuild |
The decision logic for containment options is covered in the Incident Scoping and Containment Strategy Guide. D3-HR has its own card: D3-HR Host Reboot.
ATT&CK techniques D3FEND relates to D3-HS
Relationship type: inferred only. D3FEND does not hand-map D3-HS to ATT&CK. Every row below is inferred through the shared Process artefact: D3-HS terminates Process, and each technique acts on a Process as shown (D3FEND 1.6.0, checked November 2026). D3FEND labels these relations inferred and experimental. Each ID was checked against ATT&CK v20.
| ATT&CK ID | Technique | Relation to Process in D3FEND | What a shutdown achieves |
|---|---|---|---|
| T1003.001 | OS Credential Dumping: LSASS Memory | accesses | Stops further dumping from the host; already dumped credentials remain valid |
| T1003.002 | OS Credential Dumping: Security Account Manager | may access | Stops the process; the SAM hive on disk can still be read offline if the disk is taken |
| T1003.004 | OS Credential Dumping: LSA Secrets | may access | Stops the process; service account secrets already read remain usable |
| T1505.003 | Server Software Component: Web Shell | produces | Takes the web server offline, so the shell cannot be reached until the host returns |
| T1546.007 | Event Triggered Execution: Netsh Helper DLL | produces | Ends the running instance; the registration remains for the next boot |
| T1553.006 | Subvert Trust Controls: Code Signing Policy Modification | may create | Ends processes running under the weakened policy; the changed setting remains |
| T1564.011 | Hide Artifacts: Ignore Process Interrupts | creates | Ends processes built to survive hang-up and interrupt signals |
The D3FEND web page for D3-HS also lists further inferred relations through related artefacts, including Scheduled Task (T1053.005) and Transport Agent (T1505.002), and an Impair Defenses sub-technique that ATT&CK has since revoked; its v20 successor is T1685 Disable or Modify Tools. Every row has the same shape: shutdown halts the activity while leaving the foothold on disk and any stolen material in the attacker's hands. See T1003 OS Credential Dumping and the T1505 Server Software Component Defensive Guide for the techniques themselves.
Where it is implemented
| Implementation class | How the shutdown is triggered | Platform behaviour to know | Record left behind |
|---|---|---|---|
| Windows operating system | shutdown /s, remote with /m \\computer; /h hibernates the local computer if hibernation is enabled; /p turns off the local computer only, with no timeout or warning | Default timeout is 30 seconds; a timeout above zero implies /f, which closes applications without warning | Shutdown Event Tracker reason (/d) and comment (/c, up to 512 characters) |
| Linux with systemd | systemctl poweroff or systemctl halt; --force skips orderly service shutdown, --force --force powers off immediately without terminating processes or unmounting file systems | Double force can cause data loss; it also avoids running shutdown units an attacker may have altered | System journal on the next boot or from remote log collection |
| EDR response actions | Agent-driven action from the console or API, as D3FEND describes | Depends on a healthy agent; a tampered agent may not act | EDR action audit trail |
| Cloud instance APIs | A stop call against the instance. On Amazon EC2, for example, the default stop attempts a clean OS shutdown and falls back to a hard shutdown after a few minutes; a skip-OS-shutdown option bypasses the guest entirely | On EC2, a stop erases instance store data and does not save memory (hibernate does); on start the instance typically moves to a new underlying host with a new public IPv4 address. Inside the guest, Linux halt does not stop the instance | Provider audit log (for EC2, a CloudTrail event for each user-initiated stop) |
| Out-of-band and physical | Server management controller power off, managed power units, or the power button | The only option for hosts that ignore in-band commands | Controller logs or a manual entry in the case record |
Two choices in that table carry evidence consequences. A forced or skip-OS shutdown avoids running shutdown scripts and services that an attacker may have modified to destroy evidence, a risk RFC 3227 calls out, but it can lose unflushed data. Hibernation writes memory contents to disk before powering off, so where it is enabled and supported it preserves more than a plain shutdown; it is not a substitute for a proper memory acquisition, and on EC2 it is a separate feature that must be enabled in advance.
Implementation steps
- Set the policy before the incident. Define who may order a containment shutdown, for which host classes, and what must happen first. Include critical systems where a shutdown has safety or business consequences and needs a named approver.
- Try isolation first. Follow CISA's ordering: disconnect affected systems, or take the network segment offline at the switch, and power down only when disconnection is not possible.
- Preserve what you can in the time you have. If harm is not escalating by the second, capture memory and live state first (see the Memory Forensics Guide). For cloud instances, snapshot attached volumes and copy any instance store data you need before a stop erases it. RFC 3227's advice is not to shut down until evidence collection is complete; when active encryption or spread forces your hand, record that decision.
- Choose the shutdown mode. Orderly shutdown where you trust the shutdown path; forced shutdown where shutdown scripts may be tampered with; out-of-band power off for hosts that ignore commands.
- Issue it through an audited channel and tag it. Use the EDR, management controller or cloud API, set a reason and an incident reference, and record the time.
- Keep it off. Mark the host in the asset inventory and management tools as under investigation so automation, auto-scaling or a well-meaning colleague does not start it again. Disable or tag cloud start permissions for the instance if your platform allows it.
- Decide rebuild or restore. Image the disks for analysis, then either rebuild from known-good media or, if analysis shows the host is clean after persistence removal, start it in an isolated network and verify before reconnecting.
- Handle the credentials the host held. Rotate service account, machine and application secrets that were present on the host, since a shutdown does nothing to material already stolen.
How to verify it works
- Confirm the host is actually off: no heartbeats from the EDR agent, no traffic from its addresses at the network layer, and for cloud instances a stopped state in the provider console and the matching audit log event. A host that still sends traffic after a shutdown order is a serious finding.
- Confirm the harm stopped: the indicators that triggered the shutdown (outbound connections, file encryption on shares, spam or botnet traffic) stop appearing elsewhere at the same time.
- Confirm it stays off: alert on any start event for the host or instance until the case is closed.
- Verify before restart: offline disk analysis or a clean rebuild, then a first boot in an isolated network with monitoring, before the host rejoins production.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Containment shutdowns where isolation was tried first or the reason is recorded | 100% | Keeps evidence loss a decision, not a reflex |
| Shut-down hosts restarted before verification or rebuild | Zero | An early restart reloads the attacker's persistence |
| Time from shutdown decision to confirmed power-off | Tracked per host class | Shows whether remote and out-of-band paths work under pressure |
| Hosts that ignored an in-band shutdown command | Tracked and investigated | An unresponsive host suggests tampering with the agent or OS |
| Credentials rotated for shut-down hosts within the case | All secrets present on the host | Closes the gap a shutdown leaves |
Limits, bypasses and failure patterns
- Shutting down instead of isolating: the evidence that would explain initial access is lost when network isolation would have stopped the spread equally well.
- Restarting too soon: the host comes back with its services, scheduled tasks and autoruns intact, and the attacker regains access. Boot and firmware persistence (ATT&CK T1542 Pre-OS Boot) is not affected by any amount of power cycling.
- Losing cloud evidence by accident: stopping an instance with instance store volumes erases that data, and memory is not saved unless hibernation was set up beforehand.
- Trusting a compromised shutdown path: attackers can alter shutdown scripts and services, and an implant can hook crash and reboot handling, as Cisco Talos reported in the ArcaneDoor campaign. Forced or out-of-band power off avoids the guest's own shutdown code.
- Forgetting that attackers shut hosts down too: destructive actors stop or reboot systems to hamper recovery, a behaviour described in MITRE ATT&CK T1529 System Shutdown/Reboot. Restrict who can shut hosts down, through which tools, and alert on unexpected mass shutdowns.
- Overbroad remote power rights: the same EDR, management or cloud permission that lets a responder power off a host lets an attacker with that account do it across the estate. Treat these as privileged actions.
Where identity fits
The permission to shut a host down is usually held by machine identities as well as people: automation accounts, cloud roles used by orchestration, and management agents. Inventory which non-human identities hold power-off rights (for example the Windows "Shut down the system" user right for remote use, cloud stop permissions, EDR response API keys), scope them tightly and monitor their use. A shutdown also does nothing for the service account passwords and keys stored on the host; scope that exposure with D3-CCSA Credential Compromise Scope Analysis.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | RS.MI-01 | Incidents are contained; shutdown is a last-resort containment action |
| NIST CSF 2.0 | RS.MI-02, RC.RP-01 | Eradication and the recovery steps that follow before a host returns |
| NIST SP 800-53 Rev 5 | IR-4 Incident Handling | Containment, eradication and recovery activities |
| NIST SP 800-53 Rev 5 | CP-10 System Recovery and Reconstitution | Bringing the host back to a known state |
| CIS Controls v8.1 | Control 17 Incident Response Management | See the CIS Control 17 Incident Response Management Guide |
| MITRE D3FEND | D3-PE, D3-HS, D3-HR | Parent, technique and child |
Practitioner checklist
- Write a containment rule: isolate first, shut down only when isolation cannot stop the harm.
- Name approvers for shutting down critical or safety-relevant systems.
- Capture memory, or record why there was no time, before any containment shutdown.
- Snapshot cloud volumes and save instance store data before stopping an instance.
- Use forced or out-of-band power off when the shutdown path may be tampered with.
- Tag shut-down hosts and alert on any start event until the case closes.
- Rebuild or verify offline before a host returns to production.
- Rotate every secret that was present on the host.
- Treat remote power-off rights, human and non-human, as privileged access.
Standards and references
- MITRE D3FEND: Host Shutdown (D3-HS)
- MITRE D3FEND: Host Reboot (D3-HR)
- CISA: #StopRansomware Guide
- IETF: RFC 3227 Guidelines for Evidence Collection and Archiving
- NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- NIST: SP 800-86 Guide to Integrating Forensic Techniques into Incident Response
- Microsoft Learn: shutdown command
- systemd: systemctl manual
- AWS: Stop and start Amazon EC2 instances
Related NHI Mgmt Group resources: Incident Response Guide · Incident Scoping and Containment Strategy Guide · Evidence Handling and Chain of Custody Guide · Cloud Incident Response Guide · MITRE D3FEND Guide