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 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 without exploiting any vulnerability. The handle table provides access to resources — an attacker who duplicates a handle to the LSASS process can read its memory for credential dumping. The virtual memory space is where code lives — an attacker who writes code into another process's memory executes within that process's security context, appearing to be the legitimate process in network connections, file operations, and EDR telemetry. The parent-child chain establishes lineage — an anomalous parent-child relationship like Word spawning PowerShell or svchost spawning cmd.exe is one of the most reliable indicators of compromise because legitimate software follows predictable process chain patterns.

When Windows creates a process, the kernel allocates a new virtual address space, creates an EPROCESS structure in kernel memory — the kernel's internal representation of the process — copies the access token from the parent process unless a different token is specified, maps the executable into the address space, creates the initial thread, and returns control to user mode. MDE's sensor operates at both user mode and kernel mode: the kernel-mode driver hooks system calls and ETW providers to capture process creation, thread creation, and handle operations. The user-mode service processes these events, applies behavioral analysis, and transmits them to the cloud. This dual-mode operation is why MDE can observe both kernel-level events like process injection and user-level events like script content captured through AMSI.

Access tokens and the privileges attackers steal

Every process has an access token that defines its security identity. The token contains the security identifier (SID) of the user account, the groups the user belongs to, the privileges assigned to the token — SeDebugPrivilege, SeImpersonatePrivilege, SeBackupPrivilege — the integrity level (Low, Medium, High, System), and the session ID. When a process attempts to access a resource, Windows checks the access token against the resource's security descriptor.

Attackers target tokens because tokens are permissions. Token theft steals the access token from a higher-privilege 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 uses the ImpersonateLoggedOnUser or SetThreadToken APIs to temporarily adopt another user's security context — this is how PsExec escalates to SYSTEM by creating a service that runs as SYSTEM and then impersonating that service's token. Token manipulation modifies the privileges in an existing token to enable disabled privileges — like enabling SeDebugPrivilege, which is granted to administrator tokens but disabled by default.

The privilege that matters most for endpoint security is SeDebugPrivilege. This privilege allows a process to open a handle to any other process with full access rights — including LSASS. By default, SeDebugPrivilege is granted to local administrator tokens but disabled. The attacker enables it using AdjustTokenPrivileges before opening a handle to LSASS for credential dumping. MDE detects SeDebugPrivilege being enabled in suspicious contexts — a developer running Visual Studio enabling it is normal. A PowerShell process spawned from Word enabling it is the CHAIN-ENDPOINT attack chain. The API call is identical. The process lineage is not.

Log Name:      Microsoft-Windows-Sysmon/Operational
Source:        Microsoft-Windows-Sysmon
Event ID:      1
Task Category: Process Create (rule: ProcessCreate)
Level:         Information
Computer:      DESKTOP-NGE042.northgate.local
Description:
  RuleName:      technique_id=T1059.001,technique_name=PowerShell
  UtcTime:       2026-02-14 09:18:33.204
  ProcessGuid:   {a23f8c41-7d21-67ae-0e00-000000004600}
  ProcessId:     8412
  Image:         C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
  CommandLine:   powershell.exe -nop -w hidden -enc SQBFAFgA...
  CurrentDirectory: C:\Users\t.ashworth\Documents\
  User:          NORTHGATE\t.ashworth
  ParentProcessId: 6204
  ParentImage:   C:\Program Files\Microsoft Office\root\Office16\WINWORD.EXE
  ParentCommandLine: "C:\Program Files\Microsoft Office\root\Office16\WINWORD.EXE" /n "Q1-Report.docm"

This Sysmon Event ID 1 is the raw evidence of a parent-child chain anomaly. The ParentImage field shows WINWORD.EXE — Word — spawning powershell.exe with a hidden window (-w hidden) and a Base64-encoded command (-enc). Every field matters: the -nop flag disables the PowerShell profile (avoiding detection from profile-based monitoring), the -w hidden flag hides the window from the user, and the -enc flag encodes the command to evade command-line pattern matching. The ParentCommandLine shows Word opening a .docm file — a macro-enabled document. This is the exact process chain that the ASR rule "Block Office from creating child processes" prevents, and the KQL query below detects at fleet scale.

// Detect anomalous parent-child process chains — Office spawning interpreters
DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ ("winword.exe", "excel.exe", "powerpnt.exe", "outlook.exe")
| where FileName in~ ("powershell.exe", "cmd.exe", "wscript.exe", "cscript.exe", "mshta.exe")
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName, FileName, ProcessCommandLine
| sort by Timestamp desc

This query detects the exact process chain pattern that ASR rule "Block Office applications from creating child processes" prevents. If this query returns results in your environment, each result is either a legitimate macro that should be excluded from the ASR rule or an actual attack attempt. The ASR rule blocks these chains. The KQL query detects them. Module ES4 deploys the ASR rule. Module ES8 builds the detection. Both defend the same OS mechanism — the parent-child process relationship.

Process injection: code execution inside another process

Process injection is the technique that makes endpoint security architecturally challenging. Instead of running malicious code in their own process, 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 like svchost.exe.

