Bypassing Secure Boot and DSE: A Practical Guide to UEFI and Kernel-Mode Rootkits

TLDR: This research demonstrates how to achieve persistent, high-privilege system control by chaining UEFI bootkit deployment with kernel-mode rootkit execution. By leveraging known vulnerabilities in signed drivers to bypass Secure Boot and Driver Signature Enforcement (DSE), the researchers provide a fully functional framework for red team engagements. Security professionals should prioritize monitoring for unauthorized driver loads and auditing firmware integrity to defend against these low-level threats.

Modern endpoint security often assumes the operating system kernel is the ultimate source of truth. If you can compromise the kernel, you own the machine. But what happens when you compromise the process that loads the kernel? The research presented at DEF CON 33 on UEFI bootkits and kernel-mode rootkits shifts the focus from post-exploitation to pre-boot persistence, proving that if you control the boot flow, you control everything that follows.

The Mechanics of the Boot Chain

The boot process is a series of handoffs. Each component verifies the next before passing execution. A UEFI bootkit targets this chain by inserting malicious code early in the process. By hooking key functions in the Windows Boot Manager or the OS Loader, an attacker can maintain execution while the system initializes.

The researchers demonstrated that this isn't just theoretical. By using a custom UEFI application, they can modify the boot flow to drop a kernel-mode rootkit into memory before the operating system’s security features are fully active. Once the kernel is loaded, the rootkit operates with the highest possible privileges, allowing it to hide files, intercept network traffic, and manipulate system objects.

Bypassing Modern Defenses

Defenders rely on Secure Boot and Driver Signature Enforcement (DSE) to prevent unauthorized code from running at boot or within the kernel. However, these protections are only as strong as the chain of trust they enforce. The researchers highlighted how attackers bypass these controls by exploiting vulnerabilities in legitimate, signed drivers—a technique commonly known as Bring Your Own Vulnerable Driver (BYOVD).

By utilizing drivers with known flaws, such as CVE-2025-33043, CVE-2024-8105, CVE-2024-7344, CVE-2023-40238, or CVE-2022-21894, an attacker can execute arbitrary code in kernel space. Once the vulnerable driver is loaded, the attacker uses it to disable DSE or patch kernel structures, effectively rendering the OS security model moot.

Practical Red Teaming and Exploitation

For a pentester, this research provides a roadmap for persistent access that survives reboots. The provided UEFI Bootkit repository and Kernel-Mode Rootkit tools offer a starting point for simulating advanced persistent threats. During an engagement, the goal is to identify a path to drop these components onto the EFI System Partition (ESP).

The demo showed that once the rootkit is in memory, communication is handled via custom IOCTLs. This allows the attacker to send commands to the rootkit from user mode without needing administrative privileges for every interaction. For example, hiding a process is as simple as sending a specific IOCTL to the rootkit, which then unlinks the process from the active process list in the kernel.

// Example of sending an IOCTL to the rootkit to hide a process
DeviceIoControl(hDevice, IOCTL_HIDE_PROCESS, &pid, sizeof(pid), NULL, 0, &bytesReturned, NULL);

This level of control is devastating. It allows an attacker to remain invisible to standard EDR solutions that rely on kernel-mode callbacks or process enumeration, as the rootkit can intercept and filter the data returned to these security tools.

Defensive Considerations

Defending against boot-level attacks requires a shift toward hardware-backed security. Organizations should ensure that Measured Boot is enabled and that the Trusted Platform Module (TPM) is correctly configured to attest to the system state. Furthermore, the Microsoft Vulnerable Driver Blocklist should be strictly enforced to prevent the loading of known-bad drivers.

Auditing the ESP for unauthorized EFI applications is also critical. While these files are often overlooked, they are the primary vehicle for boot-level persistence. If you find an unknown .efi binary in the \EFI\Microsoft\Boot\ directory, treat it as a high-severity indicator of compromise.

Moving Forward

The barrier to entry for developing low-level malware has dropped significantly. With the release of these tools and the accompanying automation scripts, researchers can now easily build and test these techniques in a lab environment. This is a double-edged sword. While it enables better red teaming and adversary simulation, it also provides a ready-made toolkit for malicious actors.

Investigate your own environment. Use the provided resources to understand how these rootkits interact with the kernel and test whether your current security stack can detect the IOCTL communication or the unlinking of processes from the active process list. The era of assuming the kernel is untouchable is over. If you aren't looking at the boot process, you are missing the most critical part of the attack surface.