Chapter 1: Boot Security

Introduction

When you press the power button on a modern Windows computer, a complex chain of events unfolds long before you see the familiar login screen. This boot process represents the most critical—and often overlooked—attack surface in computing. Code that executes during boot runs before any operating system protections exist: before antivirus software loads, before Endpoint Detection and Response (EDR) agents initialize, and before Windows itself takes control.

For attackers, compromising the boot process is the ultimate prize. Malware that establishes itself at this level achieves what security researchers call "god mode"—it can hide from any security software, survive operating system reinstalls, and persist indefinitely. For defenders, understanding boot security is essential because traditional security tools are blind to threats at this layer.

This chapter explores the Windows boot process from a security perspective, examining both the protective mechanisms Microsoft has implemented and the sophisticated attacks that attempt to subvert them. We'll cover everything from UEFI firmware security to Secure Boot bypass techniques, giving you the knowledge needed to both attack and defend this critical system layer.

---

The Windows Boot Process: A Security Perspective

Before diving into specific attacks and defenses, let's understand what actually happens when a Windows system starts. Each stage represents both a security checkpoint and a potential attack vector.

Power On
    │
    ▼
┌─────────────────────────────────────────────────────────────┐
│ UEFI Firmware                                                │
│ ┌─────────────┐    ┌──────────────┐    ┌──────────────────┐ │
│ │ SEC Phase   │───▶│ PEI Phase    │───▶│ DXE Phase        │ │
│ │ (Security)  │    │ (Pre-EFI)    │    │ (Driver Exec)    │ │
│ └─────────────┘    └──────────────┘    └──────────────────┘ │
└─────────────────────────────────────────────────────────────┘
    │
    │ Secure Boot Verification
    ▼
┌─────────────────────────────────────────────────────────────┐
│ Windows Boot Manager (bootmgfw.efi)                          │
│ - Reads BCD (Boot Configuration Data)                        │
│ - Selects OS to boot                                         │
│ - Validates winload.efi signature                            │
└─────────────────────────────────────────────────────────────┘
    │
    ▼
┌─────────────────────────────────────────────────────────────┐
│ Windows Boot Loader (winload.efi)                            │
│ - Loads ntoskrnl.exe, HAL, boot drivers                      │
│ - Validates all loaded binaries                              │
│ - Initializes VBS if enabled                                 │
└─────────────────────────────────────────────────────────────┘
    │
    ▼
┌─────────────────────────────────────────────────────────────┐
│ Windows Kernel (ntoskrnl.exe)                                │
│ - Kernel initialization                                      │
│ - ELAM driver loading                                        │
│ - Boot driver initialization                                 │
└─────────────────────────────────────────────────────────────┘

The key insight here is that each stage must trust the one before it. If an attacker can compromise any early stage, they can manipulate everything that follows. This is why boot security matters so much—it's the foundation upon which all other security rests.

---

1. UEFI Firmware: The First Code to Run

Understanding UEFI

When you press the power button, the CPU doesn't start executing Windows code. Instead, it runs firmware—software permanently stored on a chip on your motherboard. Since the mid-2000s, this firmware has been UEFI (Unified Extensible Firmware Interface), which replaced the ancient BIOS standard that dated back to the original IBM PC.

UEFI is far more sophisticated than its predecessor. While BIOS was essentially a simple program written in 16-bit assembly, UEFI is a miniature operating system in its own right. It can run complex drivers, connect to networks, display graphical interfaces, and—most importantly for security—verify the integrity of code before executing it.

This sophistication is both a blessing and a curse. UEFI provides powerful security features like Secure Boot, but its complexity also means a larger attack surface. UEFI firmware can contain millions of lines of code, and vulnerabilities are regularly discovered.

Why Attackers Target Firmware

Firmware-level attacks are the holy grail for sophisticated threat actors, and here's why:

Persistence: Firmware survives everything—operating system reinstalls, hard drive replacements, and even most forensic analysis techniques. Once malware is in the firmware, it can reinfect the system indefinitely.

Stealth: Operating system security tools cannot see firmware. Your antivirus runs on top of Windows, but firmware runs before Windows. It's like trying to inspect a building's foundation while standing on the roof.

Control: Firmware runs first, so it can manipulate everything that comes after. It can patch the OS kernel as it loads, disable security features, or inject code into any process.

Trust: Security software fundamentally trusts the firmware. If the firmware says everything is fine, the OS believes it.

UEFI Boot Phases

UEFI boot occurs in distinct phases, each representing a potential compromise point:

