ES1.1 Windows Process Model for Security Practitioners

What a process actually is — the security-relevant view

A Windows process is a container. It holds a virtual address space (the memory the process can access), a handle table (references to system objects like files, registry keys, and other processes), one or more threads (the actual units of execution), and an access token (the security context that determines what the process is allowed to do). When you see powershell.exe in Task Manager, you are seeing a process container. The PowerShell code running inside that container executes on threads, reads files through handles, and operates with the permissions granted by its access token.

The security relevance of each component is direct. The access token determines privilege — an attacker who steals or duplicates a token from a SYSTEM-level process gains SYSTEM privileges. The handle table provides access to resources — an attacker who duplicates a handle to the LSASS process can read its memory (credential dumping). The virtual memory space is where code lives — an attacker who writes code into another process’s memory (injection) executes within that process’s security context. The parent-child chain establishes lineage — an anomalous parent-child relationship (Word spawning PowerShell, svchost spawning cmd.exe) is one of the most reliable indicators of compromise.

Access tokens: the security context attackers steal

Every process has an access token that defines its security identity. The token contains: the security identifier (SID) of the user or service account the process runs as, the groups the user belongs to, the privileges assigned to the token (SeDebugPrivilege, SeImpersonatePrivilege, SeBackupPrivilege, etc.), the integrity level (Low, Medium, High, System), and the session ID. When a process attempts to access a resource — open a file, read a registry key, connect to a network share — Windows checks the access token against the resource’s security descriptor to determine whether access is granted.

Attackers target tokens because tokens ARE permissions. The attack techniques: Token theft — stealing the access token from a higher-privilege process and applying it to the attacker’s process. If the attacker can open a handle to a SYSTEM process with TOKEN_DUPLICATE permission, they can duplicate its token and create a new process running as SYSTEM. Token impersonation — using the impersonation APIs (ImpersonateLoggedOnUser, SetThreadToken) to temporarily adopt another user’s security context. This is how PsExec escalates to SYSTEM — it creates a service that runs as SYSTEM, then impersonates that service’s token. Token manipulation — modifying the privileges in an existing token to enable disabled privileges (like SeDebugPrivilege) that the token already contains but has disabled by default.

The defensive controls: Credential Guard isolates the most sensitive token-related secrets in a separate virtual machine (VSM) inaccessible from the main OS. Token integrity levels prevent lower-integrity processes from accessing higher-integrity process tokens. MDE behavioral analysis detects anomalous token operations — a medium-integrity process suddenly operating with SYSTEM-level privileges triggers a behavioral alert. Sysmon Event ID 10 (ProcessAccess) captures when one process opens a handle to another with specific access rights, which is the precursor to token theft.

Process injection: executing code inside another process

Process injection is the technique that makes endpoint security architecturally challenging. Instead of running malicious code in their own process (which EDR monitors), the attacker writes code into the memory of a legitimate process and executes it there. The injected code runs with the target process’s security context, appears to originate from the target process in network connections and file operations, and is harder to detect because the “malicious process” is actually a trusted system process.

The common injection techniques: CreateRemoteThread — the attacker allocates memory in the target process (VirtualAllocEx), writes shellcode into that memory (WriteProcessMemory), and creates a new thread in the target process to execute the shellcode (CreateRemoteThread). This is the classic injection technique and the most detectable — MDE and Sysmon both capture remote thread creation (Sysmon Event ID 8). Process hollowing — the attacker creates a legitimate process in a suspended state (CreateProcess with CREATE_SUSPENDED), unmaps the legitimate executable from its address space, maps the malicious executable in its place, and resumes the process. The process appears legitimate in Task Manager (same name, same path) but executes completely different code. Detection relies on identifying the hollowed process through memory analysis — the executable on disk does not match the executable in memory. DLL injection — the attacker forces the target process to load a malicious DLL using techniques like SetWindowsHookEx, QueueUserAPC, or manipulating the AppInit_DLLs registry key. The DLL executes within the target process’s context. Detection: Sysmon Event ID 7 (ImageLoaded) captures DLL loads, and MDE’s DeviceImageLoadEvents records which DLLs each process loads. APC injection — the attacker queues an asynchronous procedure call (APC) to a thread in the target process, which executes the shellcode when the thread enters an alertable state. This technique is stealthier than CreateRemoteThread because APC execution is a normal operating system mechanism.

Each injection technique requires a handle to the target process with specific access rights (PROCESS_VM_WRITE, PROCESS_VM_OPERATION, PROCESS_CREATE_THREAD). The ASR rule “Block process injection” targets this handle acquisition step — blocking non-Microsoft processes from opening handles to other processes with injection-capable access rights. This is a defense-in-depth control: even if the attacker bypasses other controls and achieves code execution, the injection step is blocked, forcing them to operate within their own process where MDE has full visibility.

Parent-child process chains: the detection goldmine

When a process creates a child process, Windows records the parent process ID (PPID) in the child’s EPROCESS structure. This creates a chain: explorer.exe → cmd.exe → powershell.exe → whoami.exe. Each link in the chain is recorded in MDE’s DeviceProcessEvents (InitiatingProcessFileName and FileName columns) and Sysmon Event ID 1 (ParentImage and Image fields).

Parent-child chain analysis is one of the highest-fidelity detection methods available because legitimate process chains follow predictable patterns. Explorer.exe spawns applications the user launches. Services.exe spawns system services. Svchost.exe spawns service host processes. WmiPrvSE.exe spawns WMI-initiated processes. Deviations from these patterns are strong indicators of compromise:

