Kill Chain Reloaded: Abuse legacy paths for stealth persistence

Kill Chain Reloaded: Abusing Legacy Paths for Stealth Persistence

Speakers: Alejandro Hernando, Borja Martinez

Conference: DEF CON 33

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

Slides: https://media.defcon.org/DEF%20CON%2033/DEF%20CON%2033%20presentations/Alejandro%20Hernando%20Borja%20Martinez%20-%20Kill%20Chain%20Reloaded%20Abusing%20legacy%20paths%20for%20stealth%20persistence.pdf

Overview

Modern Windows security — Secure Boot, Virtualization-Based Security (VBS), Credential Guard, Hypervisor-Protected Code Integrity (HVCI), and kernel-level EDR telemetry — has raised the bar for maintaining persistence on a compromised system considerably. Yet real-world threat actors continue to find ways to persist below the operating system, leveraging bootkit-level techniques against systems that are nominally "fully protected." Alejandro Hernando and Borja Martinez, red teamers from the hacking department at a Spanish organization, present a systematic methodology for finding and weaponizing legacy UEFI drivers and vulnerable signed drivers to establish persistent, stealthy footholds on modern Windows systems.

The talk demonstrates that the threat represented by bootkits — once considered largely theoretical and the domain of nation-state actors — is practically relevant to red teamers today, not just to APTs. BlackLotus, which demonstrated Windows 11 boot compromise with Secure Boot enabled, provides the framing for why this research matters. The speakers extend the publicly known techniques by presenting their own threat-hunting methodology for identifying vulnerable legacy artifacts, a set of newly discovered UEFI vulnerabilities, and practical persistence techniques developed through real red team engagements.

This is a first-time DEF CON talk for both speakers, and it is dense with practical technical content spanning UEFI internals, the Windows Secure Boot PKI, the Bring Your Own Vulnerable Driver (BYOVD) technique category, and detection-evasion strategies at the boot level.

Background

▶ Watch: Threat context: real bootkits vs. red team techniques on Windows 11 Secure Boot (2:13)

The Bootkit Threat Landscape

A bootkit is malicious code that executes before the operating system, typically by modifying or replacing firmware or bootloader components. By executing before Windows, a bootkit can:

• Disable or bypass Secure Boot verification
• Patch the Windows kernel before its integrity checks run
• Install a kernel-mode rootkit that persists across reboots
• Defeat endpoint detection and response (EDR) products whose drivers load after the kernel

Historical bootkits (Alureon/TDL4, Rovnix) targeted the MBR/VBR of legacy BIOS systems. Modern bootkits (FinFisher bootkit, ESPecter, BlackLotus) target UEFI, which has become the standard firmware interface for all modern x86 and ARM hardware.

BlackLotus, disclosed in 2022–2023, demonstrated that Secure Boot on Windows 11 could be bypassed using a combination of a known-vulnerable boot manager (the "Baton Drop" vulnerability, CVE-2022-21894) and a UEFI bootkit that exploited the Windows Boot Manager's vulnerability to install a malicious bootloader. This was a watershed moment: it showed that a fully patched Windows 11 system with Secure Boot enabled was not immune to bootkit infection if the attacker could load any vulnerable but still-signed boot component.

BYOVD (Bring Your Own Vulnerable Driver)

BYOVD is a technique where an attacker installs a legitimate but vulnerable signed kernel driver to gain kernel-level code execution without needing an unsigned driver (which would be blocked by HVCI and Secure Boot). Since the driver is legitimately signed by a trusted certificate authority, Windows loads it without complaint. The attacker then exploits a known vulnerability in the driver to achieve kernel read/write or code execution primitives.

BYOVD has been used by ransomware groups (BlackMatter, Scattered Spider), APTs, and increasingly by red teamers. The challenge is sourcing drivers that are: (a) signed by a trusted CA, (b) not already in Windows' "blocklist" (the UEFI Secure Boot Forbidden Signatures Database, dbx), and (c) contain a known exploitable vulnerability.

Key Findings

▶ Watch: Discovery: signed bootloaders incorrectly excluded from the DBX blocklist (11:18)

Threat Hunting Methodology for Vulnerable Artifacts

The first significant contribution is a systematic methodology for finding vulnerable UEFI drivers and kernel drivers that can be weaponized. The methodology includes:

Firmware image analysis: Using tools like UEFI Tool, BINwalk, and custom scripts to extract and disassemble UEFI DXE drivers from firmware images collected from vendor update packages. Modern UEFI firmware images for popular motherboard vendors (ASUS, MSI, Gigabyte, ASRock) can be obtained from official update portals.

Static analysis pipeline: Running extracted UEFI drivers through automated binary analysis (Ghidra, IDA, BinNinja) with custom scripts that look for common vulnerability patterns: unsafe CopyMem calls with attacker-influenced size parameters, unsafe string operations in SMM handlers, lack of bounds checking in SW-SMI dispatch handlers.

