Bootkits and Rootkits: Two Malicious Drivers, One Chain

▶ Watch (3:55)

A bootkit is a malicious UEFI application. A rootkit is a malicious kernel mode driver. Both definitions are simpler than they sound. Any system runs legitimate kernel mode drivers at the highest privilege level inside the kernel. Make that malicious and you have a rootkit. UEFI firmware loads the Windows Boot Manager from the EFI System Partition. Make that application malicious and you have a bootkit. Three files matter for development: the Windows Boot Manager, the Windows OS Loader, and the Windows NT kernel.

Secure Boot and DSE: What Blocks Installation

▶ Watch (7:20)

Secure Boot enforces a chain of trust through digital signatures. Every boot component must be signed by a trusted vendor. A malicious UEFI application won’t run unless signed by a key the firmware trusts. Exploit a weakness or inject your own key and every protection downstream collapses. Driver Signature Enforcement (DSE) blocks unsigned kernel mode drivers separately. If Secure Boot holds, the Bring Your Own Vulnerable Driver technique still works: load a legitimate signed driver with a known vulnerability, exploit it to run code in kernel space, then load the rootkit from there.

Hooking Through the Boot Chain, Stage by Stage

▶ Watch (12:24)

The bootkit replaces the Windows Boot Manager with a malicious UEFI application. That application hooks a firmware function responsible for loading the original boot manager. Once the original loads into memory, the bootkit scans it with a byte pattern to find the function called when the next component arrives in memory. It patches that function’s entry point with an assembly trampoline, redirecting execution to a custom handler then back to the original. The same approach repeats at each stage: hook inside the Boot Manager when the OS Loader lands, hook inside the OS Loader when the NT kernel lands.

What a UEFI Application Can Do Before the OS Loads

▶ Watch (16:31)

UEFI spans thousands of pages of specification covering memory management, file systems, and networking. A malicious UEFI application can fetch files from a remote server before the OS loads, modify partitions, and leave markers for later payloads. UEFI splits services into two zones: boot services (available only during early boot) and runtime services (available after the OS takes control). A DXE runtime driver exploits the runtime zone. This special UEFI driver stays in memory after boot, hooks runtime services, and provides a persistent backdoor capable of reading or writing anywhere in memory.

Six Techniques That Give the Rootkit Its Power

▶ Watch (23:12)

The rootkit implements six core techniques. Communication lets it receive instructions from a userland application or a C2 server. Direct Kernel Object Manipulation hides processes without triggering a blue screen. A keystroke logger captures input at the kernel level by intercepting keyboard packets. Network filtering uses the Windows Filtering Platform to block, alter, or capture traffic in real time. Windows Sockets Kernel (WSK) lets the driver make HTTP connections entirely in kernel space, no userland process needed. File system filtering uses minifilter technology to hide folders from the OS and security tools.

Live Demo: A Vulnerable Lenovo with Secure Boot Enabled

▶ Watch (32:51)

The final demo ran on a physical Lenovo with Secure Boot enabled. A firmware vulnerability in the UEFI made Secure Boot irrelevant. After installation (admin privileges required), the machine rebooted into the bootkit. A basic kernel mode driver dropped by the UEFI application then loaded the full rootkit on command. The rootkit hid the OneDrive process from Task Manager and Process Hacker, hid files on request, blocked IP address ranges, and concealed active TCP connections to port 443. All six capabilities ran on the compromised machine.

Notable Quotes

This is a safe place. Maria “drkrysSrng” San Jose · ▶ 2:20

specification, don’t bother with coffee. Alejandro “TheMalwareGuardian” Vazquez · ▶ 17:28

So this machine is fully compromised. Alejandro “TheMalwareGuardian” Vazquez · ▶ 35:35

There are no more levels. Okay. Alejandro “TheMalwareGuardian” Vazquez · ▶ 35:39

Key Takeaways

  • A UEFI bootkit runs before Secure Boot can stop it by exploiting firmware vulnerabilities in the chain
  • The DXE runtime driver persists after boot and provides a kernel-level read/write backdoor
  • Windows Sockets Kernel lets a rootkit maintain C2 entirely in kernel space with no userland process
  • The Bring Your Own Vulnerable Driver technique bypasses DSE without needing a Secure Boot exploit
  • Six standalone proof-of-concept files accompany the rootkit source, one per implemented technique

About the Speakers

Alejandro “TheMalwareGuardian” Vazquez is a security researcher and Red Team Operator specializing in Windows Internals, malware development, and advanced threat emulation. He developed Abyss and Benthic, the open-source bootkit and rootkit released at this talk. He conducts offensive security operations and teaches malware analysis, exploit development, bootkits, and rootkits in several master’s degree programs.

Maria “drkrysSrng” San Jose is a cybersecurity specialist with the Guardia Civil, Spain’s national military police force, serving in the Cybercrime Department of the Central Operative Unit on cybercrime investigations and threat intelligence. Before law enforcement, she built flight simulation systems for air navigation entities including ENAIRE and ROMATSA. She dedicates personal time to malware analysis and reverse engineering.