UEFI Bootkit: Bootkitty on Linux and the legacy of BlackLotus

Informatec Digital » Linux » UEFI Bootkit: Bootkitty on Linux and the legacy of BlackLotus

The UEFI bootkits have become one of the most disturbing vectors in the modern threat landscape: they run before the operating system, can disable defenses, and achieve persistence with elevated privileges. In recent years, we have gone from mere Proof of concept to real active cases like BlackLotus on Windows, and now the first Linux-oriented design appears, called Bootkitty, which opens a new stage for the ecosystem of FOSS.

This article compiles and organizes key information from multiple recognized sources to explain how the UEFI bootkits, what distinguishes Bootkitty on Linux, why BlackLotus marked a before and after in Windows, what indicators of compromise to watch out for and what defensive measures apply. In addition, relevant cases such as LoJax, ESPecter, MoonBounce, and MosaicRegressor are discussed, as well as related MITRE ATT&CK detection rules and tactics.

What is a UEFI bootkit and why it poses a serious risk?

A UEFI bootkit is malicious code that runs in the early stages of boot, when the firmware initializes the computer and before the operating system take control. By operating at such a low level, they can inhibit mechanisms such as signature verification or loading legitimate drivers, deploying payloads in kernel or user mode and remaining hidden from many traditional countermeasures.

It is important to distinguish between different levels of boot malware: firmware implants (e.g. LoJax in 2018) directly modify the SPI flash, while bootkits typically reside on the more accessible EFI system partition (ESP), but with capabilities similar to take early control of the startup process.

The recent evolution of vulnerabilities in UEFI and the lack of timely revocations Defective binaries in the revocation database (dbx) have made it easier for offensive actors to abuse signed but vulnerable components to bypass Secure Boot, as was the case with the CVE-2022-21894 (Baton Drop) exploitation in the BlackLotus case.

Historical context: from PoCs on Windows to cases in the wild

The first major public demonstration of a UEFI bootkit Modern development dates back to 2012, when Andrea Allievi documented a PoC capable of running in Windows environments with UEFI. This was followed by other tests—EfiGuard, Boot Backdoor, UEFI-bootkit—that demonstrated the technical feasibility of the approach.

After that first stage of experimentation, it took years for the active threats on real systems. In 2021, ESPecter (investigated by ESET) and the FinSpy bootkit (analyzed by Kaspersky) were released, and in 2023, BlackLotus, the first known bootkit to bypass UEFI Secure Boot, was released. fully updated equipment with Windows 11.

Until very recently, all these cases had one thing in common: they were exclusively oriented towards WindowsThis paradigm is broken with the discovery of Bootkitty, focused on Ubuntu and, therefore, on the world Linux.

Bootkitty: first UEFI bootkit focused on Linux

In November 2024, an unknown UEFI application (bootkit.efi) which, after analysis, turned out to be Bootkitty, the first UEFI bootkit designed for Linux, specifically for certain versions of Ubuntu. According to available telemetry, there is no evidence of deployment in the wild; everything points to a proof of concept early, with multiple developmental artifacts.

Important update: In early December 2024, confirmation emerged that this was an academic project developed by participants in the Korean Best of the Best (BoB) program. Its stated objective was Raise awareness about risks and encourage proactive measures. This piece fits with what analysts observed: a functional bootkit but with limited support and signs of PoC, not a finished weapon for mass campaigns.

PoC compatibility, signature, and signals

Bootkitty comes signed with a self-signed certificate, so it fails to run if Secure Boot is enabled unless the attacker's certificates are manually added. However, its logic attempts to continue the kernel boot with normal patching in-memory verification functions before GRUB relinquishes control.

Its compatibility is limited. To locate functions to modify, use byte patterns coded that do not span multiple kernel or GRUB versions, making it operational only in specific configurations and susceptible to crashes if the offset does not correspond to the self present.

