An approved application is not automatically a safe application. Microsoft Word, a web browser, PowerShell, Windows Management Instrumentation (WMI), and other legitimate tools all serve valid business purposes. They can also become links in an attack chain when one process launches another.
That relationship matters because malware does not always arrive as an obvious, standalone executable. An attacker may instead exploit or manipulate a trusted application and use it to start a command shell, script interpreter, system utility, or downloader. Each new process gives the attacker another way to execute code, collect information, establish persistence, or move toward sensitive data.
Controlling child processes helps stop that sequence at the point where trusted software attempts to do something it should not. It shifts endpoint security from simply recognizing applications to enforcing how those applications are allowed to behave.
What is a child process?
A process is a running instance of an application or service. When that process starts another process, the new one is called its child process.
Many parent-child relationships are routine. A software installer may launch a helper, a management platform starts a maintenance script, and a browser creates separate processes to isolate tabs or extensions.
The existence of a child process is not inherently malicious; context determines that.
A browser creating its normal rendering processes is common. A browser spawning a shell that runs curl, wget, or an encoded script deserves immediate scrutiny.
This is why effective child process control must be precise. Blocking every child process would interrupt legitimate work. Allowing every trusted application to launch anything leaves a valuable execution path open to attackers.
Why attackers rely on process chains
Modern attacks often depend on chaining together capabilities that already exist on the endpoint. Rather than introducing a complete toolkit at once, an attacker may use one trusted application to invoke another, then use that second tool to perform the next stage of the attack.
MITRE ATT&CK identifies abnormal parent-child process relationships as an important endpoint behavior to detect and block. Microsoft also provides attack surface reduction rules designed to prevent Office applications and certain communication tools from creating child processes.
A malicious document, compromised website, vulnerable application, or social-engineering prompt can provide the starting point. From there, the attacker may attempt to launch PowerShell, Command Prompt, a scripting engine, WMI, or another legitimate system binary. These tools can then retrieve additional code, change system settings, access files, communicate externally, or execute commands in memory.
This approach is attractive because the individual applications may be signed, approved, and widely used, and a security product focused primarily on file reputation or known malicious signatures may only see trusted components, even while the relationship between them reveals suspicious behavior.
Common high-risk parent-child relationships
Organizations should base policy on their environment, but several relationships regularly warrant restriction or close review:
- Office applications launching PowerShell, Command Prompt, WMI, script hosts, or unfamiliar executables
- Web browsers spawning shells, scripting interpreters, download utilities, or administrative tools
- PDF readers or other document viewers starting command-line utilities or scripts
- Email and collaboration applications launching executable content or system tools
- Scripting engines starting additional interpreters, remote access tools, or utilities unrelated to an approved workflow
- Internet-facing or frequently exploited applications launching processes outside their normal operating pattern
These behaviors are not universally malicious. Developers, IT administrators, automation tools, accessibility software, and update mechanisms may create unusual-looking process trees for valid reasons. Policies should account for those requirements without turning broad exceptions into permanent attack paths.
Detection is useful. Prevention changes the outcome.
Endpoint detection and response tools can identify suspicious process trees and alert a security team. That visibility is valuable for investigation, especially when analysts can review the parent process, child process, command line, user, file activity, and network connections together.
However, an alert does not necessarily prevent execution. If a browser launches a shell that immediately retrieves or runs malicious code, the attacker may gain a foothold before an analyst can investigate. Security teams must then determine what executed, what changed, which credentials or data were exposed, and whether the activity has spread.
Prevention changes the sequence.
When policy says that a browser cannot launch PowerShell, the process creation is denied before the next command runs. The same principle stops Word from invoking a script host or prevents an exploited application from calling an unauthorized utility.
Detection remains part of a layered strategy, but enforcing acceptable behavior reduces dependence on perfect detection and immediate human response. It also helps contain unknown threats whose payload, hash, domain, or technique has not yet been cataloged.
Application allowlisting is the foundation, not the finish line
With deny-by-default application allowlisting, if an unknown executable appears on an endpoint, it will not be able to execute simply because a user clicked it or another process called it.
This is the starting point.
Attackers also abuse software that organizations must allow, such as PowerShell and Office applications. Approving these applications without limiting their behavior can leave room for tool chaining and living off the land attacks.
Controlling child processes requires applying the principle of least privilege to your application behavior. It permits required workflows while removing unnecessary relationships between programs.
How ThreatLocker Ringfencing controls application behavior
ThreatLocker Allowlisting controls what can run. ThreatLocker Ringfencing™ adds the additional layer that controls what approved applications can do after they start.
With Ringfencing, organizations can define how applications interact with other applications, files, registry locations, and network resources. This includes restricting child process execution. For example, a business may allow Word to open documents while preventing it from launching PowerShell or allow a browser to operate normally while stopping it from spawning command-line utilities.
That distinction preserves application usability while breaking behaviors that attackers depend on. If a trusted application is exploited, the attacker does not automatically inherit unrestricted access to every tool and resource available to the user.
Allowlisting and Ringfencing work together as complementary controls and part of the greater Application Control framework:
- Allowlisting decides whether an application can execute.
- Ringfencing determines which applications it can launch and which resources it can access.
- Privileged Access Management controls whether an approved application can run with elevated rights and under what conditions.
Together, these controls reduce the number of paths an attacker has to turn an initial foothold into a wider compromise.
How to implement child process control without disrupting work
1. Observe normal process relationships
Start by understanding how applications behave across representative users and endpoints. Capture legitimate parent-child relationships, including updates, plug-ins, assistive technologies, automation, administrative workflows, and line-of-business dependencies.
2. Prioritize commonly abused applications
Begin with applications most likely to become attack launch points, such as Office programs, browsers, PDF readers, scripting engines, command shells, and remote management tools. Restrict relationships that are rarely required and offer attackers significant leverage.
3. Use specific exceptions
When a legitimate workflow requires an otherwise risky relationship, scope the exception to the appropriate application, user or group, endpoint, path, or business process. Avoid broad rules that allow any parent process to launch a powerful tool.
4. Combine process controls with resource boundaries
Stopping an unauthorized child process is powerful, but application containment should also address file, registry, and network access. A permitted tool should not automatically be able to reach sensitive data, modify persistence locations, or connect to arbitrary external destinations.
5. Review and refine policies
Applications and workflows change. Use audit data, blocked-event reviews, and stakeholder feedback to refine policy. Remove obsolete exceptions and investigate unexpected relationships rather than normalizing them without review.
Control the chain, not just the starting point
Attackers rarely reach their objective in one step. They combine applications, interpreters, system utilities, network connections, and permissions into a chain. Endpoint security is stronger when it governs those relationships instead of trusting each component in isolation.
Child process control makes that principle enforceable. By deciding which applications can launch other applications, organizations can block high-risk behavior before it becomes an incident. Combined with deny-by-default allowlisting and granular Ringfencing policies, it helps keep trusted software useful without giving attackers an unrestricted path through the endpoint.
See how ThreatLocker helps you control what applications can run and what they are allowed to do. Book a demo today
FAQs
What is a child process in cybersecurity?
A child process is a process started by another running process, known as its parent. Security teams should analyze this relationship because an unexpected parent can reveal that a trusted application is being exploited or misused to execute another tool.
Are child processes malicious?
Not necessarily. Applications routinely create child processes for legitimate functions. Risk depends on context, including the parent, the child, command-line arguments, user, endpoint, and expected business workflow.
Why would an attacker use a trusted application to launch another process?
Trusted tools may already be approved and available on the endpoint. Chaining them can help an attacker execute scripts, download payloads, alter configurations, or access data while reducing reliance on an obvious malware executable.
What is the difference between detecting and blocking a child process?
Detection creates visibility or an alert after suspicious behavior is observed. Blocking prevents the process relationship from executing, which can break the attack chain before the child process performs its intended action.
How does ThreatLocker help control child processes?
ThreatLocker Ringfencing allows organizations the ability to restrict or limit how applications interact, including which other applications they may launch. Used with Allowlisting and Privileged Access Management, ThreatLocker controls what can run, what approved software can do, and when elevated rights are available.
