- Bootkitty is the first UEFI bootkit PoC for Linux with limited support and hooks into UEFI/GRUB.
- BlackLotus exploited CVE-2022-21894 to bypass Secure Boot and disable defenses on Windows.
- IoCs, MITRE ATT&CK, and Sigma detections help monitor for boot and kernel tampering.
UEFI bootkits have become one of the most worrying 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've gone from mere proofs of concept to active real-world cases like BlackLotus on Windows, and now the first Linux-oriented design, dubbed Bootkitty, has emerged, ushering in a new era for the free software ecosystem.
This article compiles and organizes key information from multiple reputable sources to explain how UEFI bootkits operate , what distinguishes Bootkitty on Linux, why BlackLotus was a game-changer for Windows, what indicators of compromise to watch for, and what defensive measures to implement. It also discusses relevant cases such as LoJax, ESPecter, MoonBounce, and MosaicRegressor, as well as related detection rules and MITRE ATT&CK tactics.
What is a UEFI bootkit and why it poses a serious risk?
A UEFI bootkit is malicious code that executes during the early stages of booting, when the firmware initializes the device and before the operating system takes control. By operating at such a low level, it can disable mechanisms such as signature verification or the loading of legitimate drivers, deploy payloads in kernel or user mode, and remain hidden from most traditional countermeasures.
It is important to distinguish between different levels of malicious boot software: firmware implants (e.g., LoJax in 2018) directly modify the SPI flash, while bootkits usually reside in the EFI system partition (ESP), which is more accessible but has similar capabilities to take early control of the boot process.
The recent evolution of vulnerabilities in UEFI and the lack of timely revocations of 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 happened with the exploitation of CVE-2022-21894 (Baton Drop) in the case of BlackLotus.
Historical context: from PoCs on Windows to cases in the wild
The first major public demonstration of a modern UEFI bootkit dates back to 2012, when Andrea Allievi documented a proof of concept (PoC) capable of operating 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 initial experimental phase, it took years for active threats to appear on real systems. In 2021, ESPecter (investigated by ESET) and the FinSpy bootkit (analyzed by Kaspersky) were released, and in 2023, BlackLotus emerged, the first known bootkit to bypass UEFI Secure Boot on fully updated Windows 11 systems.
Until very recently, all these cases shared a common trait: they were exclusively focused on Windows . This paradigm was broken with the discovery of Bootkitty, which is centered on Ubuntu and, therefore, on the Linux world.
Bootkitty: first UEFI bootkit focused on Linux
In November 2024, an unknown UEFI application ( bootkit.efi ) appeared on VirusTotal. Analysis revealed it 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 wild-world deployment; everything points to an early proof of concept , with multiple development artifacts.
Important update: In early December 2024, it was confirmed that this was an academic project developed by participants in the Korean Best of the Best (BoB) program. Its stated objective was to raise awareness of the risks and encourage proactive measures. This aligns with analysts' observations: a functional bootkit with limited support and signs of a proof of concept, not a finished weapon for mass campaigns.
PoC compatibility, signature, and signals
Bootkitty comes with a self-signed certificate , so it cannot run if Secure Boot is enabled unless the attacker's certificates are manually added. Even so, its logic attempts to allow the kernel boot process to continue normally by patching verification functions in memory before GRUB relinquishes control.
Its compatibility is limited. To locate functions to modify, it uses encoded byte patterns that do not cover multiple kernel or GRUB versions, making it operational only in specific configurations and likely to cause crashes if the offset does not correspond to the current version.
Among the proof-of-concept artifacts are two routines that print ASCII art with the name Bootkitty and a list of possible authors; in addition, at startup it displays specific strings and references such as "BlackCat," unrelated to the ALPHV/BlackCat ransomware group. The binary also overwrites the Linux version string and banner with the text "BoB13."
Execution chain and hooks in UEFI and GRUB
Upon startup, Bootkitty checks the SecureBoot status by reading the corresponding UEFI variable. It then installs hooks on the UEFI authentication protocols—EFI_SECURITY2_ARCH_PROTOCOL.FileAuthentication and EFI_SECURITY_ARCH_PROTOCOL.FileAuthenticationState—to force EFI_SUCCESS as the result, overriding the actual evaluation of UEFI PE image integrity.
Next, it loads a legitimate GRUB from the ESP, located in the hardcoded path /EFI/ubuntu/grubx64-real.efi (presumably a copy deposited by the attacker). With GRUB in memory, but not yet executed, 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 hook over kernel decompression temporarily restores the original bytes, allows the authentic function to decompress the image, and then applies patches to the memory of the now-expanded kernel. This phase is critical for disabling controls and preparing to load additional modules or binaries.
Specifically, the observed logic rewrites the version string with “BoB13” , modifies the module_sig_check function to return 0 (thus 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 with “LD_PRELOAD=/opt/injector.so /init”.
The idea behind LD_PRELOAD is to force the priority loading of a shared ELF file to overwrite functions or insert extra logic, a common technique in userland attacks. The presence of “/init” within the LD_PRELOAD value is noteworthy; its exact meaning is not entirely clear and reinforces the interpretation that this is an early development stage.
During lab tests, the system showed the kernel as tainted after booting with Bootkitty; furthermore, the modified strings and traces of the LD_PRELOAD variable were visible in dmesg, which could also be seen in /proc/1/environ . On systems with Secure Boot enabled, an empirical indication is that the kernel accepts loading an unsigned module at runtime, which should not happen without prior patching.
BCDropper and BCObserver: associated auxiliary parts
In parallel, an unsigned kernel module nicknamed BCDropper was discovered , uploaded to VirusTotal by the same sender as the bootkit. It contains references to “BlackCat” in debug strings and paths and file hiding functionality (filtering names with prefixes like “ injector ”, in line with LD_PRELOAD pointing to /opt/injector.so).
BCDropper extracts an embedded ELF file called BCObserver from /opt/observer and executes it using /bin/bash. It also removes its own traces from the list of loaded modules and provides typical rootkit functions (hiding files, processes, ports), although the dropper doesn't directly exploit all of them.
BCObserver, for its part, waits for the gdm3 display manager to start and then attempts to load /opt/rootkit_loader.ko using the finit_module syscall , ensuring that the module is injected when the system has already completed the 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 the 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 the search for initial signals in Linux environments where the PoC may have been tested:
| SHA-1 | 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. |
The most prominent MITRE ATT&CK mapping for this set of parts and observed behavior, useful for a basic Threat Model :
| Tactic | ID | 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
In affected Ubuntu installations, forensic evidence has been observed, such as the kernel version string being altered to BoB13 (visible with `uname -v`), modifications to the boot banner (`dmesg`), and the presence of `LD_PRELOAD` in `/proc/1/environ` . The 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 restore the legitimate file from /EFI/ubuntu/grubx64-real.efi to its original location at /EFI/ubuntu/grubx64.efi so that the bootkit boots the real GRUB. Keep in mind that this only applies to the specific scenario where the deployment was exactly as described.
BlackLotus: the paradigmatic case in Windows
BlackLotus became known for its ability to run its UEFI bootkit even on fully patched Windows 11 with Secure Boot enabled. It was available for $5.000 ($200 per upgrade) starting in October 2022, with geofencing to prevent access to systems in Armenia, Belarus, Kazakhstan, Moldova, Romania, Russia, and Ukraine.
It exploited the CVE-2022-21894 (Baton Drop) vulnerability , patched by Microsoft in January 2022, but still exploitable afterward because vulnerable, signed binaries were still not added to the UEFI revocation list (dbx). The installer introduces validly signed copies of vulnerable bootloaders to achieve persistence and bypass Secure Boot.
Among its capabilities, it could disable BitLocker, memory integrity (HVCI), and Microsoft Defender; deploy a kernel driver that protected the bootkit files on the ESP; and run a user-mode HTTP downloader within winlogon.exe , employing anti-VM, anti-debugging, and obfuscation techniques. The bootkit's size was small (around 80 KB), which contributed to its stealth.
Internal codes and curious artifacts have been documented, such as references to the Higurashi series 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 over other non-Microsoft boot drivers; and Measured Boot records hashes in the TPM for remote attestation.
By default, certified devices have Secure Boot enabled and trust the Microsoft certificate and other approved bootloaders. However, keeping Microsoft's third-party UEFI CA enabled expands the attack surface by trusting bootloaders from multiple distributions, including those with known vulnerabilities. Many protected-kernel devices require disabling trust in this third-party CA to harden the default security posture .
To allow Linux in protected environments, the recommended approach is to explicitly add the desired bootloader's signature to the UEFI database or, as a last resort, disable Secure Boot—a measure that significantly reduces protection against bootkits . In either case, these changes require manual firmware modification and cannot be automated by malicious software.
Measured Boot verification allows a trusted server to assess whether an endpoint maintains an intact boot chain. TPM signs the evidence and, combined with additional telemetry, enables the isolation of compromised devices in quarantine networks until remediation.
Proactive detection and surveillance rules
Beyond Windows' native instrumentation, the community has published useful Sigma rules for detecting activity associated with these scenarios. These include creating a firmware file under System32 by a non-system process, and disabling High-VCI Memory Integrity using registry keys (MITRE ATT&CK techniques T1562 and T1112). These detections are mapped to multiple SIEM/EDR/XDR systems.
For Linux, it's advisable to correlate boot events (journald/dmesg), changes to PID 1 environment variables using uname -vy, and to check for unsigned module loads or suspicious ESP operations . Integrating these traces with behavior rules in the EDR improves the likelihood of detecting an early persistence attempt.
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 for sophistication in UEFI rootkits . In 2021, ESPecter and the FinSpy bootkit demonstrated that the pre-OS stage remained an attractive target for advanced actors.
In the Linux arena, Bootkitty was the first functional test of its kind, albeit with limited scope. And as early as 2025, references 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 serves as a reminder that this category of threats continues to expand.
Practical recommendations to reduce risk
In Linux environments, keeping Secure Boot enabled, applying firmware (UEFI) and kernel updates, and ensuring 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 when appropriate, and avoid loading modules from untrusted sources.
Regularly audit the ESP partition for unauthorized changes to paths such as /EFI/ubuntu/grubx64.efi and verify that no suspicious "copies" (grubx64-real.efi) exist. Any alteration in the GRUB verification flow should be investigated.
In Windows, in addition to Secure Boot, it strengthens Trusted Boot, enables HVCI when supported by the hardware, and adopts TPM-based remote attestation with conditional access policies . It minimizes reliance on third-party CAs if not strictly necessary and accelerates the adoption of revocations when they report failures in boot components.
Some commercial solutions integrate UEFI scanners capable of scanning firmware for malicious components . ESET claims to be the only top 20 endpoint vendor by revenue to offer this integrated capability to its customers, an approach that can add value to in -depth hardware defense .
The trajectory of recent campaigns makes it clear that the boot link remains a prime target. With proper telemetry , firmware/bootloader hardening, and systematic integrity checks, it's possible to significantly raise the bar and make life much more difficult for adversaries.
The state of the art of UEFI bootkits confirms that the boundary between Proof of Concept (PoC) and real-world operation is being crossed ever faster: Bootkitty shows that Linux is already in the crosshairs, BlackLotus solidified viability on Windows, and the defense ecosystem must prioritize boot hygiene, dbx updates, IoC monitoring , and remote attestation to nip any pre-OS persistence attempts in the bud.