Among the PoC artifacts, two routines stand out that print on screen an ASCII art with the name Bootkitty and a list of possible authors; additionally, at startup it displays specific strings and references like "BlackCat" unrelated to the ALPHV/BlackCat ransomware group. The binary also overwrites the version string and banner of Linux with the text “BoB13”.

Execution chain and hooks in UEFI and GRUB

On startup, Bootkitty checks the status of SecureBoot reading the UEFI variable of the same name. It then installs hooks in the UEFI authentication protocols — EFI_SECURITY2_ARCH_PROTOCOL.FileAuthentication and EFI_SECURITY_ARCH_PROTOCOL.FileAuthenticationState — to force EFI_SUCCESS as a result, negating the actual evaluation of UEFI PE image integrity.

Then, load from the ESP a legitimate GRUB located at the hardcoded path /EFI/ubuntu/grubx64-real.efi (presumably a copy that the attacker deposited). With GRUB in memory, not yet running, the bootkit patches and hooks several critical points, including:

• peimage::start_image (embedded in GRUB), to intercept the moment when the kernel EFI stub (vmlinuz.efi) is loaded into memory. From here, Bootkitty locates and patches the routine responsible for kernel decompression, most likely zstd_decompress_dctx depending on the build.
• shim_lock_verifier_init, part of shim_lock in GRUB, although the hook applied is irrelevant because another hook prevents it from being executed, and the modification also introduces the flag GRUB_VERIFY_FLAGS_SINGLE_CHUNK, which in theory hardens verification.
• grub_verifiers_open, which is altered to return immediately without invoking signature checks, thus neutralizing the normal flow of check in GRUB.

Kernel decompression hook and memory patches

The kernel decompression hook temporarily restores the original bytes, allows the authentic function to decompress the image, and then applies patches to the the memory of the already expanded kernel. This phase is critical for disabling controls and preparing for the loading of additional modules or binaries.

Specifically, the observed logic rewrites the version string with “BoB13”, modifies the function module_sig_check to return 0 (so the kernel accepts unsigned modules even with Secure Boot enabled, with CONFIG_MODULE_SIG_FORCE or with module.sig_enforce=1), and replaces the first environment variable of the init process by “LD_PRELOAD=/opt/injector.so /init”.

The idea behind LD_PRELOAD is to force priority loading of a ELF shared to overwrite functions or insert extra logic, a common technique in userland attacks. The presence of “/init” within the LD_PRELOAD value is striking; the exact meaning is not entirely clear and reinforces the interpretation that we are dealing with a early development.

During lab testing, the system displayed the kernel as stained after booting with Bootkitty; in addition, in dmesg you can see the modified strings and the trace of the variable LD_PRELOAD, which can also be seen in /proc/1/environ. On computers with Secure Boot enabled, an empirical indication is that the kernel agrees to load a module unsigned at runtime, which should not happen without prior patching.

BCDropper and BCObserver: associated auxiliary parts

In parallel, an unsigned kernel module dubbed BCDropper, uploaded to VirusTotal by the same sender as the bootkit. It contains references to “BlackCat” in debugging strings and paths, and a file-hiding feature (filters out names with prefixes like “injector”, in line with the LD_PRELOAD pointing to /opt/injector.so).

BCDropper extracts an embedded ELF called BCObserver in /opt/observer and runs it via /bin/bash. It also removes its own trace from the list of loaded modules and provides functions for rootkit typical ones (hiding files, processes, ports), although the dropper does not exploit all of them directly.

BCObserver, on the other hand, waits for the display manager to start. gdm3 and then tries to load /opt/rootkit_loader.ko using the syscall finit_module, ensuring that the module is injected when the system has already completed graphical boot.

There is no absolute certainty that these pieces are linked to the same author as Bootkitty, but the patching of module_sig_check suggests that the purpose was to allow loading of unsigned modules, fitting with what BCDropper/BCObserver does.

Relevant MITRE ATT&CK IoCs and Techniques

