Infecting the Boot to Own the Kernel

Infecting the Boot to Own the Kernel

Speakers: Alejandro Vazquez, Maria San Jose

Conference: DEF CON 33

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

Slides: https://media.defcon.org/DEF%20CON%2033/DEF%20CON%2033%20presentations/Alejandro%20Vazquez%20Vazquez%20Maria%20San%20Jose%20-%20Infecting%20the%20Boot%20to%20Own%20the%20Kernel%20Bootkits%20and%20Rootkits%20Development%20Presentation.pdf

Overview

Bootkits and rootkits represent some of the most powerful and most feared categories of malware. They persist below the operating system, survive reinstallation, and can subvert every security control that runs on top of them. At DEF CON 33, security researchers Alejandro Vazquez and Maria San Jose delivered one of the most practically-grounded talks on bootkit and rootkit development ever presented at a major public conference — releasing a fully functional, documented UEFI bootkit and Windows kernel rootkit as open-source tools, along with a repository of over 400 curated research resources and environment-setup automation scripts.

The researchers were explicit about their intent from the opening: this is not theoretical. The malware works, it was demonstrated live on a physical Lenovo machine with Secure Boot enabled, and it is publicly available for study and research. Their reasoning — also explicit — is that understanding how these threats work in depth is the only way to build effective defenses against them. The talk ended with a live demo showing full kernel control established from a compromised boot environment.

Background

▶ Watch: What we are going to share with you today is a fully functional working piece... (0:37)

The UEFI Boot Stack

Modern PCs boot through the Unified Extensible Firmware Interface (UEFI), which replaced the legacy BIOS. The UEFI boot sequence proceeds as follows:

1. SEC (Security): CPU executes firmware from reset vector; initializes cache-as-RAM.
2. PEI (Pre-EFI Initialization): Platform hardware initialization; memory comes online.
3. DXE (Driver Execution Environment): UEFI drivers are loaded; services like file system access, networking, and security (Secure Boot verification) are available.
4. BDS (Boot Device Selection): Boot options are enumerated; the boot manager selects and loads the bootloader.
5. OS Loader: On Windows, bootmgfw.efi → winload.efi → kernel handoff.

Secure Boot, mandated on modern Windows-certified hardware, uses a chain of trust based on asymmetric signatures. Each component must be signed by a trusted key; unsigned components are rejected. The trust anchors are stored in firmware variables: PK (Platform Key), KEK (Key Exchange Key), db (authorized signatures database), and dbx (forbidden signatures database).

What is a Bootkit?

A bootkit is malware that executes during the boot process, before the operating system loads. By gaining control early in the boot chain, it can:

• Modify the OS kernel in memory before security software starts.
• Bypass Secure Boot (through vulnerabilities in the UEFI, signed shims, or boot manager).
• Install a rootkit that persists in kernel space even after the OS loads.
• Survive disk wipes and OS reinstallation (if stored in NVRAM or the EFI System Partition).

What is a Rootkit?

A rootkit operates within the running OS kernel, subverting its behavior from the inside. A kernel-mode rootkit can:

• Hide processes, files, registry keys, and network connections from user-space tools.
• Intercept and modify system call results.
• Disable or subvert security software (AV, EDR) that also runs in kernel space.
• Maintain persistent access that survives reboots if combined with bootkit persistence.

Why Release It Publicly?

The researchers gave three reasons for open-sourcing fully functional malware:

1. Defender education: AV, EDR, and OS vendors can use the implementation to improve detection capabilities.
2. Research acceleration: The boot/firmware research community is small and scattered; a working reference implementation accelerates academic work.
3. Transparency: Sophisticated nation-state and criminal actors already possess far more advanced versions of these capabilities. The asymmetry between attacker knowledge and public knowledge harms defenders.

Key Findings

▶ Watch: And here is the general idea. (12:52)