Correlation with known vulnerability databases: Matching extracted driver code against the LoLDrivers project and other databases of known-vulnerable signed drivers to identify actionable targets.

Certificate chain analysis: Verifying that candidate drivers are still signed with certificates that chain to trusted UEFI CAs and are not present in the UEFI dbx (Secure Boot blocklist). This step is critical because Microsoft regularly updates the dbx to block previously discovered vulnerable drivers.

UEFI Vulnerabilities Discovered

Through their threat hunting methodology, Hernando and Martinez found multiple previously undisclosed vulnerabilities in UEFI software:

SMM (System Management Mode) Vulnerabilities: SMM is a privileged CPU mode that runs below Ring 0 (the OS kernel level) and is used by UEFI for power management, hardware abstraction, and certain BIOS compatibility functions. SW-SMI handlers — which respond to software-generated System Management Interrupts — in multiple vendor UEFI firmware images contained:

• Stack overflow vulnerabilities from unsafe buffer operations in SW-SMI dispatch code
• Arbitrary read/write primitives from SMM handlers that accepted attacker-controlled pointers without validation

SMM exploitation is the "holy grail" of firmware persistence: code running in SMM has higher privilege than any OS component, executes in a memory region hidden from the OS, and can modify the boot process at will.

Abandoned UEFI Boot Options: The speakers identified UEFI boot option entries in shipping UEFI firmware that reference components or paths that no longer exist or are no longer maintained. These "abandoned" boot options can be hijacked by planting a malicious binary at the expected path on the EFI System Partition (ESP). When the system boots, the UEFI firmware executes the binary from the ESP path, which is now the attacker's payload.

This technique is particularly stealthy because the UEFI boot option is legitimate — it was placed there by the firmware — and the malicious binary is stored on the ESP, which is not normally subjected to file integrity monitoring.

Vulnerable Signed Drivers for BYOVD: Several new signed drivers were identified with exploitable vulnerabilities that were not yet in the Windows dbx blocklist at the time of research. Specific CVEs were filed for these findings.

Persistence via Abandoned Boot Paths

One of the most practically applicable techniques is the abandoned UEFI boot path hijack. The attack flow:

1. Enumerate UEFI boot option variables (accessible via Windows bcdedit or Linux efibootmgr, or directly via the GetVariable UEFI service) to find entries that reference paths on the EFI System Partition that do not exist or reference a binary whose signature is not validated
2. Plant a malicious bootloader or shellcode at the expected ESP path
3. If necessary, reorder the UEFI boot order to ensure the hijacked option executes early in the boot sequence

The technique requires write access to the EFI System Partition, which a kernel-mode attacker (or even an Administrator-level attacker in many configurations) can achieve. Once established, the persistence survives OS reinstallation (since the EFI partition is typically not wiped during a Windows reinstall), antivirus/EDR removal, and most incident response procedures short of full firmware reflash or EFI partition wipe.

Red Team Application

The speakers present their persistence techniques in the context of real red team engagements, noting which techniques were used against actual enterprise targets and what detection they observed or evaded. Key practical points:

• BYOVD using a driver not yet in the dbx is effective against HVCI-enabled systems, but the window between public disclosure of a driver vulnerability and its dbx blocklisting is narrowing
• Abandoned boot path persistence has not been observed to trigger EDR alerts in their engagements, as EDRs generally do not monitor EFI partition writes or UEFI boot variable changes
• Combining a BYOVD kernel exploit with the abandoned boot path persistence creates a self-reinstalling bootkit that can re-establish kernel code execution after a user-mode remediation

Technical Deep Dive

▶ Watch: Live demo setup: installing UEFI implant with Secure Boot enabled (20:13)

UEFI Architecture Relevant to Attacks

The UEFI boot process executes in phases:

• SEC (Security) — initial hardware initialization, trust root establishment
• PEI (Pre-EFI Initialization) — memory initialization, platform early boot
• DXE (Driver eXecution Environment) — the main UEFI driver loading phase; this is where most firmware vulnerabilities are exploitable
• BDS (Boot Device Selection) — where UEFI boot options are evaluated and the bootloader is launched

The DXE phase loads drivers from the firmware image and from the ESP. DXE drivers can register SMM handlers, interact with UEFI protocols, and access all physical memory. A malicious DXE driver that executes before Secure Boot verification completes can subvert the entire boot chain.

SMI Handler Exploitation

A SW-SMI is triggered by writing a value to I/O port 0xB2 (on x86). The UEFI SMM dispatcher then executes the registered handler for that SMI value. Many vendor UEFI firmware images register SW-SMI handlers for hardware compatibility, power management, and BIOS emulation purposes.

The attack requires:

