T1036.009: Break Process Trees
An adversary may attempt to evade process tree-based analysis by modifying executed malware's parent process ID (PPID). If endpoint protection software leverages the “parent-child" relationship for detection, breaking this relationship could result in the adversary’s behavior not being associated with previous process tree activity. On Unix-based systems breaking this process tree is common practice for administrators to execute software using scripts and programs.[1]
On Linux systems, adversaries may execute a series of Native API calls to alter malware's process tree. For example, adversaries can execute their payload without any arguments, call the `fork()` API call twice, then have the parent process exit. This creates a grandchild process with no parent process that is immediately adopted by the `init` system process (PID 1), which successfully disconnects the execution of the adversary's payload from its previous process tree.
Another example is using the “daemon” syscall to detach from the current parent process and run in the background.[2][3]
Analyst context for executives and security teams
Break Process Trees matters because it can make Linux and macOS activity look disconnected from the process that launched it. If defenders rely heavily on parent-child process relationships, malicious activity may appear as a background or system-adopted process rather than part of the original execution chain. This is especially important because similar behavior can also be normal administrative daemonization, so the business risk is not just missing stealthy activity but also creating noisy detections that analysts learn to ignore.
Executive priority
Security leaders should treat this as a validation point for endpoint visibility and SOC triage quality on Unix-like systems. Ask whether investigations can reconstruct execution lineage when a process detaches from its parent, whether Linux/macOS telemetry is retained with enough detail for incident response, and whether controls distinguish legitimate daemon behavior from suspicious masquerading. This is relevant to operational resilience, audit evidence, and IR readiness because weak process lineage can delay scoping and containment decisions.
Technical view
This is a Linux and macOS sub-technique of Masquerading under the stealth tactic. The supplied ATT&CK description focuses on adversaries altering or breaking parent process ID lineage so endpoint tools do not associate later behavior with earlier execution. SOC and detection teams should validate DET0443, Detection Strategy for Masquerading via Breaking Process Trees, against local Unix telemetry and tune it around detached processes, orphaned processes, daemon-style execution, and processes adopted by PID 1 or the init system. Because administrative scripts and programs commonly detach processes on Unix-based systems, detection should correlate process lineage anomalies with command context, executable path, user/account context, persistence indicators, network activity, and other suspicious behavior rather than alerting on detachment alone.
Likely telemetry
- Linux and macOS process creation events with process ID and parent process ID
- Process lineage history before and after parent termination or detachment
- Executable path, command-line arguments where available, user/account, working directory, and timestamp context
- Init/PID 1 adoption or orphaned process observations
- Endpoint detection or audit logs that preserve parent-child relationships over time
Detection direction
- Validate whether process-tree analytics still preserve ancestry when a Unix process detaches or is adopted by init/PID 1.
- Use DET0443 as the ATT&CK-aligned detection strategy reference, but test it against normal daemonization and administrator scripts to understand false positives.
- Correlate broken lineage with suspicious execution context instead of treating all orphaned or daemonized processes as malicious.
- Prioritize detections where a newly detached process also shows unusual executable location, unexpected user context, command behavior, network communications, or other masquerading signals.
- Confirm that EDR, audit, and SIEM pipelines retain enough process history to reconstruct the original execution chain during incident response.
Mitigation priorities
- First, close telemetry gaps: ensure Linux and macOS process creation, parent process ID, user, path, and timing data are collected and retained for investigation.
- Second, tune SOC content for Unix administrative norms so normal daemonization does not overwhelm analysts.
- Third, strengthen incident response playbooks to reconstruct process lineage beyond simple parent-child views, including adopted or orphaned processes.
- Fourth, use least-privilege and administrative control review to reduce unnecessary background execution paths where business operations allow.
- Fifth, align evidence collection with compliance and audit needs by demonstrating that Unix endpoint activity can be traced even when process trees are intentionally broken.
Analyst notes and limits
The ATT&CK object does not provide an official detection paragraph, but it has a relationship to DET0443, a detection strategy for masquerading via breaking process trees. The technique is explicitly scoped to Linux and macOS for this sub-technique, with relationship examples including BPFDoor on Linux and Shai-Hulud across Linux, SaaS, and Windows; for this specific behavior, platform claims should remain limited to the technique’s supported Linux and macOS scope.
This take is based only on the supplied ATT&CK fields, external references, and relationships. Local conclusions require environment-specific telemetry review, baseline knowledge of legitimate Unix daemonization, and validation of endpoint/SIEM process lineage retention. No claim is made that this behavior is currently present, actively exploited in the reader’s environment, or guaranteed to be detected by any specific tool.
Break Process Trees
An adversary may attempt to evade process tree-based analysis by modifying executed malware's parent process ID (PPID). If endpoint protection software leverages the “parent-child" relationship for detection, breaking this relationship could result in the adversary’s behavior not being associated with previous process tree activity. On Unix-based systems breaking this process tree is common practice for administrators to execute software using scripts and programs.[1]
On Linux systems, adversaries may execute a series of Native API calls to alter malware's process tree. For example, adversaries can execute their payload without any arguments, call the `fork()` API call twice, then have the parent process exit. This creates a grandchild process with no parent process that is immediately adopted by the `init` system process (PID 1), which successfully disconnects the execution of the adversary's payload from its previous process tree.
Another example is using the “daemon” syscall to detach from the current parent process and run in the background.[2][3]
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1036 | Masquerading | This object subtechnique of Masquerading. |
Groups, software, and campaigns
S1161: BPFDoor
BPFDoor is a Linux based passive long-term backdoor used by China-based threat actors. First seen in 2021, BPFDoor is named after its usage of Berkley Packet Filter (BPF) to execute single task instructions. BPFDoor supports multiple protocols for communicating with a C2 including TCP, UDP, and ICMP and can start local or reverse shells that bypass firewalls using iptables.[1][2]
S9008: Shai-Hulud
Shai-Hulud is a supply chain worm, first reported in September 2025, that spreads through code repositories, including GitHub and NPM packages. It exploits CI/CD pipeline dependencies to propagate to victims and poisons the supply chain by publishing malicious packages. Once inside a victim environment, Shai-Hulud steals credentials and access tokens from compromised repository accounts and exfiltrates them to attacker-controlled servers via encoded GitHub Actions workflows.[1][2][3][4][5][6][7]
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.0 | Current bundle | 14b20b81589a… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
3OHA double-fork 2022
Juan Tapiador. (2022, April 11). UNIX daemonization and the double fork. Retrieved September 29, 2023.
Open source URL -
[2]
Sandfly BPFDoor 2022
The Sandfly Security Team. (2022, May 11). BPFDoor - An Evasive Linux Backdoor Technical Analysis. Retrieved September 29, 2023.
Open source URL -
[3]
Microsoft XorDdos Linux Stealth 2022
Microsoft Threat Intelligence. (2022, May 19). Rise in XorDdos: A deeper look at the stealthy DDoS malware targeting Linux devices. Retrieved September 27, 2023.
Open source URL -
[4]
mitre-attack T1036.009Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.