The following indicators of engagement and classifications can help in searching for initial signals in Linux environments where the PoC might have been tested:

SHA-1	Full Name	Detection	Description
35ADF3AED60440DA7B80F3C452047079E54364C1	bootkit.efi	EFI/Agent.A	Bootkitty UEFI bootkit.
BDDF2A7B3152942D3A829E63C03C7427F038B86D	dropper.ko	Linux/Rootkit.Agent.FM	BCDropper.
E8AF4ED17F293665136E17612D856FA62F96702D	observer	Linux/Rootkit.Agent.FM	BCObserver.

Most prominent MITRE ATT&CK mapping for this set of pieces and observed behavior, useful for a Threat Model essential:

Tactic	ID	Full Name	Description
Resource Development	T1587.001	Develop Capabilities: Malware	Bootkitty is a UEFI bootkit new.
	T1587.002	Develop Capabilities: Code Signing Certificates	Sample signed with certificates self-signed.
Execution	T1106	Native API	BCObserver uses finit_module to load an LKM.
	T1129	Shared Modules	Bootkitty strength LD_PRELOAD in init.
P	T1574.006	Hijack Execution Flow: Dynamic Linker Hijacking	Environment Patching init with LD_PRELOAD.
	T1542.003	Pre-OS Boot: Bootkit	Deployment in the ESP.
Defense Evasion	T1014	Rootkit	BCDropper as LMC for concealment.
	T1562	Impair Defenses	Disable verification of firms in GRUB and kernel.
	T1564	Hide Artifacts	Hide your module from the list modules of the kernel.

Traces on Linux systems and mitigation suggestions

Forensic clues such as the altered kernel version string have been observed in affected Ubuntu installations. BoB13 (visible with uname -v), modifications to the boot banner (dmesg) and presence of LD_PRELOAD in /proc/1/environThe kernel may be marked as tainted, a behavior that does not occur without the bootkit.

A quick fix when the bootkit replaces GRUB is to return the legitimate GRUB file. /EFI/ubuntu/grubx64-real.efi to its original location in /EFI/ubuntu/grubx64.efi so that shim boots the authentic GRUB. Remember that this only covers the stage specific one in which the deployment has been exactly like this.

BlackLotus: the paradigmatic case in Windows

BlackLotus became known for being able to execute its UEFI bootkit even on fully patched Windows 11 with Secure Boot enabled. It was on sale for $5.000 ($200 per upgrade) since October 2022, with geofencing to avoid systems from Armenia, Belarus, Kazakhstan, Moldova, Romania, Russia and Ukraine.

Exploited the vulnerability CVE-2022-21894 (Baton Drop), patched by Microsoft in January 2022, but still exploitable some time later because vulnerable and signed binaries were still not added to the list of UEFI revocations (dbx). The installer inserts copies of validly signed vulnerable bootloaders to achieve persistence and bypass Secure Boot.

Among his abilities, he was able to deactivate BitLocker, Memory Integrity (HVCI) and Microsoft Defender, deploy a driver in the kernel that protects the bootkit files on the ESP, and a user-mode HTTP downloader that runs within winlogon.exe, with anti-VM, anti-debugging, and obfuscation techniques. The bootkit size was small (around 80 KB), which favors its secrecy.

Internal chains and curious artifacts have been documented, such as references to the series Higurashi in component names and the self-signed certificate, as well as unused obfuscated messages. These details do not diminish its danger, but they do provide context about its development.

How Windows Protects Boot: Secure Boot, Trusted Boot, ELAM, and Measured Boot

In Windows, the boot chain of trust relies on several layers. Secure Boot validates firmware and bootloader signatures; Trusted Boot verifies the integrity of the kernel and boot components; ELAM prioritizes loading an antimalware driver before other non-Microsoft boot drivers; and Measured Boot records hashes in the TPM for remote attestation.