SEC (Security) Phase: The very first code to run. It initializes the CPU, validates the firmware's integrity, and establishes the initial root of trust. Compromising this phase is extremely difficult but not impossible—it requires either physical access or exploitation of a pre-SEC vulnerability.

PEI (Pre-EFI Initialization) Phase: Initializes memory and prepares the system for the main UEFI environment. PEI modules (PEIMs) are loaded here, and a malicious PEIM could compromise everything that follows.

DXE (Driver Execution Environment) Phase: The main UEFI phase where drivers load, hardware initializes, and Secure Boot verification occurs. This is where most UEFI attacks focus because it's the most accessible phase.

Secure Boot: The Chain of Trust

Secure Boot is Microsoft's and the industry's primary defense against boot-level attacks. The concept is elegant: every piece of code must be digitally signed by a trusted authority before it can execute.

┌────────────────────────────────────────────────────────────────┐
│                    SECURE BOOT HIERARCHY                        │
├────────────────────────────────────────────────────────────────┤
│                                                                 │
│    ┌─────────────┐                                             │
│    │ Platform Key│  (OEM-controlled, rarely changed)           │
│    │    (PK)     │                                             │
│    └──────┬──────┘                                             │
│           │ signs                                               │
│           ▼                                                     │
│    ┌─────────────┐                                             │
│    │     KEK     │  (Key Exchange Key - Microsoft + OEM)       │
│    └──────┬──────┘                                             │
│           │ signs                                               │
│           ▼                                                     │
│    ┌─────────────┐         ┌─────────────┐                     │
│    │     db      │         │    dbx      │                     │
│    │ (Allowed)   │         │ (Revoked)   │                     │
│    └──────┬──────┘         └─────────────┘                     │
│           │ contains                                            │
│           ▼                                                     │
│    ┌─────────────────────────────────────────────┐             │
│    │ Microsoft Windows Production PCA 2011       │             │
│    │ Microsoft Corporation UEFI CA 2011          │             │
│    └─────────────────────────────────────────────┘             │
│                                                                 │
└────────────────────────────────────────────────────────────────┘

Here's how the hierarchy works:

Platform Key (PK): The root of all trust. Controlled by your computer's manufacturer (Dell, HP, Lenovo, etc.), this key rarely changes. Only someone with the PK can modify any other Secure Boot settings. Think of it as the master key.

Key Exchange Key (KEK): One level down from the PK. Microsoft and the OEM typically have KEKs, which allow them to update the signature databases without the PK. This is how Microsoft can revoke vulnerable boot loaders.

Signature Database (db): Contains the actual certificates and hashes that are trusted. If a boot loader's signature chains to a certificate in the db, it's allowed to run. On most systems, this includes Microsoft's UEFI signing certificates.

Forbidden Database (dbx): The blacklist. Contains signatures and hashes of known-bad boot loaders. Even if something would otherwise pass Secure Boot verification, it's blocked if it appears here. This is how Microsoft revokes vulnerable or malicious boot loaders.

The Secure Boot Verification Process

When your system starts with Secure Boot enabled, here's what happens:

