Process tree analysis: how SOC teams trace an attack

When an alert fires, your first question is never “what happened?” - it’s “how far did it get?” A process tree is often the fastest path to that answer. Understanding how to read one is a core skill for any SOC analyst, and knowing what your EDR is actually capturing makes the difference between closing a ticket and stopping a breach.

What a process tree tells you

Every process on a modern operating system has a parent. When cmd.exe spawns powershell.exe, which spawns whoami.exe, that chain is preserved in the kernel. EDR agents record it continuously - not just the process name, but the command line, user context, working directory, network connections, and file writes for each node.

A process tree isn’t a single snapshot. It’s a timeline of activity anchored to parent-child relationships. When you expand a suspicious process in your EDR dashboard, you’re reading that timeline from the bottom up - from the alert that fired, back through the execution chain to wherever the attacker first got a foothold.

A classic example looks like this:

explorer.exe (PID 1234)
  └─ winword.exe (PID 5678)   ← user opens malicious .docx
       └─ cmd.exe (PID 9012)  ← macro drops a shell
            └─ powershell.exe (PID 3456)  ← downloads stager
                 └─ regsvr32.exe (PID 7890)  ← executes payload

The alert might fire on regsvr32.exe executing an unsigned DLL. But the process tree shows the full story: this started with a Word document. Now you know the user, the file they opened, and the fact that the initial access was phishing rather than, say, a compromised service account.

Reading parent-child relationships for attacker technique

MITRE ATT&CK (T1055, T1059, and others) documents the most common process relationships attackers abuse. A handful of patterns account for the majority of what you’ll see in the wild:

Unusual parent for a common binary. powershell.exe spawned by mshta.exe or wscript.exe is suspicious. The same binary spawned by a legitimate administrative tool is probably fine. Context is everything - process trees give you that context at a glance.

Short-lived child processes that write files. A parent process that spawns a child for less than two seconds, which writes an executable to a temp directory, almost always signals a dropper. The child process exits before most EDRs without full telemetry would even record it.

Living-off-the-land binaries (LOLBins). Attackers routinely abuse signed Windows binaries to avoid detection: certutil.exe to download files, regsvr32.exe to load COM objects, msiexec.exe to execute remote MSIs. The binary itself isn’t malicious - the parent context makes it suspicious.

Process hollowing and injection. With process injection (MITRE T1055), the parent-child tree can look completely normal because the attacker is running malicious code inside a legitimate process. Here, thread-level events and memory write telemetry matter as much as the process tree itself.

How to trace an attack from first alert

When a behavioural alert fires, work the tree in both directions:

1. Go up (parent traversal). Find the oldest ancestor that doesn’t belong. Is the chain rooted in a browser, an email client, a document editor? That’s your initial access vector. Is it rooted in a system service? Possible supply-chain issue or service account compromise.

2. Go sideways (sibling processes). Did the same parent spawn anything else around the same time? Credential dumpers (LSASS access, comsvcs.dll MiniDump calls) often appear as siblings to the main payload.

3. Go down (child enumeration). What did the suspicious process do after the alert fired? Network connections to unusual IPs, file drops to startup folders, registry writes for persistence - these all appear in the child activity.

4. Cross-reference with 90-day telemetry. Was this parent process unusual on this host historically? A process that’s appeared on the same machine for months behaves differently to one that showed up two hours ago.

The 90-day telemetry window is worth emphasising. A lot of attacks rely on the fact that most EDR tools only keep short rolling logs. If an attacker established persistence three weeks ago and is only now activating it, you need historical data to see the full chain.

What makes process tree analysis hard at scale

The challenge for SOC teams isn’t reading a single tree - it’s triaging dozens of alerts across hundreds of endpoints without missing the one that matters. Process trees can be deep (10+ levels during lateral movement) and busy (a single endpoint generates thousands of process events per hour).

This is where automated triage genuinely helps. AI analysis can summarise the most suspicious nodes in a tree, flag known-bad parent-child combinations from threat intel, and surface the chain most likely to represent real attacker activity - so an analyst can confirm or dismiss in seconds rather than manually expanding nodes.

If your team is spending more time clicking through process trees than thinking about what the trees mean, that’s worth fixing. Reach out at /company/#contact to see how LightEDR handles process telemetry and alert triage in practice.