The common injection techniques each target different aspects of the process model. CreateRemoteThread allocates memory in the target process using VirtualAllocEx, writes shellcode using WriteProcessMemory, and creates a new thread to execute it using CreateRemoteThread — the classic injection method and the most detectable because both MDE and Sysmon Event ID 8 capture remote thread creation. Process hollowing creates a legitimate process in a suspended state, unmaps the legitimate executable from its address space, maps the malicious executable in its place, and resumes it — the process appears legitimate in Task Manager but executes completely different code. DLL injection forces the target process to load a malicious DLL using techniques like SetWindowsHookEx, QueueUserAPC, or the AppInit_DLLs registry key — Sysmon Event ID 7 and MDE's DeviceImageLoadEvents capture which DLLs each process loads. APC injection queues an asynchronous procedure call to a thread in the target process, which executes shellcode when the thread enters an alertable state — stealthier than CreateRemoteThread because APC execution is a normal OS 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 handle acquisition step is where defensive controls intercept: the ASR rule for process injection blocks non-Microsoft processes from opening handles with injection-capable access rights. 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, unobstructed visibility.

Parent-child chains: the detection goldmine

When a process creates a child process, Windows records the parent process ID in the child's EPROCESS structure. This creates a chain: explorer.exe → cmd.exe → powershell.exe → whoami.exe. MDE records each link in DeviceProcessEvents — the InitiatingProcessFileName and FileName columns — and Sysmon Event ID 1 captures the same relationship in ParentImage and Image fields.

Parent-child chain analysis is the highest-fidelity detection method available because legitimate chains follow predictable patterns that attackers cannot easily mimic. Explorer.exe spawns applications the user launches. Services.exe spawns system services. Svchost.exe spawns service host processes. Deviations from these patterns are strong indicators of compromise: Word spawning PowerShell indicates a macro attack. Svchost spawning cmd.exe for reconnaissance suggests a service-based backdoor. WmiPrvSE spawning PowerShell launching net.exe indicates remote execution from another machine. Rundll32 spawning command interpreters suggests a malicious DLL executing system commands.

Sophisticated attackers attempt to evade chain analysis through parent PID spoofing — using the CreateProcess API with an EXTENDED_STARTUPINFO_PRESENT flag that specifies a different parent process than the actual creator. The child process appears in the process tree under the spoofed parent rather than the true parent. MDE's kernel-mode driver detects this discrepancy because the kernel callback records both the true creator (the process that called CreateProcess) and the declared parent. A process whose kernel-recorded creator differs from its declared parent is either using a legitimate Windows feature like UAC elevation — which the kernel also records — or is actively spoofing. Custom detection rules in Module ES8 build on this discrepancy.

Chain depth matters for detection. A single-hop anomaly — Word spawning PowerShell — is straightforward to detect. Multi-hop chains are harder: Word spawns cmd.exe, which spawns conhost.exe as a normal console host, and cmd.exe then spawns PowerShell. The immediate parent of PowerShell is cmd.exe, which is a normal parent. The anomaly is two hops back — cmd.exe was spawned by Word, which is the attack indicator. Detection rules that look only one hop deep miss this pattern. Effective rules examine the full chain — the grandparent and great-grandparent — which MDE supports through the InitiatingProcessParentFileName field in DeviceProcessEvents.

# View parent-child relationships for running processes
Get-CimInstance Win32_Process |
    Select-Object ProcessId, ParentProcessId, Name, CommandLine |
    Sort-Object ParentProcessId |
    Format-Table -AutoSize
# Find explorer.exe — what has it spawned?
# Find svchost.exe — is its parent services.exe?
# Any process whose parent PID doesn't match a running process?

Run this on any endpoint to see the live process tree. Identify the chains. Any Office application spawning a script interpreter is the pattern that detection rules and ASR rules both target. The KQL in Advanced Hunting and the PowerShell on the local endpoint show the same data from different perspectives — live versus historical, local versus fleet-wide.

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. Kernel mode (Ring 0) is where the kernel, device drivers, and critical system components run with unrestricted access. This boundary defines what EDR can observe from each level.

MDE's user-mode service hooks user-mode API calls — CreateProcess, WriteProcessMemory, LoadLibrary — by injecting into target processes. These hooks intercept the call, record the event, and allow it to proceed. But a sophisticated attacker can bypass user-mode hooks by making direct system calls to the kernel using tools like SysWhispers, bypassing the hooked API entirely. MDE's kernel-mode driver provides the defense-in-depth layer: it 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 regardless of how it was initiated.

The arms race between EDR and evasion operates along this boundary. First-generation evasion bypassed user-mode hooks. EDR vendors added kernel-mode callbacks. Second-generation evasion targeted the kernel callbacks through driver exploits. Microsoft responded with Kernel Mode Code Integrity (KMCI) and Hypervisor-Protected Code Integrity (HVCI), preventing unsigned kernel code. Third-generation evasion uses bring-your-own-vulnerable-driver (BYOVD) attacks — loading a legitimately signed but vulnerable driver, then exploiting the vulnerability for arbitrary kernel code execution. The ASR rule "Block abuse of exploited vulnerable signed drivers" directly targets this technique. Each defensive layer addresses evasion at the layer below it, which is why the layered stack from Section 0.3 is not optional — each layer catches what the layer below it missed.

One more architectural boundary matters for endpoint security: Session 0 isolation. Windows isolates services in Session 0, a non-interactive session with no desktop that cannot interact with user sessions. Services that run in Session 0 with SYSTEM privileges are high-value targets — a compromised service provides SYSTEM-level access without user interaction. 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 include patch management, exploit protection configured per-application, and service account hardening — using Group Managed Service Accounts rather than domain admin accounts for service credentials.