Windows kernel architecture

Windows kernel architecture

TL;DR: Ring 0 on Windows = Executive (object manager, I/O, memory, security) + Kernel (scheduler, primitives) + HAL + drivers, all living in ntoskrnl.exe’s VA. Knowing which layer owns which object is what tells you where to look for bugs.

What it is

Windows splits kernel mode into a layered architecture inside a shared address space. The Executive provides high-level subsystems (Object Manager, I/O Manager, Memory Manager, Process Manager, Security Reference Monitor, ALPC, PnP, Power); the Kernel layer supplies thread scheduling, IRQL synchronisation, traps, and CPU abstractions; HAL hides chipset/platform differences; and a forest of drivers (KMDF/WDM/WPP) plug in via the I/O Manager. All of these live in the same kernel virtual address space, communicating mostly through documented Executive types (EPROCESS, ETHREAD, FILE_OBJECT, OBJECT_HEADER…).

Preconditions / where it applies

  • Applies to any Windows offensive research: LPE, sandbox escape, hypervisor break-out, anti-cheat bypass, EDR evasion
  • Per-build offsets matter — _EPROCESS, _KTHREAD, _HANDLE_TABLE move regularly; always validate with dt nt!_TYPE in the matching symbol set
  • Mitigations layer on top: HVCI (hvci-vbs), CET kernel (cfg-cet-kernel), SMEP/SMAP (smep-smap-overview), KPTI (kpti-meltdown-implications)

Technique

Mental model the exploit author keeps loaded:

  • User → kernel transition. SYSCALL via KiSystemCall64 → trap frame → table dispatch through KeServiceDescriptorTable/Win32k. Modern transitions also swap CR3 under KVA Shadow.
  • Process and thread objects. EPROCESS (Executive) wraps KPROCESS (Kernel). ActiveProcessLinks is the system-wide linked list that token-stealing payloads walk (see token-stealing-payloads).
  • Memory. Kernel pool (ExAllocatePool2) replaced by Segment Heap on recent builds; pool tags help triage, but pool randomisation makes spraying harder. KMDF objects live in non-paged pool.
  • I/O Manager and drivers. Every device call becomes an IRP; IOCTLs dispatched via MajorFunction[] — primary attack surface. See kernel-objects-and-irps.
  • Win32k subsystem. Historically the highest-bug-density area: GDI/USER kernel side, reachable from low-IL processes. Win32k filter (since Win10) restricts which calls a process can make.
  • VBS partitioning. With VBS on, much of “kernel” actually runs in VTL0 while the secure kernel (securekernel.exe) runs in VTL1 — see hvci-vbs.
  • HAL and hypercalls. HAL exposes platform timer/IPI; under Hyper-V the kernel issues vmcall hypercalls for SLAT, scheduling, intercepts.

Reverse-engineering anchor table:

1
2
3
4
5

ntoskrnl.exe    — Executive + Kernel
hal.dll         — Hardware abstraction
win32k.sys      — GUI subsystem (paged on session-space)
ci.dll          — Code Integrity policy
securekernel.exe — VTL1 secure kernel (VBS)

WinDbg commands every researcher memorises:

1
2
3
4
5

!process 0 0          ; list processes
dt nt!_EPROCESS       ; layout for current build
!pool <addr>          ; pool diagnostics
!devstack <devobj>    ; driver stack for a device
!analyze -v           ; bugcheck triage

Detection and defence

  • Defence in depth: HVCI + Kernel CFG + CET + SMEP/SMAP + KPTI + Win32k filter together push exploit costs sharply higher
  • Driver Verifier (/standard /driver foo.sys) catches many bug classes pre-shipping
  • WDAC + Vulnerable Driver Blocklist closes BYOVD pathways
  • Audit syscall/IOCTL surface exposed to low-IL processes; restrict device DACLs to admin where possible

References

Related: kernel-objects-and-irps, hvci-vbs, cfg-cet-kernel, token-stealing-payloads