UEFI Bootkit: from the laboratory to reality, with a focus on Bootkitty and BlackLotus

Los UEFI bootkits In just a few years, they have gone from being a laboratory concept to becoming a real headache for defenders and manufacturers. In this area, the line between proof of concept and operational threat is blurred, and cases like black lotus or the recent discovery of Bootkitty on Linux They prove it amply.

This article brings together and explains, with clear language and technical details when they add value, the most relevant published by researchers and companies in the sector: from the first PoC in 2012 to modern campaigns, including vulnerabilities such as CVE-2024-7344 that allow you to bypass Secure Boot, evasion techniques, IoCs, and detection and mitigation measures that actually work in the real world.

What is a UEFI bootkit and why is it so problematic?

A UEFI bootkit is an implant that runs before the operating system, with the ability to control the flow of Boot, disable checks, and load components with high privileges. By operating at such a low level, you can evade traditional antivirus and even certain "safe start measures" if it exploits flaws or permissive configurations.

In the real world, persistent UEFI implants and techniques have already been observed, such as LoJax, MosaicRegressor o MoonBounce, milestones that show how an actor can occupy the firmware and master critical phases of the boot, complicating the forensic analysis and remediation.

To defend Windows, Microsoft chains several layers: Secure Boot (UEFI validates the loader with trusted certificates), Trusted Boot (the kernel validates the rest of the components), ELAM (Early Launch Antimalware, which inspects boot drivers) and Measured Boot (TPM measurements and remote attestation). These are useful, but not infallible, barriers to vulnerabilities of the ecosystem itself UEFI or overly broad trust settings. In addition, it is possible shield Windows with Credential Guard, BitLocker, and WDAC to reduce long-term persistence risk.

From PoCs to Real Life: Timeline and Key Players

The journey begins in 2012 with the PoC of Andrea Allievi for Windows on UEFI, followed by projects such as EfiGuard, Boot Backdoor or UEFI-bootkit. It took years until in-the-wild cases were documented such as ESPecter (ESET, 2021) or the FinSpy bootkit (Kaspersky, 2021), and in 2023 it burst onto the scene black lotus, the first UEFI bootkit capable of Bypass Secure Boot on fully updated systems. In laboratory environments it is common testing malware on a virtual machine to evaluate PoCs and detections without putting productive infrastructure at risk.

One thing had been constant until now: the target was exclusively Windows computersThat assumption was shattered when a UEFI app called VirusTotal appeared on VirusTotal in November 2024. bootkit.efiThe analysis revealed a bootkit, dubbed by its authors as Bootkitty, designed to Linux (Ubuntu)According to telemetry, there is no confirmed actual deployment; and the authors themselves, linked to the Korean training program Best of the Best (BoB), they clarified that it was a proof of concept with the aim of raising awareness.

The Bootkitty binary is signed with a self-signed certificate. This means that it will not run with Secure Boot enabled unless install the attacker's certificates. Nevertheless, its logic illustrates how an actor can patch, in memory, components of the loader (GRUB) and the linux kernel to bypass checks.

Bootkitty in detail: artifacts, compatibility, and what it modifies

The bootkit contains unused functions that print ASCII art with the name Bootkitty and a list of possible authors. It also shows text strings at each startup and references to BlackCat within its output and in a related kernel module, unrelated to the ALPHV/BlackCat ransomware; partly because Bootkitty is written in C, while ALPHV develops in Rust.

Its compatibility is limited. To locate which functions to touch, use encoded byte patterns (a classic bootkit technique), but the chosen patterns don't cover multiple kernel or GRUB versions well. The result is that the implant is only functional in a very limited set of configurations, and furthermore, patches fixed offsets after kernel decompression: if offsets do not match the version, it may overwrite random data and cause hang up instead of commitment.

The boot begins with shim running Bootkitty, which first queries the status of SecureBoot and places hooks into two UEFI authentication protocols: EFI_SECURITY2_ARCH_PROTOCOL.FileAuthentication y EFI_SECURITY_ARCH_PROTOCOL.FileAuthenticationState. In both cases, set the output to return EFI_SUCCESS, effectively negating the PE image integrity check during pre-OS.

Bootkitty then loads a legitimate GRUB from a hardcoded path on the ESP (/EFI/ubuntu/grubx64-real.efi), patches it in memory and hooks key functions before it is executed.

Hooking into GRUB and unzipping the Linux kernel

The implant alters the function start_image of the module peimage of GRUB, responsible for launching already loaded PE binaries (such as the EFI kernel stub, vmlinuz.efi/vmlinuz). Take advantage of the fact that the kernel is already in memory and place a hook in the routine that decompresses the actual kernel image (probably zstd_decompress_dctx depending on the build), so once unzipped, you can hot patch it.

