Windows Process Architecture

Why Process Architecture Matters for Defenders

Every Windows system runs dozens of processes at any given time. Most are legitimate — the operating system booting up, services starting, user applications launching. But hidden among them, an attacker's payload might be running as a child of a process it should never have spawned, or executing from a directory where that binary should never exist.

Knowing what "normal" looks like is the single most important skill for detecting what isn't.

This is not abstract knowledge. Every time you investigate an alert in Wazuh, triage a process creation event (Event ID 4688 or Sysmon Event ID 1), or collect a process listing in Velociraptor, you are reading a process tree. If you cannot tell whether svchost.exe running under a user account is normal (it isn't), you will miss the compromise.

The Windows Boot Process — How the Tree Grows

When a Windows system starts, processes launch in a strict, predictable order. Each process has exactly one parent, and that parent-child relationship is fixed by design. Understanding this chain is your baseline.

Click to enlarge

Stage 1: Kernel Initialization

System (PID 4) is the first process. It represents the Windows kernel itself. You cannot kill it. It has no parent process (its PPID is 0). Every other process on the system descends from this root.

System spawns smss.exe (Session Manager Subsystem) — the process responsible for creating Windows sessions.

Stage 2: Session Creation

smss.exe has two critical jobs:

1. Create Session 0 (for services and system processes) by launching a copy of itself, which then starts csrss.exe and wininit.exe
2. Create Session 1 (for the first interactive user) by launching another copy, which starts csrss.exe and winlogon.exe

After launching its children, the initial smss.exe instance terminates its Session 0 and Session 1 copies. This is why you typically see only one smss.exe running, and its children (csrss.exe, wininit.exe) appear to be orphans — their parent has already exited.

Stage 3: Session 0 — Services

wininit.exe (Windows Initialization) runs in Session 0 and launches three critical children:

services.exe then launches svchost.exe instances — the generic service host that runs DLL-based services. A healthy Windows system has 10-20+ svchost.exe instances, each running a group of related services.

Stage 4: Session 1 — User Login

winlogon.exe handles the user login process for Session 1. After the user authenticates (via lsass.exe), winlogon launches:

• userinit.exe — initializes the user environment, then launches explorer.exe
• explorer.exe — the Windows shell (taskbar, desktop). This is the parent of everything the user launches: browsers, Office, terminals, etc.

The Critical Process Reference Card

This is the table you will reference constantly during investigations. Memorize the "Expected" columns — any deviation is a finding worth investigating.

Click to enlarge

Five Signs of a Suspicious Process

When analyzing any process on a Windows system, check these five attributes. If any one deviates from expected values, investigate further.

1. Wrong Parent

Every critical process has an expected parent. If svchost.exe is a child of explorer.exe instead of services.exe, an attacker likely launched it manually or through a script.

Normal:     services.exe → svchost.exe
Suspicious: explorer.exe → svchost.exe
Suspicious: cmd.exe → svchost.exe

2. Wrong Path

System processes run from C:\Windows\System32\. If you find lsass.exe running from C:\Users\Public\ or C:\Temp\, it is a fake — an attacker binary named to look legitimate.

Normal:     C:\Windows\System32\lsass.exe
Suspicious: C:\Users\Public\lsass.exe
Suspicious: C:\Windows\Temp\lsass.exe

3. Wrong User Context

svchost.exe runs as SYSTEM, LOCAL SERVICE, or NETWORK SERVICE. If it runs as jsmith or any domain user, something is wrong.

4. Wrong Instance Count

Some processes should only have one instance. Two lsass.exe processes means one of them is not the real LSASS. Two services.exe processes means one is an impersonator.

5. Misspelled Name (Masquerading)

Attackers name their binaries to look like system processes: svch0st.exe (zero instead of 'o'), scvhost.exe (letters transposed), lssas.exe (doubled 's'). These evade casual human inspection but fail the path and parent checks.

How Attackers Abuse Legitimate Processes

Beyond simple masquerading, sophisticated attackers use techniques that make malicious activity appear to come from legitimate processes:

Process Hollowing (T1055.012)

The attacker starts a legitimate process (e.g., svchost.exe) in a suspended state, replaces its in-memory code with malicious code, then resumes execution. The process looks legitimate in Task Manager — correct name, correct path, correct parent — but its actual code is malicious.

Detection: Memory analysis (Module 9) can reveal hollowed processes by comparing the on-disk image with the in-memory image.

DLL Sideloading (T1574.002)

Many Windows executables load DLLs from their own directory before checking System32. An attacker places a malicious DLL with the expected name next to a legitimate executable. When the program runs, it loads the attacker's DLL instead of the real one.

Detection: Monitor for DLL loads from unusual directories (Sysmon Event ID 7).

Living Off the Land (LOLBins)

Attackers use legitimate Windows utilities to perform malicious actions:

Detection: These processes are legitimate, so you cannot simply block them. Instead, monitor their command lines (Sysmon Event ID 1) for suspicious arguments like URLs, encoded commands, or unusual paths.

Connecting Process Analysis to Your SOC Tools

Every tool you have learned (or will learn) uses process information:

Key Takeaways

• The Windows process tree follows a strict hierarchy: System → smss.exe → csrss.exe/wininit.exe/winlogon.exe → services.exe/lsass.exe → svchost.exe → user applications
• Every critical system process has an expected path, parent, user context, and instance count — any deviation is a finding
• The five signs of a suspicious process are: wrong parent, wrong path, wrong user, wrong instance count, and misspelled name
• lsass.exe is the #1 target for credential theft — more than one instance or unusual access patterns always warrant investigation
• Attackers use process hollowing, DLL sideloading, and LOLBins (Living Off the Land Binaries) to hide within legitimate processes
• Process analysis connects directly to Wazuh (Sysmon events), Velociraptor (live process collections), YARA (memory scanning), Sigma (detection rules), and Volatility (memory forensics)
• Memorize the Critical Process Reference Card — it is the baseline you will use in every investigation

What's Next

Now that you understand how processes work on Windows, Lesson 3.2 examines the two other pillars of Windows internals that defenders must know: the file system (NTFS, MFT, timestamps) and the registry (hive structure, persistence locations, forensic artifacts). Together with process architecture, these three areas form the foundation for all Windows-based investigation and detection.