By default, certified computers include Secure Boot enabled and trust the certificate. Microsoft and other approved loaders. However, keeping the Microsoft third-party UEFI CA enabled expands the attack surface to trust in bootloaders of multiple distributions, including those with known vulnerabilities. Many hardened kernel devices require disabling trust in that third-party CA to harden the stance default.

To allow Linux in protected environments, the recommended approach is Add explicitly signing the desired bootloader to the UEFI database or, as a last resort, disabling Secure Boot — a measure that significantly reduces protection against bootkitIn any case, these changes require manual intervention in the firmware and cannot be automated by malware.

The attestation with Measured Boot allows a trusted server to assess whether an endpoint maintains its boot chain intact. The TPM signs the evidence and, combined with additional telemetry, makes it possible to isolate compromised devices on networks quarantine until its remediation.

Proactive detection and surveillance rules

Beyond the native Windows instrumentation, the community has published Sigma rules useful for detecting activity associated with these scenarios. These include creating a firmware file under System32 by a non-system process, or disabling Memory Integrity (HVCI) detections using registry keys (MITRE ATT&CK techniques T1562 and T1112). These detections are mapped to multiple SIEMs/EDRs/XDRs.

For Linux, it is convenient to correlate events boot (journald/dmesg), changes to uname -v and PID 1 environment variables, as well as checking for unsigned module loads or operations suspicious about ESP. Integrating these traces with behavioral rules in the EDR improves the probability of uncovering an attempted persistence early.

Bigger picture: LoJax, ESPecter, MoonBounce, MosaicRegressor, and new signals

The first UEFI firmware implant observed in the wild was LoJax (2018), followed by campaigns with MosaicRegressor and MoonBounce, the latter notable for raising the bar of sophistication in rootkits UEFI. In 2021, ESPecter and the FinSpy bootkit demonstrated that the pre-OS stage was still an attractive target for actores advanced.

In the Linux field, Bootkitty has been the first experiment functional of its kind, with limited scope. And as early as 2025, references have appeared to “HybridPetya” as an evolution of the Petya family with UEFI bootkit capabilities, with samples uploaded to VirusTotal from Poland. Although the analysis is still preliminary, it is a reminder that this category of threats continues to exist. expansion.

Practical recommendations to reduce risk

In Linux environments, maintain Secure Boot active, applying firmware (UEFI) and kernel updates, and ensuring that the revocation list (dbx) is up to date are non-negotiable pillars. Monitor that module.sig_enforce is set to 1 or that CONFIG_MODULE_SIG_FORCE is enabled where appropriate and avoid loading modules from untrusted sources.

Audit the partition regularly ESP It scans for unauthorized changes to paths like /EFI/ubuntu/grubx64.efi and verifies that there are no suspicious copies (grubx64-real.efi). Any alteration to the verification flow GRUB must be investigated.

In Windows, in addition to Secure Boot, it enforces Trusted Boot, enables HVCI when supported by the hardware, and adopts TPM-based remote attestation with policies conditional access. Minimizes reliance on third-party CAs if not strictly necessary and accelerates adoption revocations when they publish failures in boot components.

Some commercial solutions integrate UEFI scanners capable of checking the firmware for errors. malicious componentsESET claims to be the only vendor in the top 20 endpoint revenue to offer this integrated capability to its customers, an approach that can add value in defense in-depth hardware.

The trajectory of recent campaigns makes it clear that the starting link remains a priority objective. telemetry With proper firmware/bootloader hardening and systematic integrity checks, it is possible to raise the bar significantly and make life more difficult for developers. opponents.

The state of the art of the UEFI bootkits confirms that the line between PoC and real operation is being crossed ever faster: Bootkitty shows that Linux is already in the spotlight, BlackLotus consolidated viability on Windows, and the defense ecosystem must prioritize boot hygiene, dbx updating, and monitoring IoCs and remote attestation to nip any pre-OS persistence attempts in the bud.