Appearance
Attack Chains
Attack Chains correlate multiple runtime events from a single sensor into a named sequence that maps to known attacker behavior. Instead of reviewing individual alerts in isolation, operators can see whether a suspicious event was followed by a related escalation step within a meaningful time window.
Chain detection runs on every heartbeat. The Console maintains a per-sensor in-memory event window containing events from the last 30 minutes. Each time a heartbeat is processed, the window is scanned for all seven chain patterns simultaneously.
How detection works
Events from the heartbeat are added to the sensor's event window. Old events (older than 30 minutes) are evicted. The chain detection function scans the window looking for ordered pairs or sequences of event kinds that match a defined pattern. When a match is found, a chain record is stored in the database.
Chains are deduplicated: the same chain_id + sensor_id + binary_path combination fires at most once per 3,600-second window (1 hour). If the same chain fires again within that window, the existing record is updated rather than creating a duplicate.
Chain catalog
Seven chains are defined. All currently fire with severity critical or high.
Chain 1: Process Injection to C2 Communication
chain_id: process_injection_c2Severity: critical MITRE: T1055, T1071
Pattern: A ptrace or mmap_exec event (process injection indicator) followed within 600 seconds by a network_connect to a non-loopback address from the same binary.
Exclusions: Common diagnostic tools that legitimately use ptrace or mmap (redis-cli, pg_isready, dig, nslookup, curl, wget, ping, nmcli, the ip command) are excluded from step 1. Loopback destinations are excluded from step 2.
Timing: Step 1 must be within the last 900 seconds; step 2 within 600 seconds after step 1.
Chain 2: Privilege Escalation to Network Connection
chain_id: privesc_networkSeverity: critical MITRE: T1548, T1071
Pattern: A privilege_change event followed within 300 seconds by a network_connect to a non-loopback address from the same binary.
Exclusions: Binaries expected to legitimately change privileges are excluded from step 1: cron, crond, sshd, ssh, su, sudo, login, runuser, newgrp, polkitd, dbus-daemon, and anything containing systemd.
Timing: Step 1 must be within the last 600 seconds; step 2 within 300 seconds after step 1.
Chain 3: Inbound Connection to Shell Spawn (Webshell Indicator)
chain_id: webshell_spawnSeverity: critical MITRE: T1505.003
Pattern: A network_accept event (inbound connection from a non-loopback source) followed within 120 seconds by a process_exec where the parent is the same binary that accepted the connection and the spawned process is a shell (bash, sh, dash, or zsh).
Timing: Step 1 must be within the last 300 seconds; step 2 within 120 seconds after step 1.
Chain 4: Defense Evasion to Namespace Creation
chain_id: defense_evasion_containerSeverity: high MITRE: T1562, T1610
Pattern: A signal event sending SIGKILL to a known security tool (sshd, auditd, a Telovix sensor, falcon, osquery, or wazuh) followed within 300 seconds by a namespace_create event from the same binary.
Exclusions: Container runtime binaries (containerd, dockerd, runc) and systemd are excluded from step 1.
Timing: Step 1 must be within the last 600 seconds; step 2 within 300 seconds after step 1.
Chain 5: Kernel Module Load to Network Connection (Rootkit C2)
chain_id: rootkit_c2Severity: critical MITRE: T1014, T1071
Pattern: A kernel_module_load or kmod_load event followed within 600 seconds by any network_connect event from any binary.
Timing: Step 1 must be within the last 900 seconds; step 2 within 600 seconds after step 1.
Chain 6: Credential File Access to DNS Exfiltration
chain_id: credential_dns_exfilSeverity: critical MITRE: T1003, T1048
Pattern: A file_open or file_write event touching a sensitive path (/etc/shadow, /etc/passwd, /.ssh/, /root/, or files with credentials or secret in the path) followed within 300 seconds by a dns_query event with warning severity or higher from the same binary.
Exclusions: Monitoring agents are excluded from step 1 (the Telovix sensor binary, falco, osqueryd, wazuh-agent) since they legitimately read credential files for host introspection.
Timing: Step 1 must be within the last 600 seconds; step 2 within 300 seconds after step 1.
Chain 7: File Integrity Alert to Modified Binary Executed
chain_id: fim_exec_correlationSeverity: critical MITRE: T1195.002, T1554
Pattern: A fim_alert event (file integrity violation indicating a binary was modified) followed within 3,600 seconds by a process_exec event where the executed binary path matches the path reported in the FIM alert.
Timing: Step 1 (FIM alert) must be within the last 2 hours; step 2 within 3,600 seconds after step 1.
Querying chains
In the Console, navigate to Attack Chains to see all active chain matches. Use the Sensor filter to scope to a specific node, and enable Show Suppressed to include suppressed matches. The summary banner at the top of the view shows active_count, critical_count, high_count, and the five most recent chains.
Filter parameters:
| Parameter | Default | Description |
|---|---|---|
sensor_id | (all sensors) | Filter to a specific sensor |
limit | 50 | Maximum records (1–200) |
show_suppressed | false | Include suppressed chain matches |
The summary banner returns active_count, critical_count, high_count, and the top 5 most recent chains.
Chain match record
Each chain match includes:
| Field | Description |
|---|---|
chain_id | The pattern identifier (e.g. process_injection_c2) |
chain_name | Human-readable chain name |
sensor_id | Sensor where the chain was detected |
node_name | Node display name |
binary_path | Absolute path of the primary binary involved |
severity | critical or high |
chain_start_at | Timestamp of the first step |
chain_end_at | Timestamp of the last step |
event_sequence | JSON array of ordered steps with event kind, binary, message, and timestamp |
mitre_techniques | MITRE ATT&CK technique IDs added by the API response layer |
Suppressing a chain
If a chain match is a known false positive, suppress it to remove it from the active view. Suppression requires analyst role.
In the Console, open the chain detail in Attack Chains and click Suppress. Select the reason (e.g. false_positive) and confirm. To un-suppress a chain, enable Show Suppressed in Attack Chains, open the suppressed chain, and click Remove Suppression.
Limitations
- Chain detection operates on a per-sensor event window. Cross-sensor chains (lateral movement between nodes) are not currently detected by this mechanism.
- The event window holds events from the last 30 minutes. Events older than 30 minutes at heartbeat time are evicted and cannot contribute to a new chain match.
- The same chain pattern fires at most once per 3,600 seconds per sensor/binary combination. Persistent attacker activity on the same binary may produce only one chain record per hour.
- The event window is in-memory on the Console process. A Console restart resets all windows; events received before the restart cannot contribute to chain detection.