Booting into Breaches: Hunting Windows SecureBoot's Remote Attack Surfaces

Booting into Breaches: Hunting Windows Secure Boot's Remote Attack Surfaces

Speaker: Andrew Yang, Security Researcher, CyberKunlun

Conference: Black Hat USA 2025 — August 6-7, 2025, Mandalay Bay, Las Vegas

YouTube: https://www.youtube.com/watch?v=p4EXzE0dvWE

Reading Time: ~9 minutes

Type: Briefing

TL;DR

Andrew Yang of CyberKunlun submitted 55 vulnerability reports to MSRC, accounting for nearly 60% of all Windows Secure Boot Security Feature Bypass CVEs issued in the past decade. What makes his research distinctive is that the majority of his findings are exploitable remotely over the network via PXE boot, without physical access — a scenario prior research had largely ignored. The persistent PCA 2011 certificate on most hardware remains a viable exploitation bridge for all findings even today.

Introduction

Windows Secure Boot has received relatively little security research attention: in the ten years prior to Yang's work, only eight CVEs had been issued against it, two of which powered the BlackLotus bootkit. Yang's first Black Hat presentation upends that scarcity. By focusing on attack surfaces reachable through PXE (Pre-boot eXecution Environment) network booting — a standard feature used in enterprise diskless environments, virtualization platforms, and automated OS deployment — he found vulnerabilities with network-exploitable Remote Code Execution characteristics that bypass Secure Boot entirely.

The common thread enabling remote exploitability is the PCA 2011 certificate: a default UEFI Secure Boot certificate that is embedded in countless motherboard firmwares and virtualization platforms and will not expire until 2026. Any bootloader signed by this certificate is trusted by default, meaning attackers who can present a vulnerable signed bootloader to a PXE-booting machine have a path to exploitation without needing to bypass Secure Boot at the chain level.

Research Scale and Methodology

▶ Watch: Research Summary (06:00)

Yang submitted 55 reports to MSRC over the research period:

• 35 found via code audit, 20 via fuzzing
• 25 related to BCD (Boot Configuration Data) registry processing
• 16 related to filesystem parsing (FAT, NTFS)
• 6 related to network protocol handling in the bootloader
• 5 occurring in the Windows kernel during early initialization

To reduce duplicate submissions, Yang analyzed fixes from the developer's perspective — tracing root causes, understanding whether engineering teams addressed classes of bugs or individual instances, and comparing binary diffs using BinDiff to locate renamed functions after design-level changes.

A critical observation: Yang established that each Microsoft bootloader loads at a fixed base address. ASLR in the bootloader is essentially non-functional — he could read the load address from a Hyper-V minidump and perform targeted writes and ROP chains without any information leak primitive.

Attack Surface 1: Network Protocols in the PXE Bootloader

▶ Watch: Network Protocol Vulnerabilities (08:00)

The bootloader supports four main network protocols: IPv4, TCP/IP, HTTP, and WDS multicast. Yang found six vulnerabilities in the protocol stack:

• Two stack overflows in the PXE bootloader when parsing DHCPv6 response packets. Root cause: a function fails to validate that a client server identifier length is larger than the 16-byte destination array on the stack. Old-school overflow, yet present in production bootloader code for years.
• One recursive call when processing TFTP protocol — highly exploitable in the UEFI environment (see below).
• One recursive call during longhand self-reloading.
• One integer underflow when processing HTTP responses in the bootloader.
• A denial-of-service in IPv6 (assigned moderate severity; Microsoft explicitly excludes DoS from Secure Boot security scope).

Successful exploitation of the stack overflows allows control of RIP and other registers, enabling ROP chains. Since no information leak is required (fixed load addresses), exploitation is "so easy," as Yang put it.

Attack Surface 2: BCD Registry Processing

▶ Watch: BCD Vulnerabilities (12:01)

The Boot Configuration Data store is a registry-format database that controls how Windows boots. Yang found 25 vulnerabilities in BCD element processing code, concentrated in a single 100-line function named with the word "sanitize" — a function explicitly designed to reject illegal device objects from attacker-controlled data. That single function contained:

• 2 stack overflows capable of overwriting the return address
• 1 arbitrary memory write
• 3 heap out-of-bounds writes

Yang's account of dealing with duplicate reports here is instructive: after MSRC applied a "design-level change," they claimed three heap OOB reports were already fixed. Yang ran his PoC on the patched bootloader and the heap corruption still triggered. After escalation, MSRC provided a detailed explanation. The lesson: when a component has large volumes of related vulnerabilities, verify patches against original PoCs rather than trusting vendor confirmation.

A key tool for BCD fuzzing is bcdedit, which can be used via Windows registry APIs to generate test cases. Yang identified that BOOT_ENVIRONMENT_DEVICE / BL_DEVICE type structures are particularly vulnerable and recommends treating them as a focal point during audit.