1. A fully functional UEFI bootkit can be developed with publicly available SDKs and documentation, and deployed on real hardware with Secure Boot enabled by exploiting known shim/bootloader vulnerabilities.
2. The Windows kernel's own driver loading mechanisms can be abused from a bootkit to inject unsigned kernel code — effectively establishing an advanced rootkit without exploiting a kernel vulnerability.
3. A documented, extensible codebase for both components (bootkit + rootkit) provides a foundation for defenders and researchers — the "400+ resource repository" gives researchers a structured path to build expertise.
4. The development environment for bootkit and rootkit research can be fully automated, reducing the setup barrier from days to hours.

Technical Deep Dive

▶ Watch: Now, let's take a moment to talk about the power of the UFI specification its... (19:39)

Bootkit Architecture

The bootkit presented consists of two primary components:

1. UEFI Module (Pre-handoff)

The bootkit is deployed as a UEFI application or DXE driver that executes during the DXE phase, before the OS bootloader runs. The UEFI module hooks the EFI Boot Services table — specifically the LoadImage and StartImage functions, which are called when each subsequent boot component is loaded.

By hooking LoadImage, the bootkit intercepts the loading of bootmgfw.efi (the Windows Boot Manager). It can then:

• Patch the binary in memory before execution begins.
• Inject additional code into the boot manager's execution context.
• Disable or spoof Secure Boot measurement reporting.

2. Boot Manager Patcher

Once inside the Windows Boot Manager's execution context, the bootkit applies a second stage of patching to winload.efi. Specifically, it targets the kernel integrity verification functions — the routines that check that ntoskrnl.exe and other boot drivers are properly signed. By patching these checks, the bootkit allows unsigned kernel code to be loaded.

The researchers demonstrated two patching approaches:

• In-memory patching: Modify the verification function to always return success (return value forgery).
• Code cave injection: Insert shellcode into a code section of the bootloader and redirect execution to it, giving the shellcode an opportunity to set up additional hooks before returning to the normal flow.

Bypassing Secure Boot

The demo machine (Lenovo H series laptop) had Secure Boot enabled. The bootkit bypassed it using a vulnerable signed UEFI component in the device's firmware — a known but unrevoked entry in the Secure Boot db. The researchers were deliberate that this is not a new Secure Boot bypass but an illustration that Secure Boot's security depends on the revocation database (dbx) being current, and many production devices are not updated. Using an old, legitimately-signed bootloader or UEFI driver that contains known vulnerabilities is sufficient to gain pre-OS execution even with Secure Boot "on."

Kernel Rootkit Implementation

Once Windows loads with the integrity checks bypassed, the bootkit arranges for a kernel-mode driver to be loaded. The rootkit driver implements the following capabilities (as detailed in the talk):

Process Hiding

• Walks the EPROCESS doubly-linked list (ActiveProcessLinks) in the Windows kernel.
• Unlinks the target process from the list, making it invisible to tasklist, Task Manager, and other tools that enumerate via the list.
• Handles watchdog checks by also patching PspCidTable entries.

Driver Hiding

• Manipulates PsLoadedModuleList to remove the rootkit driver itself from the module list.
• Patches callbacks registered via PsSetLoadImageNotifyRoutine to intercept notification attempts.

DKOM (Direct Kernel Object Manipulation)

• All hiding operations work by directly modifying kernel data structures — no hooking of system calls, making them more resistant to integrity-check tools that look for SSDT hooks.

Communication Channel

• The rootkit registers a device object (hidden from standard device enumeration) that a userland controller communicates with via DeviceIoControl. Commands include: hide process, unhide process, inject DLL, list hidden items.

Kernel Code Signing Bypass via Boot Patching

Windows Kernel Mode Code Signing (KMCS) requires all kernel drivers to be signed with a trusted certificate. The bootkit circumvents this at a lower level: by patching winload.efi to skip the integrity verification of ntoskrnl.exe itself, it ensures that when the kernel loads, it does so without the verification machinery intact. Specifically, the PatchGuard initialization and the CI.dll (Code Integrity) component that enforces KMCS are either patched or bypassed as part of the bootkit's payload delivery.

Demo / Proof of Concept

