Windows Architecture
Windows Architecture
The Windows operating system is a complex multi-layered system consisting of several interconnected components with different purposes and rules, forming an unified system. The layered components speak to each other to achieve objectives, working in a hierarchical fashion. Components lower in the stack of layers have more control.
An understanding of the structure and hierarchy of the operating system provides invaluable insight into possible detection points, and likely points of attack. It lets us understand what is really happening, and where things could go wrong.
As you may have noticed, Microsoft frequently takes a "security through obscurity" approach, and often either doesn't document inner workings at all, or poorly documents it, sometimes with missing pieces.
As of 2025, Microsoft has released some documentation of internals, but it's incomplete. Luckily, some talented reverse engineers have figured out and documented much of the internals. Additionally, Microsoft released an educational Windows Research Kernel in 2009, a portion of the Windows Server 2003 kernel — showing source code and internal architecture, which has largely remained the same to this day.
Earlier we briefly covered user-mode and kernel-mode, and explained how the transition between these modes happens (syscalls). Now we must go deeper. While the division into two privilege levels is a critical part of the design, within these two privilege levels, there are multiple components working together to form the full operating system.
User mode components
The user mode consists mainly of various processes, and DLLs used by those processes. For historical reasons, Windows has multiple subsystems within the user mode architecture. Microsoft didn't always have the market cornered, and in the early days they aimed to make it more flexible, making it possible to run programs designed for other kinds of operating systems.
Environment subsystems
The interface between user mode applications and kernel functions — such as using system resources — is called an environment subsystem. This design makes it possible to support programs made for different kinds of operating systems.
Historically, and in the Windows Research Kernel, there were multiple environment subsystems: a POSIX subsystem, OS/2 subsystem, security subsystem, and the win32 subsystem. As Microsoft already has a monopoly in desktop computers, these have become largely obsolete. The security subsystem's functions are largely covered by the Local Security Authority Subsystem (lsass.exe), and the POSIX subsystem has been replaced by the Windows Subsystem for Linux.
Subsystem DLLs
Windows provides a toolbox of libraries for interacting with the kernel and for performing other common tasks. This includes the core WinAPI of kernel32, kernelbase, and ntdll, but also libraries like combase, advapi32, as well as libraries for using the Graphics Device Interface (GDI).
These subsystem DLLs aren't their own component in the same way as other components — they are tools used by most user mode components rather than independent entities.
User applications
This is what the user really sees: the applications they choose to use, such as a browser. Basically all applications that aren't system processes or services. User applications consist of one or more isolated processes, which can load subsystem DLLs to interact with the operating system and use system resources.
System processes
Windows uses several user mode processes to handle fundamental functions of the operating system. These include lsass.exe, explorer.exe, svchost.exe, smss.exe, csrss.exe, winlogon.exe, wininit.exe, and others.
lsass.exe — The Local Security Authority Subsystem Service is responsible for enforcing security policies, authentication, authorization, and credential management. It validates user logins by comparing them against the Security Accounts Manager (SAM) for local users, or Active Directory domain controllers. It also generates, validates, and stores access tokens. LSASS caches various credential types in memory including NTLM password hashes, Kerberos TGTs, and service tickets — and as an elevated process, it is a prime target for attackers.
explorer.exe — Windows Explorer provides a graphical interface for navigating the file system, and also handles the taskbar.
smss.exe — The Session Manager Subsystem is primarily responsible for initiating new sessions. It is the first user mode process started by the kernel. It starts csrss.exe and wininit.exe in Session 0 (an isolated Windows session for the OS), and csrss.exe and winlogon.exe for Session 1 (the user session).
csrss.exe — The Client Server Runtime Subsystem is a critical process running indefinitely. Its primary responsibilities are to oversee the Win32 console window, process and thread creation and deletion, making the Windows API available to other processes, mapping drive letters, and handling the Windows shutdown process.
svchost.exe — The Service Host is responsible for hosting one or more Windows services in the background. It serves as a lightweight way to run multiple services required by the OS, without needing to run each as a standalone executable. As svchost.exe is always running, has a digital certificate from Microsoft, is often elevated and survives rebooting, it is a prime target for attackers.
Services
Windows services are long-running background services which operate even when no user is logged in. At the heart of this is the Service Control Manager (SCM, services.exe), which starts at boot. It maintains a database of services and provides a unified and secure means of controlling them.
A list of services can be viewed with services.msc or directly in the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\
Services can be created via sc.exe, direct registry modification, the Win32 API (CreateServiceA), or PowerShell (New-Service).
Kernel mode components
The kernel is divided into two major components: the Executive and the core kernel. Kernel drivers can be thought of as extensions to the kernel.
The Executive
The Executive forms the upper part of the kernel and contains most of its functionality, contained in ntoskrnl.exe. Its responsibilities include I/O handling, object management, system service dispatching, security, and process management. System calls are also implemented at this layer.
The Executive is divided into multiple subsystems (managers), each with a naming prefix used on their exported routines:
| Manager | Prefix | Responsibility |
|---|---|---|
| Object Manager | Ob | Kernel object lifecycle |
| Memory Manager | Mm | Virtual memory, paging |
| Process Manager | Ps | Processes and threads |
| I/O Manager | Io | I/O requests and dispatch |
| Power Manager | Po | Power state management |
| Configuration Manager | Cm | Registry |
| Security Reference Monitor | Se | Access control enforcement |
| Executive Library | Ex | Generic executive interface |
Support components providing common services include the Runtime Library (Rtl), Local Procedure Call (Lpc), and Windows Management Instrumentation (WMI).
Core kernel
The core kernel sits between the Executive and the Hardware Abstraction Layer (HAL). It handles tasks close to hardware that are often time-critical: thread scheduling and dispatching, interrupt and exception handling, trap handling, and initializing critical device drivers at boot. Routines here typically use the prefix Ke.
Kernel drivers
Kernel drivers are essentially extensions to the kernel — software running in kernel mode, contained in a .sys PE file. The OS uses device drivers to allow software to interact with hardware. There are several types:
Function drivers — Handle the actual interaction with hardware. They provide the interface between hardware and the OS, implement core device functionality, handle I/O, and manage device initialization and shutdown.
Bus drivers — Manage child devices discovered on a physical or logical bus (USB, PCI, ACPI, etc.). They enumerate devices, manage power and resource allocation, and act as the function driver for the bus controller itself.
Filter drivers — Extend or restrict behavior and can sit above or below function drivers. Used for monitoring hardware behavior, security checks, and data transformation.
From an attacker's perspective, kernel drivers are an extremely high-value target — kernel mode execution with no EDR hooks.
Hardware Abstraction Layer (HAL)
The HAL sits between the kernel and hardware. Its purpose is to hide hardware differences (motherboards, interrupt controllers, multiprocessor configurations, etc.), providing a consistent platform for software and simplifying driver development.
The HAL is implemented in hal.dll and runs in kernel mode. It implements functions that differ across hardware platforms — primarily chipset variations — so that other OS components can call them uniformly.
For example, responding to an interrupt is quite different on a machine with an Advanced Programmable Interrupt Controller (APIC) than on one without. The HAL abstracts this into a single function, so the rest of the kernel need not be concerned with hardware differences.