Process Tree Visualization for Security Investigations

When a security alert fires, the first questions are always the same: What spawned this process? What else did it do? Where did the attack chain start? Answering these from flat event logs is slow and error-prone. Process tree visualization makes the chain visible instantly.

The investigation bottleneck

Industry data consistently shows that mean time to investigate (MTTI) is one of the largest contributors to overall incident response time. Analysts spend the majority of their triage time not making decisions, but gathering context: correlating log entries, searching for parent processes, cross-referencing PIDs with timestamps, and mentally assembling the execution chain.

On a typical Linux server, a single compromised session can spawn dozens of short-lived processes in seconds. Each one appears as an isolated row in a log viewer. The analyst must:

• search for the alerting process by PID;
• find its parent PID, then search again;
• repeat upward until the chain becomes clear;
• separately search for children and lateral activity;
• correlate network connections, file writes, and DNS queries by timestamp and PID.

This manual process takes 15–30 minutes per alert even for experienced analysts. For junior team members, it can take hours — or lead to incorrect conclusions when a link is missed.

Why process lineage changes everything

Every process on Linux has a parent. Attackers rely on this chain:

• initial access spawns a child process;
• that child may escalate privileges, download tools, or pivot laterally;
• each step is a new process linked to its parent.

A single alert event shows only one node. The real story is the ancestry above it and the activity below it. Process tree visualization collapses the manual search-correlate-repeat cycle into a single view:

• Immediate root cause identification. Instead of searching upward PID by PID, the analyst sees the entire ancestor chain at once. Was the process spawned by sshd, cron, docker, or a web server? The answer is visible instantly.
• Blast radius assessment. Children of the suspicious process show what happened after the initial compromise. Did the attacker download additional tools? Spawn more shells? Move laterally? The tree reveals the full scope without additional queries.
• Correlated telemetry per process. File writes, network connections, DNS queries, and other security events are grouped by the process that generated them. This eliminates the need to cross-reference timestamps and PIDs manually.
• Faster escalation decisions. When a SOC analyst can see the full chain in seconds, they can escalate with confidence — or close a false positive without wasting senior resources.

The practical impact: investigations that took 20+ minutes of manual log correlation now take under 2 minutes from alert to understanding.

What SecureExec's process tree shows

SecureExec tracks process_guid — a unique identifier derived from PID, start time, and agent ID — for every process event. Parent-child relationships are preserved via parent_process_guid. This enables automatic reconstruction of the full process hierarchy, even when PIDs have been reused (a common problem with short-lived processes).

The process tree view provides:

• ancestor chain — walks up the parent hierarchy to show how the process was spawned, up to 10 levels deep by default;
• direct children — shows what the process spawned after it;
• associated security events — file operations, network connections, DNS queries, and other telemetry linked to each process in the tree, up to 20 events per node;
• IOC-correlated processes — other processes that touched the same IP addresses, DNS names, or file paths are automatically discovered and linked to the tree (see below);
• color-coded roles — the target process (red), its ancestors (gray), children (blue), and IOC-correlated processes (orange with dashed borders) are visually distinct;
• process metadata — PID, username, full command line, container ID, and hostname on every node.

How it reduces investigation time

Without process tree	With process tree
Search for PID in logs	Click "Process Tree" on alert
Find parent PID, search again	Entire ancestor chain visible
Repeat 5–10 times upward	Done in one view
Separately search for child PIDs	Children shown automatically
Cross-reference network/file events by timestamp	Events grouped per process node
Manually correlate container context	Container ID shown on each node
15–30 min per alert	< 2 min per alert

For SOC teams handling dozens of alerts daily, this compounds into hours saved per shift. It also reduces the skill barrier — junior analysts can triage effectively because the visual context replaces the experience needed to navigate raw logs.

IOC enrichment: beyond parent-child relationships

Traditional process trees only show parent-child lineage. But real attacks leave traces across multiple unrelated processes — the same C2 IP, the same dropped file, the same DNS domain. SecureExec's process tree automatically enriches the graph with IOC-correlated processes: other processes on the same host that interacted with the same indicators of compromise.

How it works:

1. After building the parent-child tree, the backend extracts IOC values from the collected events — destination IPs, DNS query names, and file paths.
2. Noise is filtered out automatically: loopback addresses, common system files (/proc/, /etc/passwd), well-known public DNS resolvers, and link-local addresses are excluded.
3. An Elasticsearch query finds events from other processes (not already in the tree) that touched those same IOC values, scoped to a ±2 hour time window.
4. Matching processes appear in the graph as orange dashed nodes, connected to the tree node that shares the IOC with animated orange edges labeled with the matching indicator.

This turns a simple lineage view into a mini attack graph — showing not just what the attacker's process did, but what else on the host interacted with the same infrastructure.

How it works

The feature has two parts:

Backend. A dedicated API endpoint queries Elasticsearch to assemble the tree. It starts with the target process, walks ancestors recursively, fetches direct children in a single batch query, collects associated security events for all discovered processes, and then performs IOC enrichment to find correlated activity. Cycle detection, depth limits, and IOC noise filtering ensure the query completes quickly — typically under 500ms.

Frontend. An interactive graph built with React Flow and automatic layout via dagre. Nodes show process name, PID, username, command line, and event count. IOC nodes are visually distinct with dashed orange borders and an "IOC" badge. Clicking a node opens a detail sidebar with the full event list, matched IOC indicators, and direct links to the events search page. Pan, zoom, and minimap navigation support large trees.

From alert to attack graph in one click

The process tree is accessible from two places:

• Alert detail page — a "Process Tree" button appears on every alert, pre-linked to the relevant process;
• Events page — when expanding any event row, a "Process Tree" button appears if the event has a process_guid.

One click takes you from a single alert to the full execution context. No manual query building, no Elasticsearch syntax, no PID hunting — just the visual chain of events.

Example: investigating a reverse shell alert

1. An alert fires for reverse_shell — bash connected to an external IP.
2. Click "Process Tree" on the alert.
3. The graph shows: sshd → bash → curl (downloaded a script) → bash (reverse shell).
4. Click the initial sshd node — see the SSH authentication events, including the source IP that gained access.
5. Click the curl node — see the DNS query resolving the C2 domain and the file write event saving the payload.
6. Click the reverse shell bash node — see the outbound connection to the attacker's IP and port.

In under a minute, the full attack chain is mapped: initial access via SSH from a specific IP, tool download from a known domain, and reverse shell callback to an attacker-controlled server. The analyst now has everything needed for containment: source IP to block, C2 domain to blacklist, compromised account to disable.

Example: triaging a false positive

Not every alert is an attack. Process tree helps close false positives faster too:

1. An alert fires for fileless_execution — memfd_create was called.
2. Open the process tree.
3. The graph shows: systemd → fwupdmgr (firmware update manager).
4. The parent chain immediately reveals this is a legitimate system operation, not malware.
5. Close the alert as false positive in seconds, no further investigation needed.

Without the tree, the analyst would need to search for the PID, check its parent, verify the binary path, and confirm it is a known system component — a process that takes several minutes.

Try it

Process tree visualization is available in SecureExec's web console. Deploy the agent on your Linux servers and start investigating alerts with full process context.

Get started with SecureExec — deploy in minutes with Docker Compose and see your first process trees today.