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.

It should be noted that, 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 amount of documentation of internals, but it's not the best and is missing a lot of information. 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. It showed the source code and through it the 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... Let's look at the full picture. While the division into two different 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. You see, 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, such as a POSIX subsystem, OS/2 subsystem, security subsystem, and of course win32 subsystem. As Microsoft already has a monopoly in desktop computers, these have become largely obsolete. The security subsystems 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 also 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 these other components, since these aren't independent entities, but instead they are tools used by most of these user mode components.

User applications

This is what the user really sees, the applications they choose to use, such as your browser. Basically all applications that aren't system processes/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. In previous articles we've already went over internals from the perspective of user applications, so let's not dwell on this too much...

System processes

Windows also uses several user mode processes to handle some fundamental function of the operating system. These include programs such as lsass.exe, explorer.exe, svchost.exe, smss.exe, csrss.exe, winlogon.exe, wininit.exe, and others.

The Local Security Authority Subsystem Service (lsass.exe) is responsible for enforcing security policies, authentication, authorization and credential management. It enforces security policies configured through group policy or local security settings, and validates user logins by comparing them against those found in the Security Accounts Manager (SAM) for local users, or Active Directory domain controllers, depending on system configuration. It also generates, validates, and stores access tokens. LSASS.exe caches various credential types in memory including NTLM password hashes, Kerberos Ticket Granting Tickets (TGTs), and service tickets, and it is also an elevated process, making it a prime target for malicious actors.

The Windows Explorer (explorer.exe) provides a graphical user interface for exploring and interacting with the file system, but it also handles some other things such as the taskbar in the bottom of your screen.

The Session Manager Subsystem (smss.exe) is primarily responsible for initiating new sessions. It is also 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 operating system, as well as csrss.exe and winlogon.exe for Session 1, which is the user session. The first child instance creates other child instances in new sessions, done by copying itself into the new session and self-terminating.

The Client Server Runtime Subsystem (csrss.exe) is a critical process running indefinitely and its primary responsibilities are to oversee the Win32 console window, as well as process thread creation and deletion. It is also responsible for making the Windows API available to other processes, mapping drive letters, and handling the Windows shutdown process.

The Service Host (svchost.exe) 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 operating system, without needing to run each as a standalone executable. To run services, svchost can be provided a parameter outlining the group. These groups are defined in the registry, where it also lists their path. These services are almost always PE files, typically DLLs. As svchost.exe is always running, has a digital certificate from Microsoft, is often elevated and survives rebooting, it is a prime target for malicious actors.

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 up at boot. It maintains a database of services, and provides a unified and secure means of controlling them. They can run under different user accounts and can be configured automatically restart upon failure.

A list of services can be viewed with services.msc or directly in the registry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\. Taking a look at these registry entries may be useful in understanding how these services are used. It is not just a simple list, but also configures everything from startup to security contexts.

There are multiple ways to create a service. You can use interfaces, such as sc.exe, you can directly modify the registry, or you can use the API functions, or PowerShell cmdlets such as New-Service.

Kernel mode components

The actual kernel is divided into two major components: the executive and the core kernel. Kernel drivers can be thought of as extensions to the kernel_. Note that different resources may refer to the "core kernel" with varying names._

The Executive

The Executive forms the upper part of the kernel, it contains most of the kernel's functionality, and is contained in the ntoskrnl.exe file. Its responsibilities include handling of I/O, object management, system service dispatching, security and process management, among others. System calls are also implemented at this layer.

The executive layer is divided into multiple subsystems, or managers, which are in charge of different responsibilities. The managers typically provide a set of routines for use by kernel drivers and other kernel components. These routines' names typically have a prefix corresponding to the component responsible for said routine.

The executive layer's subsystems include the Object Manager (prefixed "Ob"), Memory Manager (prefixed "Mm"), Process Manager (prefixed "Ps"), I/O Manager (prefixed "Io"), Plug & Play Manager (actually a subsystem of I/O manager), Power Manager (prefixed "Po"), Configuration Manager (prefixed "Cm"), and the Security Reference Monitor (prefixed "Se"). Together they form executive services. Routines that are grouped together as a generic interface to the Executive Library are usually prefixed with "Ex". These managers will be covered in more detail in another article...

In addition to the managers, the kernel includes several support components that provide common services used by the kernel (and some user mode components). These include the Runtime Library (Rtl), Local Procedure Call (Lpc), and the Windows Management Instrumentation (WMI).

Core kernel

The core kernel is the lower part of the kernel and it sits between the e_xecutive_ layer and the Hardware Abstraction Layer (HAL) which is the lowest (helper) layer before hardware. It is in charge of tasks close to hardware and often time-critical, such as thread scheduling and dispatching, interrupt and exception handling, trap handling, as well as initializing critical device drivers at boot up. It performs almost all tasks of a traditional microkernel. It abstracts away details of the kernel, for the layers above it. These routines often use the prefix "Ke".

Kernel drivers

Kernel drivers are essentially extensions to the kernel. Drivers are software running in kernel mode, contained in a PE file (.sys). The operating system uses device drivers to allow for software to interact with hardware devices. There are multiple types of drivers, including function drivers, bus drivers, filter drivers, and software drivers, latter of which aren't tied to hardware devices. For an attacker, drivers are a very juicy target.

Function drivers handle the actual interaction with hardware devices and are the main driver for a device. They provide the interface between the hardware and the OS, as well as implementing core functionality of the device. This includes handling I/O, interacting with hardware and managing device initialization and shutdown.

Bus drivers are responsible for managing a group of child devices that are discovered on a physical or logical bus (for example USB, PCI or ACPI). They enumerate devices, manage power, and resource allocation, and forward requests down the stack. Bus drivers act as the function driver for the bus controller itself.

Filter drivers are additional drivers used to extend or restrict behavior, and they can sit below or above function drivers. Examples of functionality include monitoring of hardware behavior, security checks, and data transformation.

User mode drivers also exist, and are used in applications such as printers and webcams. They function as a bridge between a user mode application and hardware, utilizing a "reflector" driver to communicate with the kernel. From a security point of view, they are not interesting to us...

tip

From an attacker's perspective, kernel drivers are an extremely high-value target. Kernel mode access provides almost limitless access to the system.

Hardware Abstraction Layer (HAL)

The Hardware Abstraction Layer (HAL) is the layer between the kernel and hardware. Its purpose is to hide differences in hardware (motherboards, interrupt controllers, multiprocessor configurations, etc.), providing a consistent platform for software, simplifying driver development, and enhancing OS portability across hardware.

Despite the design, it doesn't entirely reside below the kernel, instead all known HAL implementations depend in some measure on the core kernel, or even the Executive. In practice, this means that kernel and HAL variants come in matching sets that are specifically constructed to work together.

The HAL is implemented in hal.dll and runs in kernel mode. The HAL implements a number of functions that are implemented in different ways by different hardware platforms, which in this context, refers mostly to the chipset. Other components in the operating system can then call these functions in the same way on all platforms, without regard for the actual implementation.

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 provides a single function for this purpose that works with all kinds of interrupts by various chipsets, so that other components need not be concerned with the differences.

Further reading

Architecture of Windows NT - Wikiwand

Windows Internals: Hardware Abstraction Layerlibrary.mosse-institute.com

A Low-Level View of the Windows 11 Kernel: Architecture, Mechanisms, and InnovationsLinkedInEditors