Module 1 — Kernel and Privilege Rings

Summary

Windows splits the machine into kernel mode (Ring 0) and user mode (Ring 3). Security engineering starts by knowing which side code runs on and what crosses the boundary.

Path: MOC · Next: Module 2

0. Purpose

You need a stable picture of where policy is enforced (kernel, drivers, security subsystem) vs where attackers usually start (user-mode processes, scripts, DLLs). Without this, every log line and ProcExp column floats without context.

1. ELI5

The computer has two floors:

Top floor (user mode) — apps, PowerShell, browsers. They can break their own room but not the building.
Basement (kernel mode) — the building manager (ntoskrnl.exe) and specialized workers (drivers). They touch hardware, memory of all processes, and security decisions.

Apps ask the basement through a single guarded door (syscalls). That door is the main audit point for EDR and kernel callbacks.

2. Deep breakdown

flowchart TB
  subgraph ring3 [User mode — Ring 3]
    APP[Applications .exe]
    DLL[DLLs in process]
  end

  subgraph ring0 [Kernel mode — Ring 0]
    KERN[ntoskrnl.exe]
    DRV[Drivers .sys]
    HAL[Hardware abstraction]
  end

  APP --> DLL
  DLL -->|syscall via ntdll| KERN
  KERN --> DRV
  DRV --> HAL

Component	Location	Security role
`ntoskrnl.exe`	`C:\Windows\System32\` (kernel image)	Scheduler, memory manager, object manager, security reference monitor
*Drivers (`.sys`)**	`C:\Windows\System32\drivers\`	Kernel-mode code — network filter, storage, AV minifilter, etc.
User processes	Each has private virtual address space	Where malware and admin tools usually run
Security subsystem	Kernel + LSASS (user) + policy	AuthZ, tokens, integrity labels

What only kernel mode can do (examples):

Map physical memory arbitrarily
Install kernel drivers (with signing/policy gates on modern Windows)
Modify another process without user-mode APIs
Handle interrupts and hardware directly

Win11-specific awareness:

VBS / HVCI (when enabled) raises the cost of unsigned kernel code and some memory attacks — check with msinfo32 or Get-CimInstance on lab .114
Kernel-mode code signing still matters; lab VMs may relax policies — note your baseline

3. Deep dive — VBS, HVCI, and Credential Guard

Modern Win11 hardening moves enforcement below user-mode EDR into the hypervisor.

Feature	What it does	Requires
VBS	Hypervisor-enforced isolation for security features	UEFI, Secure Boot, CPU virt + SLAT
HVCI (Memory Integrity)	Kernel code integrity via hypervisor	VBS + compatible drivers
Credential Guard	LSA secrets in `lsaiso.exe`	VBS + Enterprise SKU + TPM 2.0

Lab `.114` posture (baseline)

Field	Value	Meaning
`SecurityServicesRunning`	`{0}`	No CG / HVCI running
`VirtualizationBasedSecurityStatus`	`0`	VBS not active
`CodeIntegrityPolicyEnforcementStatus`	`2`	CI policy in audit mode

Verify on any host

Get-CimInstance Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard |
  Select-Object SecurityServicesRunning, VirtualizationBasedSecurityStatus,
    CodeIntegrityPolicyEnforcementStatus

Get-ComputerInfo -Property DeviceGuard*
Confirm-SecureBootUEFI
(Get-CimInstance Win32_ComputerSystem).HypervisorPresent

`SecurityServicesRunning`	Service
1	Credential Guard
2	HVCI (Memory Integrity)
3	System Guard Secure Launch

GUI cross-check: msinfo32 → Virtualization-based security. CI blocks log to Microsoft-Windows-CodeIntegrity/Operational (e.g. 3033).

Minifilter altitude bands (kernel I/O referees)

Band	Range	Example on `.114`
Anti-Virus	320000–329999	`WdFilter` 328010
Activity Monitor	360000–369999	`UCPD` 385250.5
Content Screener	260000–269999	`applockerfltr` 265000

fltmc filters | Select-String 'WdFilter|UCPD|applocker'

Refs: VBS / HVCI · Credential Guard

Security engineer lens

Question	Why it matters
Is this artifact kernel or user?	Kernel compromise = total host loss
Which driver touched this I/O?	Minifilters see files/network at kernel level
Does policy allow this driver load?	CI / WDAC / ELAM paths
Are we debugging user or kernel crash?	Different tools (WinDbg pool vs user dump)

Do not start by patching ntoskrnl.exe or random .sys files in a lab — observe signing, version, and load order first.

Lab checkpoint — `192.168.50.114`

SSH: ssh tester808@192.168.50.114

# Kernel image on disk (metadata only — do not modify)
Get-Item C:\Windows\System32\ntoskrnl.exe |
  Select-Object FullName, Length, VersionInfo, LastWriteTime

# Count inbox drivers
(Get-ChildItem C:\Windows\System32\drivers\*.sys).Count

# Is virtualization-based security reporting enabled? (may be off on lab VM)
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard |
  Select-Object SecurityServicesRunning, VirtualizationBasedSecurityStatus

# OS build — record for baselines
[System.Environment]::OSVersion.Version

Record in notebook

Build number on .114 (expect 26200 family)
ntoskrnl.exe file version and last write time
Driver count (order of magnitude)
One sentence: "User mode cannot ___ without a syscall"

← MOC · Module 2 →