Before you can secure, attack, or defend a Windows system, you need to understand how it is built from the ground up. Windows is not a monolithic block of code — it is a carefully layered architecture where each layer has distinct responsibilities, trust boundaries, and attack surfaces. This lesson lays the foundation for everything you will learn in this course.
As a security professional, you will constantly encounter terms like "kernel mode," "HAL," "NTLM hash," and "access token." Understanding where these concepts live in the Windows architecture will make you dramatically more effective at both offensive and defensive work.
💡 This course uses Windows 10/11 and Windows Server 2019/2022 as reference platforms. The core architectural concepts have remained consistent since Windows NT 3.1 in 1993, so this knowledge transfers across nearly all modern Windows versions.
Windows divides all code into two privilege levels: User Mode and Kernel Mode. This separation is enforced at the hardware level by the CPU's protection rings (Ring 3 for user, Ring 0 for kernel on x86/x64).
| Aspect | User Mode | Kernel Mode |
|---|---|---|
| Privilege Level | Restricted (Ring 3) | Full (Ring 0) |
| Memory Access | Own virtual address space only | Full system memory |
| Hardware Access | Must request via system calls | Direct access |
| Examples | Applications, services, subsystems | HAL, kernel, drivers |
| Crash Impact | Process terminates (BSOD rare) | System crash (BSOD) |
When a user application needs to perform a privileged operation — such as reading a file or opening a network connection — it must transition from User Mode to Kernel Mode through a system call (syscall). This transition is mediated by the Windows kernel and is a critical choke point for security monitoring.
The Windows architecture consists of several critical components that every security professional must understand. Here is a breakdown of the most important ones:
The Object Manager is one of the most security-critical components. Every resource in Windows — files, registry keys, processes, threads, mutexes, and even other objects — is represented as an object with a security descriptor. Understanding object-based security is essential for privilege escalation and defense.
Understanding the boot process is critical for detecting boot-level attacks such as bootkits and rootkits. The modern Windows boot sequence on UEFI systems follows this chain:
UEFI Firmware
→ Windows Boot Manager (bootmgfw.efi)
→ Windows Boot Loader (winload.efi)
→ Windows Kernel (ntoskrnl.exe)
→ Session Manager (smss.exe)
→ Client/Server Runtime (csrss.exe)
→ Windows Logon (winlogon.exe)
→ Service Control Manager (services.exe)⚠️ Secure Boot in UEFI is designed to prevent unauthorized bootloaders from executing. However, attackers with physical access or firmware-level exploits can bypass it. Always verify Secure Boot status in enterprise environments: Confirm-SecureBootUEFI in PowerShell.
Every running program in Windows is a process. Each process contains one or more threads (the actual units of execution). But from a security perspective, the most important concept is the **Access Token**.
When a user logs on, the Local Security Authority (LSA) creates an access token. This token contains the user's Security Identifier (SID), group SIDs, privileges, and integrity level. Every process created by that user receives a copy of this token. Windows uses the access token to make every authorization decision.
# View your current access token information
whoami /all
# View the integrity level of your current process
whoami /groups | findstr "Mandatory Label"
# List all privileges of the current token
whoami /privWindows implements Mandatory Integrity Control (MIC) through integrity levels assigned to both processes and objects. The four integrity levels are:
| Level | SID | Typical Use |
|---|---|---|
| Untrusted | S-1-16-0 | Anonymous/internet sandboxed processes |
| Low | S-1-16-4096 | Protected Mode Internet Explorer, sandboxed apps |
| Medium | S-1-16-8192 | Standard user processes (default) |
| High | S-1-16-12288 | Elevated/admin processes |
User Account Control (UAC) leverages integrity levels. When an administrator logs in, Windows creates two tokens: a filtered standard user token (Medium integrity) and a full admin token (High integrity). By default, processes run with the filtered token. When admin rights are needed, UAC prompts for consent, and the process is re-launched with the full token.
💡 UAC bypass techniques are a major category of privilege escalation attacks. Understanding how UAC works at the token and integrity level level is essential for both attackers and defenders. We will explore this in depth later in the course.
Several Windows processes are critical to understand from a security perspective. Malware often targets or impersonates these processes:
| Process | Purpose | Security Relevance |
|---|---|---|
| System (PID 4) | Kernel and driver host | Malware may inject here for stealth |
| smss.exe | Session Manager | First user-mode process; rarely targeted directly |
| csrss.exe | Win32 subsystem | Critical process; termination causes BSOD |
| winlogon.exe | Logon/lock screen | Credential interception target |
| lsass.exe | Local Security Authority | Primary target for credential dumping (Mimikatz) |
| services.exe | Service Control Manager | Manages Windows services; service abuse vector |
| svchost.exe | Service host process | Multiple instances; malware hides here |
| explorer.exe | Shell/File Manager | User shell; DLL injection target |
⚠️ lsass.exe (Local Security Authority Subsystem Service) is the single most targeted process in Windows for credential attacks. It stores NTLM hashes, Kerberos tickets, and sometimes plaintext credentials in memory. Protecting LSASS is a top defensive priority — enable LSA Protection (RunAsPPL) and Credential Guard in enterprise environments.
Verify exercises to earn ★ 100 XP and unlock next lab level.