A runtime child process is a new process spawned by an application while it is running. In exploitation scenarios, that detail matters because attacker-controlled code often appears as a child of the legitimate service, making it harder to distinguish from normal execution without process monitoring.
What a runtime child process is
A runtime child process is created while a parent application is already running. That distinction matters because the child inherits the parent’s execution context, which makes process lineage a useful signal for normal behaviour, abuse, or compromise.
Why process ancestry matters for security
In defensive monitoring, process trees help separate expected application behaviour from suspicious execution paths. A child process launched by a trusted service may be legitimate, but it can also be the first visible sign that code execution moved from the application into a new process boundary.
That is why process ancestry is often paired with telemetry such as command line, parent process, signer, user context, and timing. None of those fields prove maliciousness on their own, but together they show whether a child process fits the parent application’s normal runtime pattern.
How attackers abuse runtime child processes
Attackers often prefer child processes because they can blend into normal service activity and ride on a process that defenders already trust. If the parent is a widely used application or daemon, the spawned child may look like ordinary operational noise unless monitoring is tuned to the expected process tree.
Runtime child processes are especially important in post-exploitation activity, where a foothold inside one application can be used to start another process for staging, command execution, or privilege escalation. The child process is not the attack itself, but it is often the mechanism that makes the attack visible.
For containerised workloads, runtime child processes are part of the runtime security picture as well, which is why guidance such as NIST SP 800-190 Container Security is relevant when the child process appears inside an application container.
Detection and investigation signals
The strongest investigations start by asking whether the child process is expected for that parent, that host, and that time of day. Sudden interpreter launches, shell spawning, or unusual binaries started by a service often deserve closer review than a routine worker process.
Security teams usually correlate process creation with authentication context, network activity, and file or registry changes to understand what the new process was trying to do. Process monitoring alone is useful, but it becomes much stronger when it is compared with baseline application behaviour and known-good parent-child relationships.
Broader detection and response programs often anchor that work in controls such as NIST SP 800-53 Rev 5 Security and Privacy Controls and adversary mapping such as MITRE ATT&CK Enterprise Matrix, because both help translate a suspicious child process into a broader security narrative.
Risk and Threat Considerations
Runtime child processes create risk because they blur the boundary between legitimate application behaviour and attacker activity. When a compromised service can spawn a new process, defenders may see only a trusted parent and miss the malicious command being executed underneath it.
Failure mechanism: The parent application becomes a convenient launch point for unapproved code, and normal-looking process ancestry can hide shell spawning, payload execution, or lateral movement steps.
Impact: The result can be stealthier compromise, slower detection, and a wider blast radius if the child process gains access to the parent’s permissions, data, or network reach.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | Runtime child processes are detected through process and event monitoring. |
| AU-12 — Audit Record Generation | Process creation events must be logged to support investigation of suspicious child processes. | |
| CM-7 — Least Functionality | Restricting what an application can launch reduces abuse of runtime child processes. | |
| Recommendation — Monitor parent-child process creation patterns for unexpected execution paths. Generate and retain process-creation audit records for investigation. Limit services to only the executables they legitimately need. | ||
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Suspicious child processes often materialize as interpreter or shell execution by a trusted parent. |
| T1106 — Native API | Malware may create child processes through native OS process-creation mechanisms. | |
| Recommendation — Hunt for interpreter launches spawned by trusted applications. Correlate native process-creation activity with suspicious parent process lineage. | ||
Practitioner Guidance
What to watch for: Treat unexpected child processes as an investigation trigger, not as proof of compromise. Focus first on whether the parent application should ever launch that binary, interpreter, or command path in normal operation.
Governance implication: Teams should define baseline parent-child relationships for critical services and review them as part of application hardening and monitoring. That baseline is especially important when services are allowed to run with elevated rights or broad network access.
Practitioner takeaway: The key question is not just “what process started,” but “does this process tree make sense for this application’s role and permissions?”