▶ Watch: Um but also standalone proof of concepts for each uh example. (36:27)

The live demo was conducted on a physical Lenovo H-series laptop running Windows (the specific build was not stated). Key observations:

1. The laptop booted normally from a modified EFI System Partition containing the bootkit alongside the standard boot files.
2. Windows loaded to the desktop — appearing completely normal.
3. A demonstration process (e.g., a test executable) was launched and its PID confirmed visible in Task Manager.
4. A command was sent to the rootkit driver to hide the process.
5. Task Manager and tasklist no longer showed the process — but the rootkit's own query command confirmed it was still running.
6. The Lenovo laptop's firmware had Secure Boot enabled throughout; the audience was shown that Secure Boot remained "on" in the firmware settings even while the bootkit operated.

The speakers noted that this exact implementation would be caught by several commercial EDR products — the goal was educational, not evasion-focused. They pointed to the 400+ resource repository for those who want to explore detection-evasion techniques further.

Defensive Implications

▶ Watch: demo, we have the vulnerable computer right here. (44:31)

Detection

• Secure Boot + current dbx: Keep the Secure Boot revocation database updated via Windows Update. Unrevoked vulnerable signed components are the most common Secure Boot bypass vector.
• Measured Boot + TPM attestation: If Secure Boot cannot be trusted to prevent malicious boot code, measured boot (which records what actually loaded) can detect tampering retrospectively through remote attestation.
• Kernel integrity monitoring: Tools that periodically verify the integrity of kernel code sections and key data structures (EPROCESS list consistency, etc.) can detect DKOM-based rootkit activity.
• UEFI firmware integrity scanning: Endpoint security products that can scan the EFI System Partition for unauthorized UEFI applications should detect this bootkit class.
• Boot logs and event auditing: Windows event log sources covering boot integrity (Microsoft-Windows-Kernel-Boot) and code integrity (Microsoft-Windows-CodeIntegrity) generate events on policy violations that should be monitored.

Hardening

• Enable Virtualization-Based Security (VBS) and HVCI: Hypervisor-Protected Code Integrity (HVCI) runs code integrity checks in a hypervisor-protected environment, making kernel patching much harder because the attacker must also compromise the hypervisor.
• Enable Kernel DMA Protection: Prevents DMA-based attacks against the boot process.
• Disable test signing: Ensure production systems do not have Kernel Mode Code Signing in test mode.
• Firmware password: Prevents trivial modification of UEFI boot order or Secure Boot settings.
• Restrict EFI System Partition write access: Ensure that only the OS installer and authorized update mechanisms can write to the ESP.

Key Takeaways

• A fully functional UEFI bootkit capable of bypassing Secure Boot and establishing kernel-level control on real hardware is now publicly available as an educational research project.
• The attack chain — UEFI module → boot manager patching → kernel rootkit — is well-documented and reproducible from the released code.
• The root bypass mechanism relies on unrevoked vulnerable signed boot components — maintaining Secure Boot dbx currency is essential.
• VBS/HVCI is the most effective defense against the kernel-level rootkit techniques demonstrated; it makes direct kernel object manipulation significantly harder.
• The 400+ curated resources and automated setup scripts lower the barrier to entry for boot-security research, which benefits both attackers and defenders.
• The researchers' philosophy: making this knowledge public accelerates defensive research more than it empowers attackers, who already have access to far more sophisticated tools.

About the Speakers

Alejandro Vazquez describes himself as a gentleman exploring UEFI and (not) creating scammers. His background is in UEFI and pre-boot security research, with hands-on development experience building both defensive tools and offensive proof-of-concept malware to probe the boot security boundary.

Maria San Jose brings a law enforcement and malware analysis background to the research — she has spent years analyzing malware for a law enforcement cybercrime department. Her combination of forensic analysis skills and kernel-level development experience gives the project a grounded, threat-intelligence-informed perspective. Together, the pair developed the bootkit and rootkit as a collaborative project to bridge the gap between academic boot-security research and practical, demonstrable threat tooling.