Word → PowerShell — Microsoft Word does not normally spawn PowerShell. This chain indicates a macro-based attack where the macro launches PowerShell to download and execute a payload. ASR rule “Block Office applications from creating child processes” targets exactly this chain.

svchost.exe → cmd.exe → whoami.exe — svchost hosts Windows services. It does not normally spawn cmd.exe for reconnaissance. This chain suggests a service-based backdoor executing system commands.

WmiPrvSE.exe → powershell.exe → net.exe — WMI-initiated PowerShell launching network commands indicates remote execution — an attacker on another machine used WMI to run commands on this endpoint.

rundll32.exe → cmd.exe — rundll32 loads and executes DLL functions. It does not normally spawn command interpreters. This suggests a malicious DLL is executing system commands.

MDE’s DeviceProcessEvents table records the full chain with command-line arguments, making it possible to build detection rules that match on specific chain patterns. Module ES8 builds these detections systematically, but the underlying principle is established here: anomalous process chains are the behavioral fingerprint of compromise.

1
2

# View parent-child relationships for running processes
Get-CimInstance Win32_Process | Select-Object ProcessId, ParentProcessId, Name, CommandLine | Sort-Object ParentProcessId | Format-Table -AutoSize

1
2
3
4
5

DeviceProcessEvents
| where Timestamp > ago(1h)
| where DeviceName == "<your device name>"
| project Timestamp, InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, ProcessCommandLine
| sort by Timestamp asc

User mode vs kernel mode: the visibility boundary

Windows operates in two modes. User mode (Ring 3) is where applications run — they cannot directly access hardware, kernel memory, or other processes’ memory. They must request services from the kernel through system calls (syscalls). Kernel mode (Ring 0) is where the operating system kernel, device drivers, and critical system components run — they have unrestricted access to hardware and memory.

This boundary matters for endpoint security because it defines what EDR can observe from each mode. MDE’s user-mode service can hook user-mode API calls (CreateProcess, WriteProcessMemory, LoadLibrary) using DLL injection into target processes. These hooks intercept the API call, record the event, and allow it to proceed (or block it). But a sophisticated attacker can bypass user-mode hooks by making direct system calls (syscalls) to the kernel, bypassing the hooked API entirely. This is what tools like SysWhispers and HellsGate do — they resolve the syscall number and call the kernel directly, evading the user-mode hooks that EDR relies on.

MDE’s kernel-mode driver provides the defense-in-depth layer against syscall-level evasion. The driver registers callbacks with the kernel (PsSetCreateProcessNotifyRoutine, PsSetCreateThreadNotifyRoutine, ObRegisterCallbacks) and ETW providers that fire regardless of whether the syscall was made through the normal API or directly. The kernel callback sees the process creation or thread creation regardless of how it was initiated. This is why MDE has both a user-mode and kernel-mode component — the user-mode component provides rich API-level telemetry, and the kernel-mode component provides the guaranteed visibility that cannot be bypassed from user mode.

Session 0 isolation and service security

Windows isolates services in Session 0 — a non-interactive session that has no desktop and cannot interact with user sessions. Before Windows Vista, services ran in Session 0 alongside the first logged-in user’s desktop. This created a class of attacks called “shatter attacks” where a low-privilege application in the user’s session could send window messages to a high-privilege service, manipulating it to execute arbitrary code.

Session 0 isolation eliminates this attack vector. Services run in their own session without a graphical interface. They cannot receive window messages from user sessions. They communicate with user-mode applications through well-defined interfaces (RPC, named pipes, shared memory) rather than the desktop message pump.

The security relevance for endpoint security engineering: services that run in Session 0 with SYSTEM privileges are high-value targets for attackers. A compromised service provides SYSTEM-level access without user interaction. The attack path: exploit a vulnerability in a network-accessible service → gain code execution in the service’s context → the service runs as SYSTEM in Session 0 → the attacker has full system access. PrintNightmare (CVE-2021-34527) exploited exactly this path — the Print Spooler service ran as SYSTEM and accepted network requests that could be crafted to execute arbitrary code.

Endpoint security controls for services: patch management (eliminating the vulnerability), exploit protection (making exploitation harder), and service configuration hardening (disabling unnecessary services, restricting service accounts using Group Managed Service Accounts rather than domain admin accounts). Module ES11 covers service hardening as part of the forensic readiness and hardening configuration.

Troubleshooting

“Process tree analysis shows explorer.exe spawning unknown processes — is this always suspicious?” No. Explorer.exe is the shell — it spawns every application the user launches from the desktop, taskbar, or Start menu. The question is not whether explorer.exe spawned the process but what the spawned process is. Explorer spawning notepad.exe is normal. Explorer spawning mshta.exe with a URL argument is suspicious — mshta is a LOLBin used for HTML application execution. The anomaly is in the child process and its arguments, not in the parent.

“I see LSASS opening handles to many processes — should I investigate each one?” LSASS legitimately opens handles to processes during authentication operations. The detection focus is the reverse: other processes opening handles to LSASS. A process with PROCESS_VM_READ access to LSASS is the credential dumping indicator. Use the MDE query: DeviceProcessEvents | where FileName == "lsass.exe" and isnotempty(InitiatingProcessFileName) to identify processes accessing LSASS, not LSASS accessing other processes.