Overview
Process trees show the parent-child relationships between processes, revealing how activity unfolded on an endpoint. This lesson covers reading them.
Learning objectives
- Explain what a process tree is.
- Describe reading process trees for investigation.
- Identify suspicious process relationships.
Core concept
A process tree is the parent-child hierarchy of processes on an endpoint — showing which process spawned which. EDR records this, and it's a primary investigation tool because attacks unfold as process chains: an initial process (e.g. a document viewer, a script interpreter) spawns child processes that carry out the attack. Reading the tree reveals the sequence and lineage of activity — what launched what — making both the attack chain and suspicious relationships visible. Certain parent-child relationships are inherently suspicious (e.g. an office document application spawning a command interpreter or scripting engine — unusual for normal use). Process trees turn scattered process events into a coherent story of what happened on the host.
How it works
The process tree links each process to its parent (the process that created it) and its children, forming a hierarchy. In investigation, the analyst reads it to reconstruct the attack chain: e.g. a phishing document opened in an application (parent) spawns a scripting/command interpreter (child) that downloads and runs a payload (grandchild) that establishes persistence and a network connection — each step visible as a node in the tree. Suspicious relationships stand out: a document/productivity application spawning a command shell or script engine, a normally-benign process spawning something it never should, unexpected chains leading to system utilities being abused ("living off the land"), or a process spawned from an unusual location. Because normal software has predictable process lineage, deviations are strong leads. The tree also shows timing and arguments (command lines), enriching the picture. Reading process trees is central to malware-alert investigation (module 8) — it's how the analyst reconstructs what the malware did and how, from initial execution through its actions — and to endpoint threat hunting. It turns EDR's recorded process telemetry into an understandable narrative of endpoint activity.
Practical example
Investigating an endpoint alert, the analyst opens the process tree. It shows a document application (opened from a phishing attachment) as the parent, which spawned a command/script interpreter — an inherently suspicious relationship (that application shouldn't launch a shell). The interpreter's child process downloaded and executed a payload, which in turn created a persistence entry and opened a network connection to an external address. Reading the tree top-to-bottom reconstructed the entire attack chain — from the phishing document through execution to persistence and C2 — with command-line arguments at each step. The process tree turned scattered events into a clear narrative of exactly what happened and how, guiding the investigation and scoping.
Cybersecurity relevance
Process trees are central to endpoint investigation because attacks unfold as process chains: the parent-child hierarchy reveals what launched what, reconstructing the attack chain from initial execution through payload, persistence, and C2. Suspicious relationships (a document app spawning a shell/script engine, abuse of legitimate utilities, unexpected lineage) are strong leads — normal software has predictable lineage, so deviations stand out. Reading process trees (with command-line arguments and timing) is how analysts investigate malware alerts (module 8) and hunt on endpoints (module 16), turning EDR's recorded process telemetry into an understandable narrative. It's a core EDR-driven skill for understanding exactly what happened on a host.
Common mistakes
- Ignoring parent-child relationships (missing suspicious lineage like a document app spawning a shell).
- Not examining command-line arguments that reveal what each process did.
- Failing to reconstruct the full chain (stopping at one process rather than tracing the tree).
Key takeaways
- A process tree is the parent-child hierarchy of processes (what spawned what), recorded by EDR — a primary investigation tool since attacks unfold as process chains.
- Reading it reconstructs the attack chain (initial execution → payload → persistence → C2) and exposes suspicious relationships (e.g. a document app spawning a shell/script engine).
- Normal software has predictable lineage, so deviations are strong leads; process trees (with arguments and timing) are central to malware investigation and endpoint hunting.
Check your understanding
- What does a process tree show, and why is it central to reconstructing an attack chain?
- What are examples of suspicious parent-child process relationships?