Recursive Calling in UEFI: Why It's Not Just a DoS

▶ Watch: Recursive Call Exploitation (18:01)

In user-mode Windows, recursive stack exhaustion typically results in denial of service. In the UEFI environment, it becomes a highly exploitable vulnerability. The reason is memory layout:

In the standard EDK2 UEFI memory model, writable memory exists before the UEFI stack region. When a recursive call overflows the stack boundary, it writes into this pre-stack memory, which may include interrupt stack frames or other critical UEFI environment variables. This converts what appears to be a DoS into an out-of-bounds stack write with real exploitation potential.

Yang used Hyper-V — the only virtualization platform that can generate minidumps from bootloader crashes without requiring firmware modification — as his primary research environment. Hyper-V also supports IPv6 PXE booting on firmware, making it ideal for network protocol testing.

Attack Surface 3: Filesystem Parsing (FAT and NTFS)

▶ Watch: Filesystem Fuzzing (22:01)

Sixteen vulnerabilities were found in filesystem processing, five found by code audit in functions whose names contained the keyword "fixup" and eleven found by fuzzing. Yang's filesystem fuzzing approach:

1. Reverse-engineer the filesystem format and read documentation.
2. Write a workable fuzzer targeting the specific filesystem.
3. Hot-patch already-found vulnerabilities before continuing — otherwise the fuzzer generates hundreds of unique-appearing crashes from the same root cause, wasting triage time.
4. Repeat until no new crashes emerge.

This approach found all 16 filesystem vulnerabilities in five days.

Beyond the Bootloader: Attack Surface in the Windows Kernel

▶ Watch: Kernel-Level Findings (30:03)

Yang extended his research into the early Windows kernel initialization phase, where Winload reads specific files from the Windows directory (under inf) that are later consumed by NTOS at a very early stage — before PatchGuard or other kernel protections are active.

Using Virtual KD / KDCOM hooking at KdDebuggerInitialize0, he was able to fuzz this INF file processing code. A fuzzer that initially appeared to find only null-pointer dereferences turned out to have found a genuine heap out-of-bounds write — the first Windows kernel memory corruption in Yang's career. MSRC's initial response was to close the case on the grounds that user data is not compromised when the system BSODs. Yang's counterpoint: the victim is running unsigned code at kernel level during the crash, which is a security concern regardless of data access.

The Two Bridges: Why Most PCs Remain Exploitable Today

▶ Watch: Persistent Exposure (34:03)

Yang identifies two structural reasons why his findings remain exploitable on most systems:

1. PCA 2011 bridge: The default PCA 2011 certificate is embedded in virtually all UEFI firmware and will not expire until 2026. Any vulnerable signed bootloader can be served over PXE. Patched OS versions do not help if the bootloader being served is from the PCA 2011 chain.
2. Patch branch bridge: Five of Yang's findings were fixed only in the PCA 2023 branch of the bootloader, not in PCA 2011. Systems running Windows 2022 or earlier, or Windows 11 23H2 without a manual switch to PCA 2023, remain vulnerable to those five issues even on fully updated systems.

A practical check: Yang points users to an open-source web tool (referenced in the slides) that can detect current Secure Boot status and certificate chain.

Notable Quotes

"To today, I have found nearly sixty percent of Secure Boot Security Feature Bypass vulnerabilities in Windows operating system in the last ten years." — Andrew Yang (04:00)

"A function with 'fixup' or 'sanitize' in its name could be very vulnerable." — Andrew Yang (36:03)

"There's no need to leak the bootloader address. You can perform specific address write and ROP directly." — Andrew Yang (26:02)

"Check twice after your patch is released, especially when you have found vulnerabilities in the same component at a very large volume. Don't be lazy." — Andrew Yang (36:03)

Key Takeaways

• PXE booting creates a real remote attack surface for Secure Boot vulnerabilities. Enterprise diskless environments and virtualization platforms are particularly exposed, with no local interaction required.
• ASLR is effectively absent in Microsoft's bootloader. Fixed load addresses allow targeted ROP attacks without an information leak primitive.
• Functions with "sanitize" or "fixup" in their names are vulnerability magnets. Yang found 6 bugs in a 100-line sanitization function and 5 RCEs across two "fixup" functions.
• Recursive calls in UEFI are exploitable RCEs, not just DoS. The EDK2 memory layout converts stack overflows into OOB writes targeting critical environment variables.
• Verify patches against original PoCs. Yang confirmed that three "fixed" heap OOB bugs still triggered on the patched bootloader — a design-level change had renamed the function but not corrected all vulnerable code paths.

Slides were not listed as available for this briefing.