A reboot kills every running process on a host, including memory-only malware, but it also destroys the volatile evidence responders need and does nothing against anything the attacker has written to disk. MITRE D3FEND names this countermeasure Host Reboot (D3-HR) and defines it as "Initiating a host's reboot sequence to terminate all running processes." It sits under the Evict tactic as a child of Host Shutdown (D3-HS), which in turn sits under Process Eviction (D3-PE). This card covers what D3-HR does, which ATT&CK techniques D3FEND relates it to, how to trigger it across endpoints, servers and cloud instances, how to prove the threat is gone after the reboot, and where it fails. It is written for incident responders and SOC leads deciding when a reboot belongs in a containment or eradication step.
Key takeaways
- It evicts processes, not persistence. D3FEND's own considerations state that if the attacker has achieved persistence, the technique may not be effective. A reboot only removes what lives in memory.
- Capture memory first. A reboot erases volatile state. RFC 3227 puts memory and the process table near the top of its order of volatility and advises not to shut down until evidence collection is complete.
- The value is in the check afterwards. A reboot followed by a clean persistence review and no return of the malicious behaviour is evidence of eviction; a reboot alone proves nothing.
- Attackers can use reboots too. Some implants hook crash or reboot paths, and some persistence only runs at boot, so an unplanned reboot can complete the attacker's plan.
- Treat it as a response action with an owner. Remote reboot rights through EDR, MDM or cloud APIs are powerful; restrict who holds them and log every use.
D3-HR at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-HR (d3f:HostReboot) |
| Tactic | Evict |
| Parent technique | Host Shutdown (D3-HS), itself a child of Process Eviction (D3-PE) |
| Digital artefact | Process (D3FEND relation: terminates Process) |
| Trigger methods named by D3FEND | Physical power controls, a remote management interface, or an installed EDR agent with a reboot function |
| What it removes | All running processes and in-memory state, including fileless and memory-resident code |
| What it does not remove | Files, services, scheduled tasks, registry autoruns, boot and firmware implants, stolen credentials |
| D3FEND reference | Botacin, Grégio and Zanata Alves, "Near-Memory & In-Memory Detection of Fileless Malware" |
| Main cost | Loss of volatile evidence and a service interruption for users of the host |
How it works
D3FEND describes the mechanism simply: the reboot is started at the device's power controls, through a management user interface, or through an EDR agent that offers the function. Because the operating system terminates every process on the way down, code that exists only in memory is gone when the host comes back. D3FEND gives two benefits: removal of some malware types such as fileless malware, and prevention of further damage, for example when a host is part of a botnet.
The definition is what separates D3-HR from its siblings. Process Termination (D3-PT) kills a single process and leaves the host running; Process Suspension (D3-PS) freezes one; Host Shutdown (D3-HS) terminates everything and leaves the host off. A reboot terminates everything and brings the host straight back, so it restores service quickly but also reloads anything the attacker has set to start at boot.
D3FEND lists four considerations, and each is a design constraint:
- Persistence: an attacker with persistence will likely return after the reboot.
- Unresponsive hosts: a compromised system may ignore remote shutdown or reboot commands and need physical intervention.
- Forensics: memory loses its state, which can matter for investigation.
- Availability: a reboot interrupts legitimate users.
The Cisco Talos analysis of the ArcaneDoor campaign against perimeter firewalls shows both sides of the trade-off. Talos described one implant, Line Dancer, as memory-resident and noted it would no longer be present after a reboot, while a second component, Line Runner, survived reboots and upgrades by planting a file that ran at boot. Talos also reported that Line Dancer hooked the crash dump function so the device rebooted without writing a dump, destroying memory evidence, and advised responders not to reboot a suspected compromised device before collecting memory. For the wider picture of in-memory threats, see the Fileless Malware Guide.
ATT&CK techniques D3FEND relates to D3-HR
Relationship type: inferred only. D3FEND does not hand-map D3-HR to ATT&CK. Every row below is inferred through the shared Process artefact: D3-HR terminates Process, and each ATT&CK technique acts on a Process in the way 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 reboot actually does to it |
|---|---|---|---|
| T1003.001 | OS Credential Dumping: LSASS Memory | accesses | Ends a dumping tool that is still running; credentials already taken stay valid |
| T1003.002 | OS Credential Dumping: Security Account Manager | may access | Ends the dumping process; extracted hashes stay usable |
| T1003.004 | OS Credential Dumping: LSA Secrets | may access | Ends the dumping process; service account secrets already read stay usable |
| T1505.003 | Server Software Component: Web Shell | produces | Ends processes spawned by the shell; the web shell file remains and runs again on the next request |
| T1546.007 | Event Triggered Execution: Netsh Helper DLL | produces | Ends the current process; the registered DLL loads again when netsh next runs |
| T1553.006 | Subvert Trust Controls: Code Signing Policy Modification | may create | Ends processes started under the weakened policy; a policy change written to boot configuration persists |
| T1564.011 | Hide Artifacts: Ignore Process Interrupts | creates | Terminates processes that were set to ignore hang-up or interrupt signals, which normal process kills may miss |
The D3FEND web page for D3-HR also lists further inferred relations through related artefacts, including Scheduled Task (T1053.005) and Transport Agent (T1505.002). It still shows an Impair Defenses sub-technique for disabling security tools that ATT&CK has since revoked; its ATT&CK v20 successor is T1685 Disable or Modify Tools. The pattern across the table is the same: a reboot interrupts the running activity but leaves the stored foothold and the stolen material in place. Defensive detail for the base techniques is in T1003 OS Credential Dumping, the T1505 Server Software Component Defensive Guide and the T1546 Event Triggered Execution Defensive Guide.
Where identity fits
Three of the seven related techniques are credential dumping. A reboot does not invalidate an NTLM hash, a Kerberos ticket already exported, or an LSA secret holding a service account password. If dumping is suspected, rotate the affected service account and machine credentials and invalidate cached authentication as part of the same response; see D3-ANCI Authentication Cache Invalidation and D3-CCSA Credential Compromise Scope Analysis.
Where it is implemented
| Implementation class | How the reboot is triggered | Record left behind | Fits when |
|---|---|---|---|
| Operating system tools | Windows shutdown /r, with /m \\computer for a remote host, /t for the timeout (default 30 seconds) and /d plus /c for a reason code and comment; Linux systemctl reboot | Windows Shutdown Event Tracker reason and comment; the system journal on Linux | A responder has an admin session on the host or a trusted management path |
| EDR response actions | A console or API action through the installed agent, as D3FEND describes | The EDR audit trail of who issued the action | The host is managed and the agent is healthy |
| Mobile device and endpoint management | A remote restart action. Microsoft Intune's Restart action, for example, usually starts within 5 minutes, may not warn the user, and depends on the device receiving a push notification | Management platform action history | Laptops and mobile devices away from the corporate network |
| Cloud and hypervisor APIs | A reboot call against the instance or virtual machine. Amazon EC2's reboot, for example, keeps instance store data and IP addresses and falls back to a hard reboot if the instance does not shut down cleanly within a few minutes | Provider audit log (for EC2, a CloudTrail record of the reboot) | Cloud workloads, including hosts that ignore in-guest commands |
| Out-of-band and physical power | Server management controllers, managed power units or the power button | Controller logs, or a manual note in the case record | The host no longer responds to remote commands, the case D3FEND calls out |
Two Linux details matter for eviction. systemctl reboot --force skips orderly service shutdown, which avoids running shutdown scripts an attacker may have altered, a risk RFC 3227 names. And systemctl soft-reboot restarts only user space while the kernel keeps running, so it is not a host reboot in D3FEND's sense: kernel-level code survives it. The systemctl documentation also notes that reboot is redirected to a soft reboot if a new root file system is staged in /run/nextroot/, so check for that before relying on a reboot to clear the kernel.
Implementation steps
- Decide whether a reboot is the right action. Use it when the threat is believed to be memory-resident, when a host is actively causing harm (botnet traffic, encryption in progress) and isolation is not available, or as the final step after persistence has been removed. Prefer network isolation when the goal is only to stop spread while evidence is gathered; see the Incident Scoping and Containment Strategy Guide.
- Capture volatile evidence. Acquire memory and record running processes, network connections and logged-on sessions before the reboot, following the Memory Forensics Guide and the Evidence Handling and Chain of Custody Guide. If the device vendor publishes a forensic procedure, as Cisco did for ASA devices, follow it.
- Remove persistence first where you can. Review services, scheduled tasks, autorun registry keys, web roots, boot configuration and firmware integrity, and remove what you find. A reboot after clean-up is an eviction; a reboot before it is often a restart of the implant.
- Issue the reboot through an audited path. Use the EDR, management platform or cloud API rather than an ad hoc session, and record a reason. On Windows, a
/dreason code and/ccomment place the incident reference in the Shutdown Event Tracker. - Watch the host come back. Keep the host isolated or closely monitored as it boots, since boot-time persistence acts in the first minutes.
- Verify eviction. Run the checks in the next section before returning the host to normal service.
- Roll back if the reboot fails. If the host does not return, use the platform's recovery or rebuild path; if the malicious behaviour returns, move to rebuild from known-good media and treat the reboot as having failed.
How to verify it works
- Confirm the reboot happened: check the boot time on the host, the management or EDR action record, and for Windows the shutdown record carrying the reason you set. An unexpected-shutdown record where you expected a clean reboot can mean the shutdown path was tampered with.
- Confirm the process is gone and stays gone: hunt for the original process name, hash, parent chain and command line for a defined window after the reboot (for example 72 hours, an NHI Mgmt Group suggestion, not a standard).
- Confirm the network indicators are gone: no further connections from the host to the command and control addresses or domains seen before the reboot.
- Re-run the persistence review: the same checks you used before the reboot, now on the booted host, compared with a known-good baseline.
- Confirm credentials were handled: where dumping was in scope, the rotation and cache invalidation tickets are closed.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Response reboots preceded by memory capture | 100% unless the case record states why not | Shows evidence is not being destroyed by reflex |
| Rebooted hosts with recurrence of the same indicator within 7 days | Zero, each one escalated to rebuild | A recurrence means persistence was missed |
| Response reboots issued through an audited channel | 100% | Every reboot has an owner and a reason |
| Median time from reboot decision to host back and verified | Tracked per host class | Shows the operational cost of the action |
| Hosts that ignored a remote reboot command | Tracked and investigated | An unresponsive host is itself a compromise indicator |
Limits, bypasses and failure patterns
- Rebooting before evidence capture: the reflex "turn it off and on again" loses the only copy of a memory-resident implant and the process table that shows how it got in.
- Persistence that runs at boot: services, scheduled tasks, autostart entries and web shells reload or remain. Boot and firmware implants (ATT&CK T1542 Pre-OS Boot, including T1542.003 Bootkit) run before the operating system and its security tools.
- Reboots the attacker wanted: Talos reported a vulnerability being used to force a reboot that triggered the ArcaneDoor persistence. A reboot can also be an attacker's goal in itself, covered by MITRE ATT&CK T1529 System Shutdown/Reboot.
- Tampered shutdown paths: RFC 3227 warns that attackers may alter startup and shutdown scripts and services to destroy evidence. A forced reboot avoids running altered shutdown scripts.
- Soft reboots mistaken for full reboots: a user-space restart or a kexec into another kernel does not give the same guarantees as a firmware-level restart.
- Stolen material outlives the reboot: credentials, tokens and data already exfiltrated are unaffected, so the incident is not closed by the reboot.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | RS.MI-01, RS.MI-02 | Incidents are contained; incidents are eradicated |
| NIST CSF 2.0 | RS.AN-03 | Analysis establishes what happened and the root cause, which needs the evidence a reboot destroys |
| NIST SP 800-53 Rev 5 | IR-4 Incident Handling, IR-4(1) Automated Incident Handling Processes | Containment and eradication steps, including automated response actions |
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring | Monitoring that confirms the threat does not return |
| CIS Controls v8.1 | Control 17 Incident Response Management | The process that decides when a reboot is used; see the CIS Control 17 Incident Response Management Guide |
| MITRE D3FEND | D3-PE, D3-HS, D3-HR | Grandparent, parent and technique |
Related countermeasures
- Host Shutdown (D3-HS): the parent; terminates everything and leaves the host off, which suits hosts that must not come back until rebuilt. See D3-HS Host Shutdown.
- Process Termination (D3-PT) and Process Suspension (D3-PS): narrower siblings under Process Eviction that act on one process and keep the host and its memory available.
- Authentication Cache Invalidation (D3-ANCI): the credential step a reboot does not perform.
- For the full D3FEND matrix, see the MITRE D3FEND Guide.
Practitioner checklist
- Write down when a response reboot is allowed and who approves it.
- Capture memory and live state before any response reboot, or record why not.
- Remove known persistence before rebooting, not after.
- Issue reboots through EDR, management or cloud APIs that log the actor and reason.
- Restrict remote reboot permissions to response roles and review them.
- Prefer a forced, full reboot over a soft reboot when the aim is eviction.
- Hunt for the original indicators for a defined window after the reboot.
- Rotate credentials and invalidate caches where credential dumping was in scope.
- Escalate to rebuild from known-good media if the behaviour returns.
Standards and references
- MITRE D3FEND: Host Reboot (D3-HR)
- MITRE D3FEND: Host Shutdown (D3-HS)
- IETF: RFC 3227 Guidelines for Evidence Collection and Archiving
- NIST: SP 800-86 Guide to Integrating Forensic Techniques into Incident Response
- NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- Microsoft Learn: shutdown command
- systemd: systemctl manual
- Microsoft Learn: Intune Restart remote action
- AWS: Reboot your Amazon EC2 instance
- Cisco Talos: ArcaneDoor campaign targeting perimeter network devices
Related NHI Mgmt Group resources: Incident Response Guide · Memory Forensics Guide · Fileless Malware Guide · MITRE ATT&CK T1529 System Shutdown/Reboot · MITRE D3FEND Guide