It also modifies the function grub_verifiers_open, which decides whether to verify the integrity of each loaded file (modules, kernel, config, etc.). The hook returns immediately, and thus, avoids any signature verification. For its part, the adjustment in shim_lock_verifier_init It is confusing: it forces a stricter verification flag (GRUB_VERIFY_FLAGS_SINGLE_CHUNK), but this function is not even called by the other hook, leaving Irrelevant.

Once the kernel is decompressed, the Bootkitty code applies three memory modifications: it rewrites the version/banner string from the kernel with the text "BoB13"; force that module_sig_check() return 0 for the kernel to load unsigned modules; and replaces the first environment variable of the process init to inject LD_PRELOAD=/opt/injector.so /init at the beginning of user space.

Injection by LD_PRELOAD This is a classic tactic to prioritize an ELF shared object and override functions. Here the chain has a peculiarity (it includes "/init" next to LD_PRELOAD), a detail that reinforces the character of Unfinished PoC rather than a polished operation. The supposedly injected binaries were not observed, although a subsequent third-party writing indicated that they are used only for load an additional stage.

Indicators, symptoms and a simple remedy

If Bootkitty is present, it is possible to see visible hints. The command uname -v will display the kernel version with the text altered and in dmesg The banner may also appear modified. In addition, it is possible to detect that the process PID 1 (init) was released with LD_PRELOAD inspecting /proc/1/environ, an anomalous signal in legitimate systems.

In laboratory tests, the kernel appears stained after booting with Bootkitty, and another empirical check on computers with Secure Boot enabled is to try to load a unsigned module: If hot loading is allowed, it suggests that module_sig_check has been patched.

If the bootkit had been installed by replacing the GRUB binary with an intermediary (observed behavior), a straightforward way to recover is to move the Legitimate GRUB from /EFI/ubuntu/grubx64-real.efi to its original route /EFI/ubuntu/grubx64.efi for shim run it and the boot chain continues without the implant.

BCDropper and BCObserver: Connected Pieces or Just a Coincidence?

An unsigned kernel module nicknamed Bootkitty was found alongside Bootkitty BCDropper, which shares clues with the bootkit: strings BlackCat/blackcat in metadata and debug paths, and a function of file hiding whose prefixes include "injector" (in line with the variable LD_PRELOAD pointing to /opt/injector.so).

BCDropper leaves in /opt/observer an embedded ELF (called BCObserver) and launches it through / bin / bashThis fairly simple component waits for gdm3 is active and then loads a kernel module from /opt/rootkit_loader.ko using finit_module, making sure to do so after the system has fully booted.

Although there are signs of a relationship, it is not possible to guarantee that both elements come from the same author or that they are designed to work together. To make matters worse, the kernel version mentioned in its metadata (6.8.0-48-generic) is not even listed among those supported by the bootkit.

Associated IoCs

The following artifacts have been associated with the findings discussed. Their value is mainly referencia and laboratory:

BlackLotus and CVE-2022-21894: The milestone that opened the floodgates

BlackLotus has been on the market since 2022 with a price of around 5.000 USD (plus extras per upgrade) and includes techniques for anti-VM/anti-debug evasion, geofencing to avoid certain countries (Armenia, Belarus, Kazakhstan, Moldova, Romania, Russia and Ukraine) and, most importantly, the exploitation of CVE-2022-21894 (Baton Drop) for bypass Secure Boot and achieve robust persistence on fully patched Windows 10/11 machines.

The flow described by the security community includes a first phase with deactivation of protections of the operating system, the exploitation of the legacy vulnerability in Secure Boot and the registering a machine owner key controlled by the attacker. After further reboots, the implant deploys a kernel driver and a user-mode component type downloader to manage command and control communication and additional charges.

For proactive defense, the community has published operational rules. For example, SOC Prime offers Sigma detections that look for the suspicious creation of firmware files in System32 by non-system processes or the HVCI deactivation via logging. These types of signals, mapped to MITRE ATT&CK (e.g., T0857, T1562, T1112), help to hunt for anomalous activity which usually accompanies bootkits; there are also practical guides for Detect malicious processes with Process Explorer in Windows environments.

CVE-2024-7344: Loading untrusted UEFI binaries via "reloader.efi"

A particularly sensitive vulnerability was discovered in 2024, CVE-2024-7344, which affects multiple recovery suites signed by the certificate Microsoft Corporation UEFI CA 2011The root of the problem is the use of a custom PE loader in the UEFI application reloader.efi, instead of secure APIs LoadImage/StartImage. The binary decrypts and executes content from a file cloak.dat without verifying signatures according to the policy of Secure Boot.

The vector is not limited to computers with the software installed, as an attacker with elevated privileges could deploy the vulnerable binary in the ESP (EFI partition) of any system that trusts Microsoft's third-party UEFI CA and cause the execution of a UEFI not signed during startup. Affected products included suites from Howyar, Greenware, Radix, SANFONG, Wasay, CES, and Signal Computer, as corrected and revoked the 14 of January of 2025.

To verify protection en PowerShell with elevated privileges and in Linux (LVFS/dbxtool):

