A spawned process that continues running after the parent exits. Attackers use detached processes to preserve execution, hide activity from the original parent, and maintain background tasks such as downloaders, implants, or command runners without an obvious interactive session.
Expanded Definition
A detached child process is a spawned process that survives after its parent terminates, so its execution no longer depends on an interactive shell, job control session, or a visible foreground workflow. In NHI security, that persistence matters because autonomous software, downloaders, and post-exploitation tooling can continue operating even after the original launcher disappears. The concept is closely related to process inheritance and session detachment, but it is not the same as legitimate daemonisation or service management, which are designed, monitored, and governed as part of a normal operating model. Definitions vary across vendors when the term is used loosely to describe any background process, but in practice the security concern is persistence without clear ownership, logging, or control. NIST’s control language around process monitoring and least functionality helps frame why this behaviour is suspicious when it is not expected for the workload, especially under NIST SP 800-53 Rev 5 Security and Privacy Controls. The most common misapplication is treating every background task as benign, which occurs when teams fail to distinguish managed services from orphaned execution that persists after the parent exits.
Examples and Use Cases
Implementing detection for detached child processes rigorously often introduces more telemetry volume and tuning effort, requiring organisations to weigh detection fidelity against operational noise.
- A malicious shell spawns a downloader, then exits so the payload continues in the background without an obvious parent process chain.
- An agentic AI workflow launches a helper process that detaches to continue tool execution after the orchestrator crashes or is killed.
- A compromised service account starts a long-running implant from a CI/CD runner, and the process persists after the job wrapper ends.
- A post-exploitation script uses session detachment to keep command execution alive while reducing the chance of immediate operator observation.
- Legitimate automation may also detach for reliability, which is why ownership, expected runtime, and logging should be validated against the lifecycle guidance in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and correlated with process lineage rules in NIST SP 800-53 Rev 5 Security and Privacy Controls.
In practice, defenders look for parent termination followed by continued network activity, file writes, or repeated command execution from the child. Detached behaviour becomes much easier to interpret when the process is tied to a known service identity, scheduled task, or deployment pipeline rather than an unexplained interactive launch.
Why It Matters in NHI Security
Detached child processes are important because they help NHI abuse survive beyond the initial compromise window. A service account, API key, or agent token can be used to launch a process that outlives the parent session, making containment harder and forensic reconstruction less obvious. That is especially dangerous in environments where identity sprawl and poor visibility already reduce control over non-human execution. NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts, which means process-level persistence can remain hidden long enough to support lateral movement, data collection, or repeated task execution. For that reason, detached execution should be evaluated alongside secret handling, workload identity, and runtime monitoring, not as a standalone host anomaly. The lifecycle and visibility guidance in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs reinforces why orphaned child processes are often symptoms of broader governance failure, not isolated host noise. Organisational response also depends on interpreting the execution context against standards such as NIST SP 800-53 Rev 5 Security and Privacy Controls. Organisations typically encounter the operational impact only after an incident review finds a surviving payload, at which point detached child process analysis becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-06 | Detached child processes often indicate hidden runtime persistence for an NHI workload. |
| NIST CSF 2.0 | DE.CM-1 | Process monitoring is central to detecting unexpected detached execution. |
| NIST Zero Trust (SP 800-207) | PR.AA-5 | Detached processes can retain access beyond the original trust context. |
| NIST SP 800-53 Rev 5 | AU-6 | Audit review supports detection of unexpected process persistence and hidden execution. |
| CSA MAESTRO | TRUST-04 | Agentic systems may detach helper processes to continue tool use after orchestration ends. |
Constrain agent helpers so detached execution cannot outlive approved orchestration boundaries.
Related resources from NHI Mgmt Group
- Why do NHI programmes need stronger process ownership than many human identity programmes?
- How should organisations govern API partner onboarding as a non-human identity process?
- How can security teams apply GRC maturity benchmarks without creating process bloat?
- Should organisations use the same process for onboarding people and machine identities?