1. UEFI firmware loads the Windows Boot Manager (bootmgfw.efi) from the EFI System Partition
2. Before executing it, UEFI calculates its hash and verifies its digital signature
3. The signature must chain to a certificate in the db (typically Microsoft's)
4. The hash must not appear in the dbx
5. If verification passes, the boot manager runs; if not, boot fails

This same process repeats for each subsequent component: the boot manager verifies winload.efi, which verifies the kernel, and so on down the chain.

---

2. Boot Attacks: Breaking the Chain

Despite Secure Boot's protections, determined attackers have found ways through. Understanding these attacks is essential for both offensive security professionals and defenders.

The BlackLotus Bootkit: A Case Study

In March 2023, security researchers documented BlackLotus, the first in-the-wild bootkit capable of bypassing UEFI Secure Boot on fully patched Windows 11 systems. This wasn't theoretical—it was being sold on underground forums for $5,000 and used in real attacks.

MITRE ATT&CK Reference: T1542.003 - Pre-OS Boot: Bootkit

BlackLotus matters because it demonstrated that Secure Boot wasn't the impenetrable barrier many assumed. Let's examine how it worked:

The Vulnerability (CVE-2022-21894 "Baton Drop"): Secure Boot's achilles heel is the dbx—specifically, the difficulty of getting all systems to update it. When Microsoft discovers a vulnerable boot loader, they add its hash to the dbx, but this update must actually reach every computer. BlackLotus exploited outdated Windows boot loaders that were legitimately signed but vulnerable, and hadn't yet been added to every system's dbx.

The Attack Chain:

Stage 1: Exploit Baton Drop
├── Identify vulnerable bootmgr.efi version not in target's dbx
├── Replace system boot loader with vulnerable version
└── Vulnerable loader passes Secure Boot (valid signature, not revoked)

Stage 2: Deploy Malicious Boot Components
├── Modify boot configuration (BCD)
├── Install malicious bootmgfw.efi
└── Executes before BitLocker decryption

Stage 3: Kernel Patching
├── Hook kernel as it loads
├── Disable Driver Signature Enforcement (DSE)
├── Disable Hypervisor-Protected Code Integrity (HVCI)
└── Disable BitLocker protections

Stage 4: Persistence
├── Load unsigned kernel driver
├── Establish C2 communication
└── Survive reboots and updates

The brilliance of BlackLotus was that it didn't break Secure Boot cryptographically—it simply found legitimate Microsoft-signed code that was vulnerable and used it as a stepping stone.

Detection Approaches:

Detecting BlackLotus and similar bootkits requires looking where traditional tools can't:

# Check Secure Boot status
Confirm-SecureBootUEFI

# Examine boot configuration for tampering
bcdedit /enum all

# Look for unexpected boot partition modifications
# (requires offline analysis or specialized tools)

The challenge is that by the time Windows loads and your security tools run, the bootkit has already compromised the system and can hide its presence.

BootHole (CVE-2020-10713)

While BlackLotus targeted the Windows boot chain, BootHole attacked GRUB2, the bootloader used by many Linux systems. However, it had implications for Windows systems too, because many enterprise environments dual-boot or use GRUB-based recovery tools.

The Vulnerability: A buffer overflow in GRUB2's configuration file parser (grub.cfg). Because GRUB2 is signed and trusted by Secure Boot, an attacker who could modify grub.cfg could execute arbitrary code in the boot environment.

Why It Matters: BootHole demonstrated that Secure Boot's trust model has inherent weaknesses. Once something is signed and trusted, Secure Boot can't prevent that trusted code from being exploited.

UEFI Firmware Implants

The most sophisticated adversaries don't just attack the boot loader—they attack the firmware itself. These implants are extremely rare because they require either physical access or exploitation of UEFI vulnerabilities, but they've been documented in the wild.

Notable Examples:

LoJax Deep Dive: LoJax, discovered in 2018 and attributed to APT28 (Fancy Bear), was groundbreaking because it demonstrated that UEFI rootkits weren't just theoretical. The attackers modified the SPI flash chip that stores UEFI firmware, implanting a malicious DXE driver that would reinstall their agent on every boot—surviving even OS reinstalls and hard drive replacements.

The attack used legitimate tools like RWEverything to read and write SPI flash, then injected a malicious module into the firmware image. Once installed, this module would execute during every boot and drop a Windows agent to disk, ensuring persistent access.

---

3. Measured Boot and TPM Integration

While Secure Boot prevents unauthorized code from running, Measured Boot takes a different approach: it creates an unforgeable record of what actually ran. This record is stored in the Trusted Platform Module (TPM), a specialized security chip present in most modern systems.

How Measured Boot Works

During boot, each component is "measured" (hashed) before execution, and these measurements are stored in the TPM's Platform Configuration Registers (PCRs). The TPM is designed so that these measurements cannot be modified after the fact—they can only be extended.

┌────────────────────────────────────────────────────────────────┐
│                    MEASURED BOOT PROCESS                        │
├────────────────────────────────────────────────────────────────┤
│                                                                 │
│  Boot Stage              PCR Extended    Measurement            │
│  ──────────────────────────────────────────────────────────────│
│                                                                 │
│  UEFI Firmware    ───▶   PCR[0]    ───▶  Hash(firmware)        │
│  UEFI Settings    ───▶   PCR[1]    ───▶  Hash(config)          │
│  Boot Manager     ───▶   PCR[4]    ───▶  Hash(bootmgfw.efi)    │
│  Boot Config      ───▶   PCR[5]    ───▶  Hash(BCD)             │
│  Boot Loader      ───▶   PCR[8-9]  ───▶  Hash(winload.efi)     │
│  Kernel/Drivers   ───▶   PCR[10]   ───▶  Hash(ntoskrnl + drivers)│
│                                                                 │
│                           │                                     │
│                           ▼                                     │
│                    ┌─────────────┐                              │
│                    │     TPM     │                              │
│                    │  PCR Values │  ◄── Cannot be modified     │
│                    │  Stored     │      Only extended          │
│                    └─────────────┘                              │
│                                                                 │
└────────────────────────────────────────────────────────────────┘

The key property is that PCR values can only be "extended," not set directly. Extending works like this: new_PCR = Hash(old_PCR || new_measurement). This means if even a single bit changes in any boot component, all subsequent PCR values change unpredictably.

PCR Assignments

Understanding which PCR stores which measurement is crucial for both attackers and defenders:

Remote Attestation

The real power of Measured Boot comes from remote attestation. A remote server can ask the TPM to prove what code ran during boot, and the TPM can cryptographically prove that the PCR values haven't been tampered with.

This enables scenarios like:

• Enterprise VPNs that only allow connections from systems that booted cleanly
• Cloud services that verify VM integrity before providing sensitive data
• Conditional access policies that require specific security configurations

BitLocker Integration

BitLocker disk encryption leverages Measured Boot in an elegant way. The disk encryption key can be "sealed" to specific PCR values. This means the key is only released if the system boots in exactly the expected configuration.

Normal Boot:
  PCR values match ──▶ TPM releases BitLocker key ──▶ Disk decrypts

Tampered Boot:
  PCR values differ ──▶ TPM refuses key ──▶ BitLocker recovery required

This is why bootkits like BlackLotus specifically target BitLocker—they need to either run before BitLocker checks occur or somehow bypass the PCR-based sealing.

TPM Attack Vectors

While the TPM is designed to be tamper-resistant, several attacks have been demonstrated:

Cold Boot Attack: If you can physically access a running system, you can freeze the RAM with compressed air, reboot to external media, and dump memory contents—potentially extracting BitLocker keys.

TPM Sniffing: The TPM communicates with the CPU over a physical bus (typically LPC or SPI). Sophisticated attackers with hardware access can intercept this communication to extract keys as they're transmitted.

Mitigation: Use TPM + PIN mode for BitLocker, which requires a PIN that's never transmitted over the bus, defeating both attacks.

---

4. Boot Configuration Data (BCD)

The Boot Configuration Data store replaced the old boot.ini file and controls how Windows boots. Understanding BCD is essential because attackers frequently manipulate it.

BCD Location and Structure

BCD is stored as a registry hive:

\EFI\Microsoft\Boot\BCD  (UEFI systems)
\Boot\BCD                 (Legacy BIOS)

Important BCD objects include:

BCD Attack Techniques

Attackers with administrator access can manipulate BCD to disable security features:

Disable Driver Signing:

bcdedit /set {current} nointegritychecks on
bcdedit /set {current} testsigning on

Disable HVCI:

bcdedit /set {current} hypervisorlaunchtype off

Enable Boot Debugging (disables many security features):

bcdedit /set {current} debug on
bcdedit /set {current} bootdebug on

Force Safe Mode (for persistence):

bcdedit /set {current} safeboot minimal

These changes persist across reboots and can prepare a system for further compromise.

BCD Defense

Monitoring BCD for unauthorized changes is critical:

# Export current BCD for baseline
bcdedit /export C:\bcd_backup.bin

# Compare with known good configuration
bcdedit /enum all | Out-File current_bcd.txt
Compare-Object (Get-Content baseline_bcd.txt) (Get-Content current_bcd.txt)

Windows Event Log captures some BCD changes:

• Event ID 4826: Boot Configuration Data loaded
• Event ID 4608: Windows starting up

---

5. Virtualization-Based Security (VBS) and Boot

VBS Architecture

Modern Windows can launch a hypervisor very early in the boot process. This hypervisor creates isolated execution environments called Virtual Trust Levels (VTLs).

┌─────────────────────────────────────────────────────────────┐
│                      HARDWARE                                │
│  ┌─────────────────────────────────────────────────────────┐│
│  │ CPU with VT-x/AMD-V, SLAT (EPT/RVI), IOMMU (VT-d/AMD-Vi)││
│  └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
                            │
                            ▼
┌─────────────────────────────────────────────────────────────┐
│                 HYPER-V HYPERVISOR                           │
│ ┌────────────────────────┐  ┌────────────────────────────┐  │
│ │    VTL 0 (Normal)      │  │    VTL 1 (Secure)          │  │
│ │                        │  │                            │  │
│ │  ┌──────────────────┐  │  │  ┌──────────────────────┐  │  │
│ │  │ Windows Kernel   │  │  │  │ Secure Kernel        │  │  │
│ │  │ (ntoskrnl.exe)   │  │  │  │ (securekernel.exe)   │  │  │
│ │  └──────────────────┘  │  │  └──────────────────────┘  │  │
│ │                        │  │                            │  │
│ │  ┌──────────────────┐  │  │  ┌──────────────────────┐  │  │
│ │  │ User Mode        │  │  │  │ Isolated User Mode   │  │  │
│ │  │                  │  │  │  │ (lsaiso.exe)         │  │  │
│ │  └──────────────────┘  │  │  └──────────────────────┘  │  │
│ └────────────────────────┘  └────────────────────────────┘  │
└─────────────────────────────────────────────────────────────┘

The key insight is that even if an attacker compromises the normal Windows kernel (VTL 0), they cannot access memory in VTL 1. This protects critical secrets and security code.

VBS Components

Attacking VBS

Because VBS provides strong protection, attackers focus on disabling it during boot (before the hypervisor launches) or exploiting vulnerabilities in the hypervisor itself.

Disabling VBS via BCD: As shown earlier, attackers with admin access can disable the hypervisor via BCD changes.

BYOVD to Disable VBS: Load a vulnerable signed driver, use it to write to kernel memory, and patch the code that checks for hypervisor presence.

Hypervisor Vulnerabilities: Rare but serious. Vulnerabilities like CVE-2021-28476 (Hyper-V RCE) could theoretically allow escape from VTL 0 to VTL 1.

---

6. Detection and Defense Strategies

For Red Teams

When assessing boot security, consider these approaches:

Enumeration:

# Check Secure Boot status
Confirm-SecureBootUEFI

# List boot configuration
bcdedit /enum all

# Examine UEFI variables (requires admin)
Get-SecureBootUEFI -Name PK
Get-SecureBootUEFI -Name KEK
Get-SecureBootUEFI -Name db
Get-SecureBootUEFI -Name dbx

Attack Surface:

• Secure Boot bypass typically requires finding signed-but-vulnerable boot loaders
• Physical access enables many more attack vectors (SPI flash modification, TPM sniffing)
• Virtual environments may have different Secure Boot implementations

For Blue Teams

Prevention:

• Keep UEFI firmware updated
• Ensure dbx is current (Windows Update typically handles this)
• Enable VBS and HVCI where supported
• Use BitLocker with TPM and PIN
• Implement Measured Boot attestation for critical systems

Detection:

# Regular Secure Boot verification
$sb = Confirm-SecureBootUEFI
if (-not $sb) { Write-Warning "Secure Boot disabled!" }

# Monitor boot file integrity
Get-FileHash -Path "C:\Windows\Boot\EFI\*" -Algorithm SHA256
Get-FileHash -Path "C:\Windows\System32\winload.efi" -Algorithm SHA256

# Check VBS status
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard

CHIPSEC Framework for firmware analysis:

# Check SPI flash protections
python chipsec_main.py -m common.spi_lock

# Check UEFI Secure Boot
python chipsec_main.py -m secureboot.variables

# Dump and analyze firmware
python chipsec_util.py spi dump firmware.bin

Event Log Analysis

---

7. MITRE ATT&CK Mapping

---

8. Summary

Boot security represents a fascinating intersection of hardware, firmware, and software security. The boot process is where trust begins, and compromising it grants attackers nearly unlimited control.

Key Takeaways:

1. UEFI firmware is the first code to run and represents a high-value target for sophisticated attackers. Compromising firmware provides persistence that survives OS reinstalls.

1. Secure Boot creates a chain of trust through digital signatures, but can be bypassed through signed-but-vulnerable code like the BlackLotus bootkit demonstrated.

1. Measured Boot and TPM provide an unforgeable record of what actually ran during boot, enabling remote attestation and BitLocker integration.

1. Modern attacks like BlackLotus demonstrate that boot security remains an active battleground, with new bypass techniques regularly discovered.

1. Defense requires both prevention (Secure Boot, updates, VBS) and detection (attestation, monitoring, integrity checking).

Understanding boot security is essential for any serious security professional. Whether you're conducting red team assessments or defending enterprise systems, the boot process represents the foundation upon which all other security rests.

---

References

• BlackLotus Analysis - ESET
• BootHole Vulnerability
• CHIPSEC Framework
• Microsoft Secure Boot Documentation
• MITRE ATT&CK - Pre-OS Boot
• TPM Specification
• UEFI Forum Specifications
• Windows Secure Boot Key Management