1. Identifying a vulnerable SW-SMI handler via static analysis of SMM driver code
2. Triggering the SMI from kernel mode (a ring-0 attacker or a BYOVD driver can execute outb 0xb2, [value])
3. Passing a crafted buffer that exploits the vulnerability (e.g., a pointer to attacker-controlled data in OS-accessible memory)
4. Achieving code execution within SMM

SMM code execution is persistent across reboots (if the attacker can modify the UEFI firmware image) or temporary but hyper-privileged (for single-session attacks such as disabling secure boot enforcement or patching the hypervisor).

Secure Boot Key Hierarchy and Blocklist

The UEFI Secure Boot PKI involves:

• PK (Platform Key) — the root of trust, owned by the platform manufacturer
• KEK (Key Exchange Key) — authorized to update db and dbx
• db (Signature Database) — list of trusted signing certificates and binary hashes
• dbx (Forbidden Signatures Database) — list of explicitly distrusted certificates and hashes

Microsoft signs Windows boot components with a Microsoft certificate that chains to the UEFI db. When a vulnerable driver is publicly disclosed and added to the dbx, any UEFI firmware that has received updated Secure Boot variables will refuse to load that driver.

The research notes that updating dbx requires a UEFI variable update (which requires OS or firmware-level access), and many enterprise systems lag significantly in applying dbx updates because they are shipped as optional Windows updates that are not always included in standard patch management.

Demo / Proof of Concept

▶ Watch: Privilege escalation: chaining WPBT and custom UEFI table for kernel access (22:49)

The speakers demonstrate:

1. The threat-hunting pipeline extracting and analyzing UEFI DXE drivers from vendor firmware images and identifying vulnerable SMM handlers
2. Triggering a vulnerable SMM SW-SMI handler from kernel mode using a BYOVD driver, achieving code execution within SMM
3. The abandoned boot path hijack: writing a malicious payload to an ESP path referenced by an abandoned UEFI boot option, then rebooting to show the payload executing before Windows loads
4. A complete red team persistence chain: initial foothold → BYOVD kernel exploit → SMM modification to plant ESP-based bootkit → persistence surviving reboot and OS reinstall

Defensive Implications

▶ Watch: Result: fully signed, legitimately-appearing bootkit persistence achieved (33:43)

For defenders and blue teams:

• Monitor UEFI variable writes from user space and kernel space — legitimate software rarely modifies UEFI boot order variables. EFI partition file writes should trigger alerts.
• Apply UEFI dbx updates promptly. Microsoft delivers these as Windows updates (KB articles related to "Secure Boot DBX update"). Ensuring these are applied in patch management closes the window on known-vulnerable signed drivers.
• Enable HVCI (Hypervisor-Protected Code Integrity) and Memory Integrity — while not a complete defense against BYOVD (since a non-blocklisted driver still loads), it significantly narrows the available driver pool.
• Use Microsoft's Vulnerable Driver Blocklist (available in Windows Defender Application Control) to block a broader set of known-vulnerable drivers proactively.

For vendors:

• Audit UEFI firmware for abandoned or unnecessary boot option entries and SMM SW-SMI handlers before shipping
• Remove UEFI driver code that is no longer needed — abandoned handlers are attack surface
• Engage with Microsoft's MSRC to fast-track the addition of newly discovered vulnerable signed drivers to the dbx, shortening the window of exploitation

For incident responders:

• Include the EFI System Partition in forensic collection — check for unexpected binaries at paths referenced by UEFI boot option variables
• Dump and analyze UEFI boot variables (using tools like chipsec or UEFITool) as part of IR for suspected advanced persistent threats
• Full firmware reflash from a known-good vendor image is the only remediation for SMM-level persistence

Key Takeaways

• Bootkit-level persistence on Windows 11 with Secure Boot enabled is practically achievable by red teamers today, not just APTs — using abandoned UEFI boot path hijacking and BYOVD kernel exploitation.
• A systematic methodology for discovering vulnerable signed drivers and UEFI SMM handlers — combining firmware extraction, static analysis, and certificate chain verification — yields actionable BYOVD candidates that are not yet in the Secure Boot dbx.
• Abandoned UEFI boot options represent a stealthy and undermonitored persistence vector that survives OS reinstallation and most endpoint remediation procedures.
• SMM code execution, achievable via vulnerable SW-SMI handlers in common vendor UEFI firmware, provides ring-(-2) persistence that is essentially invisible to OS-level security tools.
• Defenders should treat EFI partition integrity and UEFI variable monitoring as first-class security controls, on par with OS-level file integrity monitoring.

About the Speakers

Alejandro Hernando is a red teamer and security researcher working in the hacking department at a Spanish organization. His work focuses on red teaming engagements and low-level security research into UEFI and kernel attack techniques.

Borja Martinez is also a red teamer in the hacking department at the same Spanish organization, with additional experience participating in CTF competitions as a member of the ID20 team. Both speakers presented at DEF CON 33 for the first time.