BOOTKITTY: Multi-OS Trust Chain compromise from Bootkit to Rootkit

BOOTKITTY: Multi-OS Trust Chain compromise from Bootkit to Rootkit

Speakers: Junho Lee (Student, Mokpo National University), HyunA Seo (Student, Sungshin Women's University)

Conference: CODE BLUE

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

Overview

The "BOOTKITTY: Multi-OS Trust Chain compromise from Bootkit to Rootkit" presentation at CODE BLUE by Junho Lee and HyunA Seo delved into the alarming capabilities of a novel hybrid bootkit designed to compromise the boot process across Windows, Linux, and Android operating systems. This talk illuminated how attackers can achieve persistent control over a system from the earliest stages of boot, even before the operating system kernel loads, effectively bypassing modern security mitigations like Secure Boot.

The core contribution of BOOTKITTY lies in its ability to establish a multi-stage hooking mechanism, extending control from the firmware or bootloader into the operating system kernel. By targeting critical points in the boot chain—such as UEFI phases, bootloaders like GRUB, and even the kernel decompression process—BOOTKITTY demonstrates a sophisticated approach to system compromise that is both difficult to detect and challenging to remediate. The research highlights the critical need for robust boot integrity verification and enhanced hardening measures to counter such advanced persistent threats.

This presentation is highly significant for the cybersecurity community, particularly for system architects, incident responders, and security researchers. It provides a detailed technical blueprint of how a multi-OS bootkit operates, exposing vulnerabilities in fundamental system components and illustrating the profound impact of compromising the root of trust. Understanding BOOTKITTY's techniques is crucial for developing effective defenses against the next generation of highly persistent and evasive malware.

Background

▶ Watch: Introduction to BootKitty and bootkit definition (0:00)

A bootkit represents an advanced class of malware that initiates its malicious activities before the operating system (OS) fully starts, typically by hijacking the bootloader or kernel during the boot process. Unlike a traditional rootkit, which operates within the OS kernel space, a bootkit gains control at an even earlier stage—often within the firmware or bootloader. This early execution grants the bootkit unparalleled control over the entire system, enabling it to disable security mitigations, evade anti-malware solutions, and maintain persistence across reboots by embedding itself in critical boot partitions. The persistent nature of bootkit threats is evidenced by annual reports detailing new analyses and attack vectors.

Modern systems predominantly utilize Unified Extensible Firmware Interface (UEFI), a firmware standard that supersedes the legacy BIOS. UEFI offers a more flexible, modular, and extensible architecture, supporting 32-bit or 64-bit modes and GUID Partition Tables (GPT) for larger storage devices. The UEFI boot process unfolds through several distinct stages: SEC (Security), PEI (Pre-EFI Initialization), DXE (Driver Execution Environment), BDS (Boot Device Selection), TSL (Transient System Load), and RT (Runtime). Among these, the DXE and BDS phases are particularly attractive targets for bootkit installation due to their critical roles in system initialization and bootloader selection.

The DXE phase is where most system initialization occurs, including the loading of System Management Mode (SMM) drivers and various UEFI drivers that activate hardware resources. A compromise at this early stage can corrupt the entire boot trust chain, impacting the subsequent OS. Following DXE, the BDS phase is responsible for identifying bootable devices, selecting an appropriate bootloader, and transferring control to it. The EFI System Partition (ESP), which contains the EFI images used during BDS, is accessible from within the OS, simplifying the installation or replacement of malicious EFI binaries for attackers. This accessibility makes the BDS phase a relatively easy target for hijacking the bootloader and gaining persistent control before kernel initialization.

To counter such threats, Secure Boot was introduced as a critical mitigation. Secure Boot verifies the cryptographic signatures of each bootloader and kernel component, blocking the execution of any untrusted code. However, as the research highlights, Secure Boot is not infallible. Various firmware vulnerabilities, configuration errors, and exploitable authentication mechanisms have repeatedly allowed attackers to bypass Secure Boot, rendering it ineffective against sophisticated bootkits. Once Secure Boot is circumvented, a bootkit can execute freely, disable kernel-level mitigations, and dismantle the entire security chain, paving the way for full system compromise.

Key Findings

▶ Watch: Introducing BootKitty: A multi-OS hybrid bootkit (6:00)

The central finding of this research is the development and demonstration of BOOTKITTY, a hybrid bootkit capable of compromising the trust chain across multiple operating systems: Windows, Linux, and Android. The speakers emphasize that BOOTKITTY is not merely another bootkit implementation but a comprehensive proof-of-concept that unequivocally demonstrates that once Secure Boot is bypassed, the door is open for the installation of virtually any bootkit. This bypass allows BOOTKITTY to hook the firmware and bootloader to gain control very early in the boot process.

BOOTKITTY achieves its multi-OS compatibility through environment-specific modules tailored to each operating system's architectural nuances. While the presentation focused primarily on Linux and Android due to time constraints, the overarching principle is consistent: gain control before the kernel starts, then progressively extend that control into the kernel itself.

Specifically, the key findings include:

1. Multi-Stage Hooking: BOOTKITTY employs a sophisticated multi-stage hooking technique, progressively hijacking control from the earliest boot stages (e.g., PEI, bootloader) into the compressed and then decompressed kernel space. This ensures deep and persistent compromise.
2. Secure Boot Bypass Exploitation: The research illustrates practical methods for bypassing Secure Boot. On Linux, this involves exploiting vulnerabilities related to the Machine Owner Key (MOK) system in Shim. On Android, it leverages an Odin authentication bypass vulnerability in the bootloader.
3. Kernel Mitigation Disablement: Once control is established, BOOTKITTY demonstrates the ability to disable critical kernel security mitigations, such as kernel module signing on Linux and various memory and access protections (mark_rodata_ro, security_capable) on Android, by patching verification functions to always return a "success" (zero) value.
4. Rootkit Loading from Early Boot: The bootkit facilitates the loading of a full-fledged rootkit into the kernel. On Linux, this is achieved via the LD_PRELOAD technique targeting the init process. On Android, it involves loading a custom RAM disk with rootkit modules and even C2 communication for dynamic rootkit deployment.
5. Persistent and Covert Compromise: By operating before the OS fully loads, BOOTKITTY achieves high persistence across reboots and remains highly covert, making detection by traditional endpoint security solutions exceptionally difficult.

In essence, BOOTKITTY provides a compelling demonstration of how a determined attacker can dismantle the fundamental security mechanisms of modern computing systems, moving from an initial bootkit compromise to a fully operational rootkit, thereby controlling the entire system from its very foundation.

Technical Deep Dive

▶ Watch: Linux: Bypassing kernel module signing for rootkit (11:30)

BOOTKITTY's technical sophistication lies in its ability to adapt its attack methodology to the distinct boot processes of Linux and Android, achieving deep and persistent compromise by meticulously targeting critical control points.

Linux Boot Chain Compromise

The Linux boot process, under UEFI, typically involves four main stages:

1. EFI loads the signed Shim bootloader.
2. Shim verifies GRUB's signature and loads it.
3. GRUB loads the kernel and initial RAM disk (initramfs) into memory.
4. The kernel starts system processes, including init.

BOOTKITTY strategically targets specific points within this chain:

1. Shim Stage (Secure Boot Bypass):

The initial entry point for BOOTKITTY on Linux systems involves exploiting an out-of-bounds write vulnerability, referred to as log_fail, during the very first PEI (Pre-EFI Initialization) stage of the boot process. This vulnerability allows an attacker to execute arbitrary code, critically enabling the registration of their own Machine Owner Key (MOK) in the system. The MOK system is an authentication mechanism used by Shim; if an attacker can register their MOK, any binary signed with that key is implicitly trusted by Secure Boot and allowed to execute. This effectively bypasses Secure Boot, allowing malicious code to be injected into the entire boot process.

2. GRUB Stage (Bootloader Hijack):

After bypassing Secure Boot, BOOTKITTY focuses on GRUB, the bootloader responsible for loading the kernel image into memory. This stage is considered ideal for implementing hooks before kernel execution. To achieve this, BOOTKITTY hooks the StartImage function. In a UEFI environment, StartImage is essential for executing any EFI image. By hooking StartImage, BOOTKITTY gains control over the kernel loading process, enabling it to inject code that will execute before the kernel fully takes over.

3. Kernel Stage (Deep Kernel Compromise):

At the GRUB stage, while control over kernel loading is achieved, the kernel image is often in a compressed state, making direct hooking of internal kernel functions impossible. To overcome this, BOOTKITTY employs a two-step process:

• Hooking decompress_kernel: The bootkit identifies and hooks the decompress_kernel function. This allows BOOTKITTY to gain control immediately after the kernel is decompressed into memory, providing access to its uncompressed code.
• Bypassing Kernel Module Signing: Once control over the decompressed kernel is established, BOOTKITTY targets the kernel module signing verification function. By patching this function to always return zero (effectively a NOP or JMP to RET 0), the signature verification process is disabled. This critical bypass allows BOOTKITTY to load unsigned or maliciously signed kernel modules (i.e., its rootkit component) without triggering security alerts or being blocked. The speakers confirmed that this bypass relies on signature-based detection of the verification function's assembly bytes.
• Rootkit Loading: With kernel mitigations disabled, BOOTKITTY loads its rootkit. The preferred method described is using the LD_PRELOAD technique. By setting the LD_PRELOAD environment variable for the init process (the first process executed after the kernel boots), a malicious shared object is loaded and executed first. This shared object then invokes a function to load the kernel module containing the rootkit, which seamlessly integrates into the kernel. The original init process then runs normally, making the compromise transparent to the user.

Android Boot Chain Compromise

The Android boot process, analyzed on Samsung devices, involves several exception levels:

1. ROM Stage (EL3): Code built into the device's ROM performs initial boot setup and loads the bootloader. This stage is generally hard to attack due to hardware embedding and limited known vulnerabilities.
2. Bootloader Stage (EL1): The bootloader (e.g., Little Kernel) loads the kernel into memory and prepares for its execution. This is a security-critical stage where Android Verified Boot checks kernel image integrity.
3. Kernel Stage (EL1/EL0): The kernel launches, loads main processes, and completes the boot.

BOOTKITTY's Android attack focuses on the bootloader and kernel stages:

1. Bootloader Stage (Initial Foothold and Code Execution):

BOOTKITTY exploits two critical vulnerabilities to gain initial control and execute arbitrary code:

• Odin Authentication Bypass: This vulnerability allows the bootkit to be installed into the boot partitions, circumventing the device's authentication mechanisms for flashing firmware.
• Heap Overflow Vulnerability: After installation, a heap overflow vulnerability is exploited within the bootloader to execute arbitrary code. This exploit allows BOOTKITTY to place a hook that intercepts the control flow just before the bootloader transfers control to the kernel.
• Hooking boot_linux_ft: Specifically, BOOTKITTY hooks the boot_linux_ft function, which is called when the bootloader loads the kernel into memory. Instead of jumping to the normal kernel entry point, the hook redirects execution to the BOOTKITTY's custom start address in memory.

2. Kernel Stage (Mitigation Disablement and Rootkit Deployment):

Once BOOTKITTY gains control before kernel execution, it proceeds to disable kernel mitigations:

• Disabling Kernel Protections: Android kernels include various protections like mark_rodata_ro (read-only data protection), SELinux, KASLR (Kernel Address Space Layout Randomization), and security_capable (capability checks). BOOTKITTY identifies where these protection logics are invoked and patches the relevant check functions (e.g., mark_rodata_ro, security_capable) to always return zero. This makes the system believe checks are performed, but the actual security enforcement is bypassed.
• Custom RAM Disk and Rootkit Loading: After disabling mitigations, BOOTKITTY invokes the init process of a custom RAM disk that it had loaded into memory. This custom RAM disk contains the attack payload and allows for early execution in the boot process. The rootkit modules included in this RAM disk are loaded.
• C2 Communication: The Android variant of BOOTKITTY can also connect to a Command and Control (C2) server to download additional rootkit modules to a persistent location, further extending its capabilities and ensuring dynamic updates and persistence. Since kernel mitigations are already disabled, the rootkit modules load without limitation, making them undetectable by user-space security solutions.

In both Linux and Android, BOOTKITTY's strategy is to establish control at the earliest possible stage, disarm built-in security mechanisms, and then seamlessly inject its rootkit components, leading to a fully compromised system that operates under the attacker's control.

Demo / Proof of Concept

▶ Watch: Linux BootKitty compromise demonstration (16:15)

The speakers provided compelling demonstrations for both the Linux and Android variants of BOOTKITTY, showcasing the full compromise process from initial infection to active rootkit operation.

Linux Demo

The Linux demonstration illustrated a bad USB-based attack scenario. The process unfolded as follows:

1. Preparation: The target Linux system had Secure Boot and lockdown modes enabled, representing a typical hardened environment.
2. Infection: A malicious USB device (simulating a bad USB) was plugged into the system. An installation script on the USB automatically ran, gaining root privileges, and proceeded to install the BOOTKITTY bootkit into the boot partition.
3. Reboot and Hijack: After the installation was complete, the system was rebooted. This triggered the modified boot process:

• The GRUB bootloader was hijacked, and hooks were injected into the kernel loading process.
• The decompression function of the compressed kernel space was subsequently hooked.
• Finally, the decompressed kernel was hijacked to disable security mitigations (like kernel module signing), and the rootkit was loaded via the LD_PRELOAD technique into the init process.

1. Compromise Confirmation: The demo video clearly showed the system booting with the bootkit active, confirming that the GRUB and kernel initialization stages were successfully hijacked, leading to a fully compromised system. The speakers noted that while this demo used a USB for installation, similar infection methods could be achieved through network-based attacks.

Android Demo

The Android demonstration showcased a scenario involving physical access and exploitation of bootloader vulnerabilities:

1. Preparation: A Samsung device was connected to a PC via a USB cable and put into Download Mode (often used for flashing firmware).
2. Exploitation and Installation: The attacker exploited an Odin authentication bypass vulnerability in the device's bootloader. This allowed the BOOTKITTY bootkit to be installed onto the boot partition, bypassing the device's integrity checks.
3. Reboot and Hijack: Upon system reboot, the modified boot chain executed automatically:

• The hooking code, injected via a heap overflow vulnerability in the bootloader, ran just before the Android kernel entry point.
• This code immediately disabled kernel mitigations (e.g., mark_rodata_ro, security_capable).
• Following this, the rootkit was loaded into memory from a custom RAM disk, and the system became fully compromised.

1. Compromise Confirmation: The demonstration successfully illustrated how gaining control at the bootloader stage enabled a full system compromise, with the BOOTKITTY rootkit becoming active and operational. The C2 communication for rootkit module download was also highlighted as a capability.

Both demonstrations effectively validated the theoretical concepts and technical deep dives presented, solidifying the claim that BOOTKITTY can indeed achieve multi-OS trust chain compromise from bootkit to rootkit.

Defensive Implications

▶ Watch: Q&A: How security checks are found and patched (27:00)

The BOOTKITTY research presents a stark warning for defenders, highlighting the critical vulnerabilities at the very foundation of modern computing systems. The ability of a hybrid bootkit to bypass Secure Boot and progressively compromise the boot chain demands a multi-layered and proactive defensive strategy.

1. Enhanced Boot Integrity Verification:

The primary implication is the urgent need for more robust and continuous boot integrity verification mechanisms. While Secure Boot is a crucial first line of defense, its demonstrated bypasses necessitate:

• Firmware Updates: Regular and timely application of firmware updates to patch known vulnerabilities, especially those affecting the PEI stage or bootloaders like GRUB and Little Kernel.
• Runtime Integrity Monitoring: Implementing solutions that can monitor the integrity of critical boot components (UEFI firmware, bootloaders, kernel images) not just at boot time but continuously during runtime. This includes checking for unexpected modifications to the Machine Owner Key (MOK) list or EFI System Partition (ESP).
• Hardware-Anchored Root of Trust: Leveraging hardware-based security features like Trusted Platform Modules (TPMs) or Hardware Security Modules (HSMs) for stronger attestation of the boot process. This would involve securely storing measurements of boot components and verifying them against known good values.

2. Secure Configuration Management:

Misconfigurations are a significant attack vector. Organizations must:

• Strict MOK Management: Implement stringent policies for registering MOKs in Linux environments. Unauthorized MOK registrations should trigger immediate alerts and investigation.
• Bootloader Hardening: Ensure bootloaders like GRUB are configured securely, with password protection and restricted access to their configuration files.
• Device Provisioning: For Android devices, enforce secure provisioning processes that prevent unauthorized flashing or exploitation of vulnerabilities like the Odin authentication bypass. This includes disabling debug modes or insecure boot modes when not strictly necessary.

3. Advanced Endpoint Detection and Response (EDR):

Traditional antivirus solutions are largely ineffective against bootkits that operate before the OS loads. Defenders need:

• Pre-OS Monitoring: EDR solutions that can extend their visibility to the pre-OS environment, monitoring UEFI firmware, bootloaders, and kernel loading processes for anomalies.
• Memory Forensics: Enhanced memory forensics capabilities to detect hooks injected into compressed or decompressed kernel memory, and to identify patched kernel functions (e.g., those bypassing kernel module signing or other mitigations).
• Behavioral Analysis: Look for unusual process behavior, such as attempts to modify boot partitions, unexpected LD_PRELOAD usage on init processes, or C2 communication from low-level system components.

4. Proactive Vulnerability Management:

Organizations must actively track and patch vulnerabilities in firmware, bootloaders, and kernel components. This includes:

• Vendor Communication: Maintaining strong communication channels with hardware vendors and OS developers to stay informed about newly discovered vulnerabilities and available patches.
• Internal Research: Potentially conducting internal research or engaging third-party security firms to audit critical boot components for undiscovered vulnerabilities.

5. Incident Response and Remediation:

If a bootkit infection is suspected or confirmed, remediation is challenging due to the deep level of compromise.

• Re-imaging and Firmware Flashing: Complete re-imaging of affected systems, including re-flashing UEFI firmware, is often necessary to ensure the bootkit is fully eradicated. This must be done carefully to avoid bricking devices.
• Offline Analysis: Performing offline analysis of compromised boot partitions and memory dumps to understand the bootkit's behavior and identify its persistence mechanisms.

In summary, defending against threats like BOOTKITTY requires shifting focus to the very earliest stages of system initialization. It demands a holistic approach combining robust hardware-level security, vigilant software patching, advanced monitoring, and a deep understanding of the boot process across diverse operating environments.

Key Takeaways

• Multi-OS Bootkit Capability: BOOTKITTY demonstrates a sophisticated hybrid bootkit capable of compromising Windows, Linux, and Android systems by adapting its attack vectors to each OS's unique boot chain.
• Secure Boot Bypass is Critical: The research underscores that once Secure Boot is bypassed (e.g., via MOK exploitation on Linux or Odin bypass on Android), a wide range of bootkit and rootkit attacks become feasible, dismantling the foundational trust chain.
• Multi-Stage Hooking for Deep Control: BOOTKITTY achieves persistent and deep system control by employing a multi-stage hooking technique, progressively hijacking execution from early firmware/bootloader stages into the compressed and then decompressed kernel.
• Kernel Mitigation Disablement: A core technique involves disabling critical kernel security features, such as kernel module signing and various memory protections, by patching verification functions to always return a "success" value, allowing the rootkit to operate unimpeded.
• Early Rootkit Loading for Stealth: The bootkit leverages techniques like LD_PRELOAD on Linux and custom RAM disks on Android to load its rootkit components into the kernel before the operating system fully initializes, making detection extremely challenging for traditional security solutions.
• Urgent Need for Boot Chain Hardening: The findings highlight the critical need for enhanced boot integrity verification, secure firmware updates, proactive vulnerability management, and advanced pre-OS monitoring to counter such deeply embedded and persistent threats.

About the Speaker(s)

Junho Lee is a student at Mokpo National University with a keen interest in low-level security. His research contributions, as demonstrated by the BOOTKITTY project, focus on understanding and exploiting vulnerabilities at the fundamental layers of system operation.

HyunA Seo is a student at Sungshin Women's University, specializing in system security. Her work on BOOTKITTY showcases her expertise in analyzing complex system architectures and identifying critical security weaknesses within them. Together, their collaboration has produced significant insights into advanced bootkit and rootkit threats.