# ¿El sistema confía en la UEFI CA 2011 de Microsoft? (posible exposición)
::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Microsoft Corporation UEFI CA 2011'

# Revocación instalada (64 bits)
::ToString((Get-SecureBootUEFI dbx).bytes) -replace '-' -match 'cdb7c90d3ab8833d5324f5d8516d41fa990b9ca721fe643fffaef9057d9f9e48'

# Revocación instalada (32 bits)
::ToString((Get-SecureBootUEFI dbx).bytes) -replace '-' -match 'e9e4b5a51f6a5575b9f5bfab1852b0cb2795c66ff4b28135097cba671a5491b9'

# Linux (dbxtool)
dbxtool --list | grep 'cdb7c90d3ab8833d5324f5d8516d41fa990b9ca721fe643fffaef9057d9f9e48'
dbxtool --list | grep 'e9e4b5a51f6a5575b9f5bfab1852b0cb2795c66ff4b28135097cba671a5491b9'

This case reopens the debate on the chain of trust: Microsoft maintains two certificates widely present on consumer and enterprise UEFI computers (Windows Production CA 2011 y UEFI CA 2011 for third parties). The plan in place is to migrate to certificates 2023, following incidents such as BlackLotus and the proliferation of vulnerable bootloaders signed years ago. On computers Secured-core, third-party UEFI CA usually comes disabled by default.

Practical protections and customization of Secure Boot

Beyond applying UEFI revocations and keep firmware/OS up to date (Windows Update and LVFS), there are measures that reduce the attack surface: controlling the access to ESP with security rules, customize Secure Boot to limit trust to what is necessary (following guidelines such as that of the NSA) and deploy attestation with TPM to remotely validate the boot status against reference values.

In Windows, the combination of Secure Boot + Trusted Boot + ELAM + Measured Boot It offers layered barriers: loader validation, boot controllers inspected before the rest, and a record signed by the TPM which allows the firewall to separate "clean" computers from those with deviations. In managed environments, this reduces There de detection and containment.

On Linux, in addition to revocations and ESP control, it is worth watching for signals such as LD_PRELOAD in the process init, the state stained of the kernel, and correlate module loading events (e.g., finit_module) with unusual routes (/opt/*.ko) to detect attempts to persistence early.

Tools, Coverage, and MITRE ATT&CK

According to ESET, it is the only vendor in the top 20 endpoints by revenue that integrates a UEFI firmware scanner in their equipment protection solutions. Although other manufacturers offer UEFI-related technologies, their purpose does not always coincide with the direct firmware inspection. Since UEFI attacks, although sporadic, grant total control and persistence almost absolute, investing in this layer can make all the difference.

In terms of MITRE ATT&CK, the observed behaviors fit with several techniques: Pre-OS Boot: Bootkit (T1542.003), Shared Modules/LD_PRELOAD (T1129), development of Malware (T1587.001) and use of certificates (T1587.002), plus Rootkit (T1014), Impair Defenses (T1562) y Hide Artifacts (T1564) in the case of kernel modules that they hide to themselves.

• T1542.003: Bootkit on the ESP for pre-OS persistence.
• T1129: Preload with LD_PRELOAD in the init process.
• T1014: Kernel modules with rootkit functionality.
• T1562 / T1564: Disable checks and hide from the system.

Linux is not invulnerable: the Bootkitty case and new names on the radar

For years, the popular narrative contrasted the increased exposure of Windows against the supposed "impenetrability" of macOS or Linux. The reality is more nuanced: their model and share make them different targets, but not immune. The emergence of Bootkitty in Linux shows that the knowledge to create bootkits also exists for this ecosystem, although in this specific case we are talking about a Academic PoC with limited support.

There have even been mentions of a ransomware variant, HybridPetya, which would integrate UEFI bootkit capabilities. The samples uploaded to VirusTotal in 2025 from Poland suggest recent development, although they should be treated with caution. caution until there is independent analysis and solid attribution.

The important thing is to internalize that the defense must cover the complete boot chain, minimize default trust in third-party signatures that are not used, monitor the EFI partition and consolidate useful telemetry (tainted kernel, module events, changes in GRUB checkers or sensitive UEFI variables) to detect in time.

The current picture of UEFI risk combines PoCs for educational purposes, bootkits marketed as a service and vulnerabilities in signed components that, if not revoked in time, open the door to untrusted pre-OS executionMaintaining up-to-date firmware and revocation lists, reducing the circle of trust, and monitoring ESP are measures that, together, put defenders in a much stronger position against this family of threats.

Related article:

How to secure Windows with Credential Guard, BitLocker, AppLocker, Device Guard, and WDAC

Isaac

Passionate writer about the world of bytes and technology in general. I love sharing my knowledge through writing, and that's what I'll do on this blog, show you all the most interesting things about gadgets, software, hardware, tech trends, and more. My goal is to help you navigate the digital world in a simple and entertaining way.