What You'll Learn
- Enumerate running processes on a Windows endpoint using Velociraptor artifacts
- Build a baseline of legitimate Windows processes and their expected properties (path, parent, user)
- Identify a planted suspicious process masquerading as a legitimate system binary
- Analyze process trees to detect abnormal parent-child relationships
- Document findings in a Process Baseline Report distinguishing normal from anomalous
Lab Overview
| Detail | Value |
|---|---|
| Lab Profile | lab-velociraptor |
| Containers | Velociraptor Server, Velociraptor Client (Windows endpoint) |
| Estimated Time | 60–70 minutes |
| Difficulty | Intermediate |
| Browser Access | Velociraptor Web UI |
| Pre-Loaded Data | 10+ planted artifacts including C2 beacon, persistence mechanisms, webshell, suspicious processes |
| Deliverable | Process Baseline Report with annotated normal vs. anomalous process entries |
Why Process Baselining Matters. Every incident response begins with one question: "What's running that shouldn't be?" Attackers hide in plain sight by naming malware after legitimate system binaries — svchost.exe, csrss.exe, lsass.exe. The only way to catch them is knowing what normal looks like: the correct path, parent process, user account, and command-line arguments. This lab teaches you to build that mental model using real endpoint telemetry.
The Scenario
Your SOC received an EDR alert flagging unusual network connections from a Windows server in the DMZ. Initial triage shows the server is reachable and responsive, but the alert details are vague — "suspicious outbound connection on a non-standard port." Your team lead asks you to perform a live process audit using Velociraptor.
The endpoint has been pre-configured with a Velociraptor client. Your task is to remotely collect process data, build a baseline of what's legitimate, and identify any processes that don't belong. Unknown to you at the start, the endpoint contains a planted C2 beacon disguised as a legitimate Windows binary running from an incorrect path, along with several other persistence artifacts you may encounter.
Part 1: Connecting to Velociraptor and Client Overview
Step 1 — Access the Velociraptor UI
Once your lab environment reaches READY status, click Open Lab to launch the Velociraptor web interface. Log in with the credentials displayed on the lab page.
After login you'll see the Velociraptor dashboard. On the left sidebar, click Clients (the monitor icon). You should see one connected client — the Windows endpoint.
Step 2 — Select the Client
Click the client hostname (e.g., WIN-SERVER-01) to open the client view. Note the following details:
- Client ID: The unique Velociraptor identifier (e.g.,
C.abc123...) - OS: Windows (build number)
- Last Seen: Should be within the last few minutes (confirming live connection)
- Labels: Any labels applied to this client
Record these details — they form the header of your Process Baseline Report.
Part 2: Collecting Process Data
Step 3 — Run the Process Listing Artifact
Navigate to the Collected Artifacts tab for the client, then click New Collection (the + button). In the artifact search box, type:
Windows.System.Pslist
Select Windows.System.Pslist from the results. This artifact enumerates all running processes with their PID, PPID, name, executable path, command line, user, and creation time.
Click Launch to start the collection. Wait for the status to change to Completed (typically 5–15 seconds).
Step 4 — Review the Process List
Once the collection completes, click on the results. You'll see a table with columns including:
| Column | Description |
|---|---|
| Name | Process name (e.g., svchost.exe) |
| Pid | Process ID |
| PPid | Parent Process ID |
| Exe | Full path to the executable |
| CommandLine | Full command-line arguments |
| Username | Account running the process |
| CreateTime | When the process started |
Record the total number of running processes. A typical Windows system has 60–120 processes. Significantly more or fewer may indicate issues.
Part 3: Building the Legitimate Process Baseline
Step 5 — Document Critical System Processes
Windows has a set of core system processes that ALWAYS run. For each one below, find it in your Pslist results and verify the expected properties:
| Process | Expected Path | Expected Parent | Expected User |
|---|---|---|---|
System | N/A (kernel) | PID 0 | SYSTEM |
smss.exe | C:\Windows\System32\smss.exe | System (PID 4) | SYSTEM |
csrss.exe | C:\Windows\System32\csrss.exe | Created by smss.exe (but parent exits) | SYSTEM |
wininit.exe | C:\Windows\System32\wininit.exe | Created by smss.exe | SYSTEM |
services.exe | C:\Windows\System32\services.exe | wininit.exe | SYSTEM |
lsass.exe | C:\Windows\System32\lsass.exe | wininit.exe | SYSTEM |
svchost.exe | C:\Windows\System32\svchost.exe | services.exe | SYSTEM, LOCAL SERVICE, or NETWORK SERVICE |
explorer.exe | C:\Windows\explorer.exe | userinit.exe (but parent exits) | Interactive user |
For each process, record:
- The actual path from your Pslist results
- The actual parent PID and parent name
- The actual username
- Whether it matches the expected baseline
Multiple svchost.exe instances are normal. Windows runs many svchost.exe processes — each hosts a group of Windows services. Having 10-20 svchost.exe instances is typical. The key is that ALL of them should run from C:\Windows\System32\svchost.exe and have services.exe as their parent. Any deviation is a red flag.
Step 6 — Identify the Anomalous Process
Carefully examine every svchost.exe entry in your results. Look for one that violates the baseline in one or more ways:
- Wrong path: Not running from
C:\Windows\System32\ - Wrong parent: Parent is NOT
services.exe - Wrong user: Running under an unexpected account
- Suspicious command line: Unusual flags or arguments
Record the anomalous process details:
ANOMALOUS PROCESS DETECTED
───────────────────────────
Name: [process name]
PID: [pid]
PPID: [parent pid]
Parent Name: [parent process name]
Path: [full executable path]
CommandLine: [full command line]
Username: [account]
CreateTime: [timestamp]
BASELINE VIOLATIONS:
[ ] Wrong path (expected C:\Windows\System32\)
[ ] Wrong parent (expected services.exe)
[ ] Wrong user account
[ ] Suspicious command-line arguments
[ ] Unusual creation time
Part 4: Deep Dive — Process Tree Analysis
Step 7 — Collect Process Tree Data
To understand the full context, collect the process tree artifact. Click New Collection and search for:
Windows.System.Pslist
This time, check the Include process tree option if available, or alternatively collect:
Generic.System.Pstree
This shows parent-child relationships in a hierarchical view. Look for:
- The suspicious process's children — is it spawning any child processes?
- The suspicious process's parent chain — how did it get launched?
- Any other processes launched around the same time — potentially related activity
Step 8 — Investigate Network Connections
The alert mentioned outbound connections. Collect network connection data:
Windows.Network.Netstat
Launch this artifact and examine the results. Look for:
- Connections from the suspicious PID to external IP addresses
- Non-standard ports (anything other than 80, 443, 53)
- ESTABLISHED connections (active communication)
Record any suspicious network connections:
SUSPICIOUS NETWORK CONNECTION
────────────────────────────
Process: [name] (PID [pid])
Local: [local IP]:[port]
Remote: [remote IP]:[port]
State: ESTABLISHED
Protocol: TCP
C2 Beacons Are Periodic. Command-and-control malware typically "beacons" — connecting to the attacker's server at regular intervals (every 30s, 60s, 5min). If you see an ESTABLISHED connection from the suspicious process to an external IP on a high port, that's likely the C2 channel. Note the remote IP and port for your report.
Part 5: Collecting Additional Evidence
Step 9 — Hash the Suspicious Binary
To confirm the binary is malicious (or at least not a legitimate Microsoft file), collect the file hash:
Windows.Search.FileFinder
Configure the artifact to search for the exact path of the suspicious executable. The results will include MD5, SHA1, and SHA256 hashes.
Record the hashes. In a real investigation, you would submit these to VirusTotal or your threat intel platform.
Step 10 — Check Binary Signature
Collect the Authenticode signature information:
Windows.Detection.BinarySignature
Legitimate Microsoft binaries are digitally signed. An unsigned svchost.exe or one signed by an unknown publisher is a strong indicator of malware.
Part 6: Build Your Process Baseline Report
Compile all findings into a structured report:
PROCESS BASELINE REPORT
═══════════════════════
Endpoint: [hostname]
Client ID: [Velociraptor client ID]
Date: [today's date]
Analyst: [your name]
SECTION 1: System Overview
Total Running Processes: [count]
OS Version: [from client info]
Last Boot: [if available]
SECTION 2: Critical Process Baseline (8 entries)
[For each: Name | Path | Parent | User | Status: NORMAL/ANOMALOUS]
SECTION 3: Anomalous Process Details
Name: [suspicious process]
Path: [wrong path]
Parent: [unexpected parent]
User: [account]
Network: [C2 connection details]
Hash: [SHA256]
Signature: [signed/unsigned]
SECTION 4: Indicators of Compromise
- File: [path to suspicious binary]
- Hash: [SHA256]
- Network: [C2 IP:port]
- Technique: Process masquerading (T1036.005)
SECTION 5: Recommendations
1. Isolate endpoint from network
2. Preserve memory dump for forensic analysis
3. Block C2 IP at firewall
4. Scan all endpoints for same hash
5. Investigate how the binary was delivered
Deliverable Checklist
Before completing the lab, ensure you have:
- Process Listing — Full Pslist collection with total process count documented
- Baseline Verification — All 8 critical system processes checked against expected properties
- Anomalous Process — Suspicious process identified with all baseline violations documented
- Process Tree — Parent-child relationships mapped for the suspicious process
- Network Connections — C2 connection details (remote IP, port, state) recorded
- File Hash — SHA256 of the suspicious binary collected
- Process Baseline Report — Complete report with all 5 sections filled in
Key Takeaways
- Every Windows system has a predictable set of critical processes with known paths, parents, and user accounts
- Process masquerading (running malware as svchost.exe from the wrong directory) is MITRE ATT&CK T1036.005 — one of the most common evasion techniques
- Velociraptor's
Windows.System.Pslistartifact gives you full process context: path, parent, user, command line, and timestamps - A process baseline is your foundation — without knowing what's normal, you cannot identify what's abnormal
- Always correlate process data with network connections to identify C2 communication channels
What's Next
In Lab OS.2 — Registry & File System Hunt, you'll shift from process analysis to persistence hunting. Using Velociraptor's registry and file system artifacts, you'll hunt the same endpoint for registry Run key entries, suspicious files in web directories, and other persistence mechanisms the attacker left behind.
Lab Challenge: Windows Process Baseline
10 questions · 70% to pass
After running Windows.System.Pslist in Velociraptor, you find an svchost.exe running from C:\Users\Public\svchost.exe. Is this legitimate?
In your Pslist results, what is the expected parent process for ALL legitimate svchost.exe instances?
You collect Windows.Network.Netstat and find the suspicious svchost.exe (PID 3847) has an ESTABLISHED TCP connection to 198.51.100.23:8443. What does this most likely indicate?
How many instances of svchost.exe is it normal to see on a typical Windows system?
You run Generic.System.Pstree and see the suspicious svchost.exe was spawned by cmd.exe, which was spawned by w3wp.exe (IIS worker). What attack technique does this process chain suggest?
Which Velociraptor artifact would you use to get the SHA256 hash of the suspicious binary at C:\Users\Public\svchost.exe?
The lsass.exe process should ALWAYS run under which user account?
In the MITRE ATT&CK framework, what technique ID corresponds to an attacker naming their malware after a legitimate system process?
You check the Authenticode signature of the suspicious svchost.exe and find it is unsigned. What does this confirm?
After completing your process baseline, what should be the FIRST recommended response action for the compromised endpoint?
0/10 answered