Killing a malicious process stops the damage but destroys the memory an investigator needs, while leaving it running lets it keep stealing credentials or serving a web shell. MITRE D3FEND names the middle path Process Suspension (D3-PS) and defines it as "Suspending a running process on a computer system." It sits under the Evict tactic as a child of Process Eviction (D3-PE), next to Process Termination (D3-PT). This card explains what suspension actually does on Windows and Linux, which ATT&CK techniques D3FEND relates it to, where it is implemented, how to prove a suspension held, and where it fails. It is written for incident responders, EDR operators and detection engineers who already work from the Incident Response Guide and need a precise view of this one containment action.
Key takeaways
- Suspend to look, terminate to remove. D3FEND's own rationale is that defenders may suspend rather than terminate so they can analyse the process first and resume it if it turns out to be benign.
- It is reversible by design, including by the attacker. A Windows thread runs again when its suspend count returns to zero, and a Linux process stopped with SIGSTOP runs again on SIGCONT, so anyone with equal rights on the host can undo the action.
- The freezer is stronger than a signal. On Linux the cgroup v2 freezer stops every process in a group and, according to Docker's documentation, the process is not aware it was paused, whereas a SIGSTOP stop is visible to the process tree.
- D3FEND relates it to credential theft and persistence. The artefact mapping links D3-PS through the Process artefact to LSASS Memory (T1003.001), Security Account Manager (T1003.002), LSA Secrets (T1003.004), Web Shell (T1505.003), Netsh Helper DLL (T1546.007), Code Signing Policy Modification (T1553.006) and Ignore Process Interrupts (T1564.011).
- Suspension is a holding action, not eviction. Persistence, injected code in other processes, child processes and stolen credentials are untouched, so a suspension must be followed by evidence capture and then termination or resumption within a defined time.
D3-PS at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-PS (d3f:ProcessSuspension) |
| Tactic | Evict |
| Parent technique | Process Eviction (D3-PE), defined as techniques that terminate or remove running processes |
| Digital artefact | Process (D3FEND relation: suspends Process) |
| Sibling | Process Termination (D3-PT) |
| Tool named by D3FEND | PsSuspend from the Sysinternals suite, for local or remote Windows systems |
| What it changes | Stops a process's threads from being scheduled while keeping its memory, handles and identity intact |
| Typical operators | EDR and live response consoles, incident responders with administrative access, container and service managers |
| Main limitation | Reversible by anyone with equivalent rights, and it does nothing about persistence or code already running elsewhere |
How suspension works on each platform
D3FEND's description is brief: a process showing anomalous, unauthorised or malicious behaviour may be suspended to mitigate its immediate effects. The mechanics differ by platform, and the differences matter for whether the suspension holds.
Windows
- Thread suspend counts: Windows suspends threads, not processes. Microsoft's SuspendThread documentation explains that each call increments the thread's suspend count, a thread with a count above zero stops executing user-mode code, and ResumeThread decrements the count. The handle needs the THREAD_SUSPEND_RESUME access right. Suspending a process means suspending every one of its threads.
- PsSuspend: the Sysinternals utility D3FEND cites suspends or resumes (-r) a process by ID or by name, locally or on a remote computer. Microsoft notes that a remote suspension needs administrative rights on the remote system, and that the -p option puts a password on the command line, which should be avoided outside controlled automation.
- Deadlock risk: Microsoft warns that suspending a thread that owns a synchronisation object such as a mutex or critical section can deadlock anything that then waits for that object. This is why suspending system processes, or processes that share locks with critical services, can hang a host.
Linux and containers
- SIGSTOP and SIGCONT: the signal(7) manual states that SIGKILL and SIGSTOP cannot be caught, blocked or ignored. SIGSTOP's default action is Stop and SIGCONT resumes a stopped process. SIGTSTP, the terminal stop signal, can be handled by the process, so it is not a reliable containment tool.
- cgroup v2 freezer: writing 1 to a cgroup's cgroup.freeze file freezes that cgroup and all descendants; processes stop and stay stopped until the cgroup is unfrozen, and cgroup.events shows frozen 1 when the freeze completes. The kernel documentation notes that frozen processes can still be terminated by a fatal signal, and that a process moved out of a frozen cgroup becomes runnable again.
- systemd units: systemctl freeze and thaw (systemd 246 and later, unified cgroup hierarchy only) apply the freezer to a whole service. systemd automatically thaws a unit just before it executes a job against it, such as a stop, so a frozen unit does not stay frozen through a restart.
- Containers: docker container pause uses the freezer cgroup on Linux, and Docker documents that, unlike SIGSTOP, the paused process is unaware of the suspension. On Windows only Hyper-V isolated containers can be paused.
ATT&CK techniques D3FEND relates to D3-PS
Relationship type: inferred only. D3FEND does not hand-map D3-PS to ATT&CK. Every row below is inferred through a shared digital artefact: D3-PS suspends Process, so ATT&CK techniques that access, produce or create a Process are related to it (D3FEND 1.6.0, checked November 2026). D3FEND labels these relations inferred. The first seven rows act on the Process artefact itself; the last three act on a kind of process, such as an operating system process or a scheduled job, and appear on the D3FEND technique page. D3FEND still lists Disable or Modify Tools under an ID that ATT&CK v20 has revoked; its successor is T1685. Each ID was checked against ATT&CK v20.
| ATT&CK ID | Technique | D3FEND relation (inferred via artefact) | What suspension buys the defender |
|---|---|---|---|
| T1003.001 | LSASS Memory | Same artefact: accesses Process | Freezes the dumping process before it writes or exfiltrates the dump, and preserves its memory for analysis. Suspend the dumper, never LSASS itself. |
| T1003.002 | Security Account Manager | Same artefact: may access Process | Halts a process reading SAM material while its command line and handles are captured |
| T1003.004 | LSA Secrets | Same artefact: may access Process | Same as above for LSA secrets, which often include service account passwords |
| T1505.003 | Web Shell | Same artefact: produces Process | Stops a shell process spawned by the web server so its commands and network connections can be examined |
| T1546.007 | Netsh Helper DLL | Same artefact: produces Process | Freezes the process started through the helper DLL while the registry change is investigated |
| T1553.006 | Code Signing Policy Modification | Same artefact: may create Process | Holds a process launched after signing enforcement was weakened |
| T1564.011 | Ignore Process Interrupts | Same artefact: creates Process | Attackers use nohup and similar options so processes survive hangups. SIGSTOP and the freezer cannot be ignored this way. |
| T1053.005 | Scheduled Task | Sub-artefact: scheduled job | Freezes the task's running instance; the task definition still runs it again later |
| T1505.002 | Transport Agent | Sub-artefact: message transfer agent | Holds a malicious mail transport component, at the cost of stopping mail flow on that server |
| T1685 | Disable or Modify Tools | Sub-artefact: operating system process | The same mechanism attackers use against security agents; see Limits below |
Treat this table as a guide to where suspension helps, not a coverage claim. Deeper defensive coverage is in T1003 OS Credential Dumping, the T1505 Server Software Component Defensive Guide, the T1546 Event Triggered Execution Defensive Guide and MITRE ATT&CK T1553 Subvert Trust Controls.
Where it is implemented
| Implementation class | Mechanism | Scope | Fits when |
|---|---|---|---|
| Native Windows tooling | PsSuspend, or debugger and live response tools that call the thread suspend APIs | One process by PID or all processes with a name | An administrator is on the host or has remote admin rights |
| Linux signals | kill -STOP and kill -CONT | One process; children are not stopped unless signalled as a group | Quick hold of a single process during live response |
| cgroup v2 freezer | cgroup.freeze, systemctl freeze | Every process in the cgroup and its descendants, including new forks that land in it | A whole service, user session or container must be held at once |
| Container runtimes | docker container pause and equivalent runtime pause operations | All processes in the container | A compromised container must be held for image and memory capture |
| EDR and live response consoles | Agent-side suspend or freeze actions where the product offers them, alongside kill, quarantine and host isolation | Process, process tree or host, depending on product | Responders work at scale across a fleet; check your product's documentation for whether a suspend action exists and how it is logged |
The parent page for the whole family, Process Eviction (D3-PE), is summarised in the MITRE D3FEND Guide. For the wider choice between holding, isolating and removing, see the Incident Scoping and Containment Strategy Guide.
When to suspend and when to terminate
| Situation | Prefer | Reason |
|---|---|---|
| Unknown process, behaviour suspicious but not yet confirmed | Suspend | Allows analysis and a clean resume if benign, which is D3FEND's stated rationale |
| Confirmed malware with in-memory payload or keys worth recovering | Suspend, capture memory, then terminate | Termination first loses decrypted configuration, injected code and session material |
| Active encryption or destruction of data | Isolate the host and terminate | Every second of runtime costs data; a reversible hold is the wrong trade |
| Process shares locks with critical services, or is a system process | Neither on the process; isolate the host | Suspension can deadlock the host and destroys availability |
| Attacker holds administrative rights on the host | Isolate the host, then act | The attacker can resume a suspended process with the same rights |
| Production service where a pause causes cascading failures | Agree a maximum hold time with the service owner in the runbook | Timeouts in callers and health checks can trigger restarts that destroy the evidence |
Implementation steps
- Decide who may suspend what. Write down in the incident runbook which roles may suspend processes, on which asset classes, and a deny list of processes that must never be suspended (for example LSASS, csrss and wininit on Windows, PID 1 and the container runtime on Linux).
- Prepare the tooling. Confirm your EDR or live response tool's suspend action, or stage PsSuspend and the freezer commands in your response toolkit. Avoid passing passwords on the command line; use the responder's own authenticated session.
- Capture before acting where possible. Record the process ID, parent, command line, user, loaded modules and open network connections. Then suspend.
- Suspend the right scope. For a single process use the thread suspend or SIGSTOP route. For a process tree, a service or a container use the freezer, because it also catches children and new forks.
- Collect evidence while frozen. Take a process memory dump and, where the case warrants it, a full memory image. The Memory Forensics Guide covers acquisition and analysis.
- Decide within the hold time. Either resume with a recorded justification, or terminate and move to eradication of persistence. Do not leave suspended processes unattended.
- Roll back cleanly. Resume with pssuspend -r, SIGCONT, systemctl thaw or docker container unpause, and confirm the process returns to a running state and the service health checks pass.
How to verify it works
- State check: on Linux, the process state in ps or /proc/<pid>/status shows T (stopped) after SIGSTOP, and cgroup.events shows frozen 1 for a frozen cgroup. On Windows, process tools and the EDR console show the threads as suspended.
- Activity check: CPU time stops increasing, and no new file, registry or network events are attributed to the process after the suspension timestamp.
- Persistence check: watch for a fresh instance of the same binary or command line starting elsewhere, which shows the suspension held but the cause was not removed.
- Tamper check: alert on any resume of a process that responders suspended, unless the resume came from the response team. A resume you did not issue is an indicator the attacker still has control.
- Exercise: include suspend, capture and resume in tabletop and technical exercises on a test host, timing each step.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Time from alert to suspension for confirmed malicious processes | Under 10 minutes | Limits credential theft and command execution |
| Suspensions followed by memory capture | Above 90% | The point of suspending rather than killing is the evidence |
| Suspensions resolved (resumed or terminated) within the agreed hold time | 100% | Stops forgotten frozen processes and service impact |
| Unexpected resumes of suspended processes | Zero, each one investigated | An unexplained resume indicates attacker control |
| Host hangs caused by suspension | Zero | Shows the deny list and scope rules work |
Limits, bypasses and failure patterns
- The attacker resumes it: suspension is reversible by design. An adversary with administrative or SYSTEM rights can resume the process, or move it out of a frozen cgroup, which makes it runnable again. Isolate the host when the attacker's privilege level is unknown.
- Suspending the wrong process: freezing LSASS to stop a credential dump, or a process holding a lock that a critical service needs, can hang the machine. Freeze the actor, not the victim.
- Only part of the tree is frozen: SIGSTOP to one PID leaves children, siblings and injected threads in other processes running. Use the freezer for groups and check for injection before declaring containment.
- Persistence restarts the work: a scheduled task, service or web shell file launches a new process minutes later. Suspension must be followed by removal of the persistence; see the Web Shell Response Playbook for one common case.
- The defender's tool is the target: attackers also stop processes. Disabling or suspending security agents is covered by the T1685 Disable or Modify Tools Defensive Guide; protect your agents and alert when one stops reporting.
- Restarts erase the hold: systemd thaws a frozen unit before running a job against it, and orchestrators restart unhealthy containers. Coordinate with platform owners so automation does not undo the suspension.
Where identity fits
Credential dumping processes are the main reason D3FEND links D3-PS to ATT&CK, and LSA secrets frequently hold service account passwords. Suspending the dumper stops further theft but does not invalidate anything already read, so treat every credential that process could reach, including service accounts and machine credentials, as exposed and rotate or revoke it. See D3-CCSA Credential Compromise Scope Analysis and D3-CR Credential Revocation.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IR-4 Incident Handling, IR-4(1) Automated Incident Handling Processes | Containment as part of incident handling, including automated suspend actions |
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring | The detection that identifies the process to suspend and the monitoring that confirms the hold |
| NIST CSF 2.0 | RS.MI-01 Incidents are contained; RS.MI-02 Incidents are eradicated | Suspension contributes to containment; eradication follows |
| NIST SP 800-61 Rev 3 | Incident response as a CSF 2.0 Community Profile | The current NIST incident response recommendations, which superseded Rev 2 in April 2025 |
| MITRE D3FEND | D3-PE, D3-PS | Parent and technique |
Related countermeasures
- Process Termination (D3-PT): the sibling that ends the process; usually the step after a suspension.
- Host Shutdown and Host Reboot: host-level eviction when process-level action is unsafe. See D3-HS Host Shutdown and D3-HR Host Reboot.
- File Eviction: removes the binaries and scripts that would restart the process. See D3-FEV File Eviction.
- Process Spawn Analysis: the detection side that often identifies which process to suspend. See D3-PSA Process Spawn Analysis.
Practitioner checklist
- Keep a never-suspend list of system and critical service processes in the runbook.
- Record PID, parent, command line, user and connections before suspending.
- Use the cgroup freezer, not single signals, for process trees, services and containers.
- Capture process memory while suspended, before any termination.
- Set and enforce a maximum hold time agreed with service owners.
- Alert on any resume of a suspended process that the response team did not issue.
- Isolate the host first when the attacker may hold administrative rights.
- Remove persistence before closing the case, and rotate credentials the process could reach.
- Exercise suspend, capture and resume on test hosts at least once a year.
Standards and references
- MITRE D3FEND: Process Suspension (D3-PS)
- NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- Microsoft Learn: PsSuspend
- Microsoft Learn: SuspendThread function
- Linux man-pages: signal(7)
- Linux kernel documentation: Control Group v2
- systemd: systemctl manual (freeze and thaw)
- Docker Docs: docker container pause
Related NHI Mgmt Group resources: Incident Response Guide · Incident Scoping and Containment Strategy Guide · Memory Forensics Guide · EDR Guide · MITRE D3FEND Guide