← ./resources / blog
Windows Security · Internals//2026-09-03//16 min read

Kernel vs. User Mode: The Role of Windows System Calls

Windows is intentionally divided into less-trusted application code and a privileged operating-system core. System calls are the tightly controlled crossing between those worlds. Understanding that boundary clarifies how applications access files and processes, why drivers are such high-value targets, and where defenders should collect evidence.

VMBy Viral Maniar · Managing Director & Principal Consultant

The boundary is a security primitive

On mainstream Windows systems, ordinary applications run in user mode (architecturally ring 3) and the Windows kernel runs in kernel mode (ring 0). User-mode code cannot directly read kernel memory, program hardware, or change page tables. Those restrictions contain application crashes and prevent a compromised application from simply taking over the machine. The kernel owns scheduling, virtual memory, object security, device I/O, and the reference monitor that enforces access checks.

Windows execution boundaryUser mode (ring 3)ApplicationWin32 / .NET APIsntdll syscall stubcontrolled system-call transitionKernel mode (ring 0)Executive / Object ManagerMemory + I/O ManagerKernel + signed driversPreemptive Cyber Security
Figure 1. Applications request privileged work through documented APIs; the final transition into the kernel is mediated by a system call.

From a familiar API to a system service

Consider an application opening a protected file. It usually calls a documented API such as CreateFileW. Supporting libraries validate or transform arguments, and ntdll.dll eventually prepares a system-service request such as NtCreateFile. The CPU performs a controlled transition, the kernel validates user pointers and requested access, resolves the object through the Object Manager, evaluates the security descriptor against the caller's token, and routes the operation through the I/O stack. A handle is returned only if those checks succeed.

The exact internal interfaces and system-service numbers are implementation details and vary by Windows release. Security products and developers should use documented Windows APIs, not hard-code syscall numbers or depend on internal structures. That keeps software compatible and avoids mistaking a version-specific detail for a security boundary.

Architecture: request, policy, device

A high-level file-open pathAppWin32 APISyscallObject Manageraccess checkI/O + file driverstorage requestaudit / EDR telemetryPreemptive Cyber Security
Figure 2. A request travels through layers that each add validation, policy, or device-specific work. Useful telemetry can be emitted at multiple points.

Why drivers change the risk calculation

Kernel drivers execute with the same broad privilege as the OS core. A flawed driver can corrupt kernel memory, expose arbitrary device access, or crash the system; a legitimate but vulnerable driver can also be abused as a stepping stone. This is why Windows uses driver signing, virtualization-based security (VBS), the vulnerable-driver blocklist, and Microsoft Defender Application Control (WDAC). These controls reduce the chance that arbitrary code reaches kernel mode, but they must be deployed, monitored, and kept current.

Relevant CVEs: learn the pattern, patch the product

CVE-2021-1732 was a Windows Win32k elevation-of-privilege vulnerability exploited in the wild. CVE-2024-21338 was a Windows kernel elevation-of-privilege vulnerability where exploitation could lead to SYSTEM privileges. These are examples of boundary failure: a user-mode attacker turns a bug in a privileged component into kernel-level control. They are not a license to disable kernel protections. The operational response is to apply vendor updates promptly, maintain EDR visibility, and remove unneeded kernel attack surface.

Defensive lab setup

  1. Create a disposable Windows VM and snapshot it before experiments.
  2. Install Sysmon with a reviewed configuration and inspect process, image-load, and file events.
  3. Use Rekall or Microsoft Sysinternals tools for observation, not modification, of the lab system.
  4. Check Windows Security's Core isolation and the Microsoft vulnerable-driver blocklist status. Record the baseline before testing a compatibility change.

Detection and hardening priorities

  • Patch kernel and driver components quickly. Treat exploited-in-the-wild advisories as an exposure-management priority.
  • Constrain driver loading. Use WDAC where feasible, retain the vulnerable-driver blocklist, and inventory new services and drivers.
  • Protect credentials and isolation boundaries. Enable VBS and Credential Guard where hardware and application compatibility permit.
  • Collect high-quality telemetry. Correlate process creation, image loads, service installation, code-integrity events, and unusual access-denied patterns.
  • Do not rely on user-mode hooks alone. They can provide valuable visibility, but they are not the kernel's authorization boundary.

A useful mental model

User mode is where untrusted workload executes; kernel mode is where the system must make correct, security-sensitive decisions. A system call is a request, not a permission grant. Its value is in forcing the request through a narrow interface where Windows can validate context, access rights, and memory before performing privileged work.

Key takeaways

  • Ring 3 and ring 0 separate everyday applications from OS privilege.
  • System calls bridge the boundary, but the kernel still performs access checks and validation.
  • Drivers are high-impact code and deserve strict inventory, policy, and patch management.
  • Use CVEs to drive updates and hardening, not as a substitute for layered controls.
#windows-internals#kernel-security#system-calls#drivers
← All articlesAssess your Windows estate →