ESET researchers find the first UEFI bootkit designed specifically to target Linux systems, marking a shift in bootkits that previously focused on Windows
Article then proceeds to describe a toy GRUB wrapper bootkit that has nothing to do with UEFI firmware (other than running on UEFI systems like any other UEFI bootloader), does not persist in UEFI firmware whatsoever … Hector Martin / @marcan@social.treehouse.systems : @dangoodin Since this is getting some traction and I expect questions about the “Secure Boot” part of the whole story, here's a TL;DR: — Secure Boot means one of three things: — Booting only code signed by the manufactuer or sole “blessed” provider — Booting only code signed by “trusted” providers … X: Alex Matrosov / @matrosov : The bootloader attack surface is highly anticipated, as such attacks occur more frequently than we could see them. Excellent REsearch from @smolar_m and @ESETresearch team! Thaddeus E. Grugq / @thegrugq : “First” @esetresearch : Proof of concept or not, Bootkitty is an interesting progression, breaking the belief that modern UEFI bootkits are Windows-only threats. To find out more, read our WLS blogpost! IoCs available on our GitHub: https://github.com/...... 5/5 [image] @nixcraft : Damn. Nothing is safe out there. Bootkitty: Analyzing the first UEFI bootkit for #Linux https://www.welivesecurity.com/ ... #infosec #security @esetresearch : #ESETresearch reveals the first Linux UEFI bootkit, Bootkitty. It disables kernel signature verification and preloads two ELFs unknown during our analysis. Also discovered, a possibly related unsigned LKM - both were uploaded to VT early this month. https://www.welivesecurity.com/ ... 1/5 @esetresearch : Bootkitty supports only a few Ubuntu versions due to hardcoded byte patterns and how it patches the Linux kernel at hardcoded offsets. We successfully tested it on Ubuntu 24.04.1 LTS running the official kernel image package linux-image-6.8.0-44-generic. 3/5 [image] @esetresearch : The bootkit file contains multiple artifacts suggesting we might be dealing with a proof of concept instead of actively used malware, including ASCII art with the bootkit's name. 2/5 [image] @vxunderground : Today @ESET released a paper on “Bootkitty” the first UEFI bootkit for Linux. We didn't even read the paper, we just liked the name and artwork [image] Forums: Hacker News : Bootkitty: Analyzing the first UEFI bootkit for Linux r/linuxsucks : We don't need bootloader protection!!! Bootkit: Exactly why I'm here
Context & Ripple Effects
Prior coverage established that boot-chain compromise can be unusually durable: MoonBounce survived disk replacement, while BlackLotus showed how Secure Boot bypasses could reach fully updated Windows systems. Bootkitty extends attention to Linux boot paths, but its observed implementation is materially narrower than those firmware-persistent cases.
The finding is most useful as a distinction in threat classification. ESET's artifacts point to a proof of concept built around GRUB, rather than evidence of a deployed compromise of UEFI firmware; its hardcoded Ubuntu-specific offsets further constrain its present reach.
First-order effects
- Linux security teams can use ESET's IoCs to hunt for the GRUB-wrapper artifact and check boot configurations, especially on the limited Ubuntu versions it targets.
- Bootkitty disables kernel signature verification and preloads ELF binaries, making bootloader integrity—not a claim of firmware persistence—the immediate defensive focus.
Second-order effects
- Incident responders and security vendors will need to separate UEFI-resident threats from bootloaders that merely execute on UEFI systems; the remediation scope differs sharply between the two.
- The disclosure adds pressure to validate Secure Boot and GRUB trust-chain controls on Linux, alongside the broader concern raised when leaked signing keys compromised Secure Boot across device models.
Third-order effects
- If Linux-targeted boot-chain tooling matures beyond this proof of concept, operating-system bootloaders become a more prominent persistence layer even where firmware itself is intact.
- The larger security shift is toward treating pre-OS protections as an end-to-end chain: firmware flaws, signing keys, bootloaders, and kernel verification can each determine the effective boundary.
The trend: Boot security is shifting from a firmware-only concern to an end-to-end trust-chain problem spanning UEFI, signed bootloaders, and operating-system kernel controls.