Appearance
Process Tree and Investigate
The Process Tree and Investigate pages provide event-level context for individual sensors and fleet-wide correlation across sensors. They are the primary tools for tracing a suspicious binary from its parent through its children, comparing behavior against the established baseline, and identifying whether the same pattern is appearing on multiple nodes simultaneously.
Process tree and process list
The process tree returns the current process snapshot from a sensor's most recent heartbeat. The snapshot is built from /proc polling at heartbeat time.
In the Console, navigate to Runtime Inspector, select the target sensor, and open the Process Tree tab for the hierarchical view or the Top Processes tab for the flat list sorted by resource usage. Both views draw from the same proc snapshot. The response data includes total and processes[].
Process records include: PID, binary path, command line, UID, cgroup path, workload context (Kubernetes namespace/pod/workload if applicable), and parent PID.
Event lineage (ancestor chain)
For any specific runtime event, the Console can reconstruct the full process ancestor chain. In the Console, open the event detail in the Investigate or Alerts view and click View Lineage. The lineage panel shows the ancestors chain from the ClickHouse event record, reconstructing the process tree at the exact moment the event fired, even for processes that are no longer running.
Runtime events query
In the Console, navigate to Investigate to query events from ClickHouse with filtering and pagination. Use the filter bar to narrow results.
Filter parameters:
| Parameter | Description |
|---|---|
sensor_id | Filter to a specific sensor |
event_kind | Filter to a specific event kind |
severity | Filter by severity: info, warning, high, critical |
q | Free-text search on the event message |
since | Time window (e.g. 1h, 24h) |
process_executable | Filter by process binary path |
node_name | Filter by node display name |
nf_role | Filter by declared NF role |
saved_search_id | Apply a saved search filter |
limit | Maximum results (default 50, max 5000) |
offset | Pagination offset |
Real-time event stream
In the Console, navigate to Runtime Inspector > Live Feed to subscribe to a real-time event stream from all sensors. Use the filter controls to narrow the stream by sensor, event kind, severity, or a text query. Each item in the feed is a single runtime event delivered as it arrives from sensor heartbeats.
Fleet correlation
Fleet correlation identifies event kinds and process executables that appear simultaneously (or near-simultaneously) across multiple sensors. This is the first signal that an incident is not isolated to a single node.
In the Console, navigate to Investigate > Fleet Correlation. Use the Time Window and Min Sensors controls to adjust the detection window.
Filter parameters:
| Parameter | Default | Range | Description |
|---|---|---|---|
window_secs | 1800 | 300–604800 | Time window to look for correlated events |
min_sensors | 2 | 2–100 | Minimum sensors that must show the same event |
limit | 50 | 1–200 | Maximum correlations to return |
The response includes correlations[], window_secs, min_sensors, and total.
Fleet correlation timeline
In the Console, click Timeline on any correlation row to see a bucketed time chart of how many sensors triggered the event kind across the selected window. Use the Process Executable filter to narrow to a specific binary.
Behavioral fingerprints
A fingerprint is the full behavioral baseline for a specific binary on a specific sensor: which children it spawns, which destinations it connects to, which file prefixes it accesses, and when it runs.
In the Console, navigate to Investigate > Fingerprints and search by binary name or select a sensor. The fingerprint detail shows spawn_profile, net_profile, file_profile, args_profile, time_profile (24-bucket hourly histogram), event_count, is_learning, and data_days.
Aggregated fingerprints
To compare baselines across sensors for the same binary or role, use the Aggregated Fingerprints tab in the Investigate section. Filter by Role (e.g. amf) or search by binary name. Filter parameters include sensor_id, declared_role, q (search), window_hours, sort_by, sort_desc, page, and page_size.
Shell Sessions view
The Shell Sessions page in the Console groups process_exec events from the last 7 days into interactive shell sessions. A session is identified when a shell binary (bash, sh, zsh, dash, fish, ksh, ash, csh, tcsh, mksh, busybox) appears as a process_exec event, and all process_exec events where that shell is the parent executable become the commands within that session.
Each session shows:
- Shell binary and the parent that spawned it
- UID and PID at session start
- List of commands executed within the session
- Risk score based on the commands observed (debugger invocations, reverse shell patterns, privilege changes)
- Risk level:
critical,high,medium, orlow - Whether the session is still active
To pivot from a shell session into the full Investigate view, use the session's parent executable and sensor as query context.
Linking events to investigations
From any event in Investigate, you can link it to an existing investigation or create a new one. See Investigations for the full workflow.
From Behavioral Analytics, the Investigate button on any anomaly score creates an investigation automatically, populating the title with the binary name and event kind and the initial evidence with the anomaly reasons and MITRE mappings.