Analyzing the primary UEFI bootkit for Linux

Over the previous few years, the UEFI menace panorama, notably that of UEFI bootkits, has advanced considerably. It began with the primary UEFI bootkit proof of idea (PoC) described by Andrea Allievi in 2012, which served as an indication of deploying bootkits on trendy UEFI-based Home windows techniques, and was adopted with many different PoCs (EfiGuard, Boot Backdoor, UEFI-bootkit). It took a number of years till the primary two actual UEFI bootkits have been found within the wild (ESPecter, 2021 ESET; FinSpy bootkit, 2021 Kaspersky), and it took two extra years till the notorious BlackLotus – the primary UEFI bootkit able to bypassing UEFI Safe Boot on up-to-date techniques – appeared (2023, ESET).

A standard thread amongst these publicly identified bootkits was their unique concentrating on of Home windows techniques. At this time, we unveil our newest discovery: the primary UEFI bootkit designed for Linux techniques, named Bootkitty by its creators. We consider this bootkit is merely an preliminary proof of idea, and based mostly on our telemetry, it has not been deployed within the wild. That mentioned, its existence underscores an vital message: UEFI bootkits are not confined to Home windows techniques alone.

The bootkit’s major objective is to disable the kernel’s signature verification function and to preload two as but unknown ELF binaries through the Linux init course of (which is the primary course of executed by the Linux kernel throughout system startup). Throughout our evaluation, we found a presumably associated unsigned kernel module – with indicators suggesting that it may have been developed by the identical creator(s) because the bootkit – that deploys an ELF binary answerable for loading yet one more kernel module unknown throughout our evaluation.

Key factors of this blogpost:

• In November 2024, a beforehand unknown UEFI utility, named bootkit.efi, was uploaded to VirusTotal.
• Our preliminary evaluation confirmed it’s a UEFI bootkit, named Bootkitty by its creators and surprisingly the primary UEFI bootkit concentrating on Linux, particularly, a number of Ubuntu variations.
• Bootkitty is signed by a self-signed certificates, thus isn’t able to working on techniques with UEFI Safe Boot enabled until the attackers certificates have been put in.
• Bootkitty is designed as well the Linux kernel seamlessly, whether or not UEFI Safe Boot is enabled or not, because it patches, in reminiscence, the mandatory features answerable for integrity verification earlier than GRUB is executed.
• bootkit.efi comprises many artifacts suggesting that is extra like a proof of idea than the work of an energetic menace actor.
• We found a presumably associated kernel module, which we named BCDropper, that deploys an ELF program answerable for loading one other kernel module.

Bootkitty overview

As talked about within the introduction, Bootkitty comprises many artifacts suggesting that we may be coping with a proof of idea as an alternative of actively used malware. On this part, we glance extra carefully at these artifacts, plus different primary details about the bootkit.

Bootkitty comprises two unused features, able to printing particular strings to the display screen throughout its execution. The primary operate, whose output is depicted in Determine 1, can print ASCII artwork that we consider represents a potential title of the bootkit: Bootkitty.

The second operate, can print textual content, proven in Determine 2, containing the checklist of potential bootkit authors and different individuals that maybe one way or the other participated in its improvement. One of many names talked about within the picture will be discovered on GitHub, however the profile doesn’t have any public repository that will include or point out a UEFI bootkit undertaking; due to this fact, we are able to neither affirm nor deny authenticity of the names talked about within the bootkit.

Throughout each boot, Bootkitty prints on display screen the strings proven in Determine 3.

Word that the BlackCat title is referenced additionally within the loadable kernel module described later. Regardless of the title, we consider there isn’t a connection to the ALPHV/BlackCat ransomware group. It is because BlackCat is a reputation utilized by researchers and Bootkitty was developed in C, whereas the group calls itself ALPHV and develops its malware solely in Rust.

As talked about earlier, Bootkitty presently helps solely a restricted variety of techniques. The reason being that to search out the features it needs to switch in reminiscence, it makes use of hardcoded byte patterns. Whereas byte-pattern matching is a standard approach on the subject of bootkits, the authors didn’t use the very best patterns for overlaying a number of kernel or GRUB variations; due to this fact, the bootkit is totally practical just for a restricted variety of configurations. What limits the usage of the bootkit much more is the best way it patches the decompressed Linux kernel: as proven in Determine 4, as soon as the kernel picture is decompressed, Bootkitty merely copies the malicious patches to the hardcoded offsets throughout the kernel picture.

We clarify how the bootkit will get to the precise kernel patching later within the Linux kernel picture decompression hook part; for now, simply word that as a result of lack of kernel-version checks within the operate proven in Determine 4, Bootkitty can get to the purpose the place it patches fully random code or knowledge at these hardcoded offsets, thus crashing the system as an alternative of compromising it. This is without doubt one of the info that helps proof of idea. Then again, it may be an preliminary not-production-ready model of malware created by malicious menace actors.

Final however not least, the bootkit binary is signed by the self-signed certificates proven in Determine 5.

Techical evaluation

We begin with an outline of Bootkitty’s execution, as depicted in Determine 6. First, we briefly describe the primary performance after which in subsequent sections we go into extra particulars.

There are three major components we give attention to:

• Execution of the bootkit and patching of the official GRUB bootloader (factors 4 and 5 in Determine 6).
• Patching of the Linux kernel’s EFI stub loader (factors 6 and seven in Determine 6).
• Patching of the decompressed Linux kernel picture (factors 8 and 9 in Determine 6).

Initialization and GRUB hooking

After Bootkitty is executed by the shim, it checks to see whether or not UEFI Safe Boot is enabled by analyzing the worth of the SecureBoot UEFI variable, and proceeds to hook two features from the UEFI authentication protocols in that case (this course of is proven in Determine 7):

• EFI_SECURITY2_ARCH_PROTOCOL.FileAuthentication: this operate is utilized by the firmware to measure and confirm the integrity of UEFI PE photos. Bootkitty’s hook operate modifies the output of this operate in order that it at all times returns EFI_SUCCESS, that means that the verification succeeded.
• EFI_SECURITY_ARCH_PROTOCOL.FileAuthenticationState: this operate is utilized by the firmware to execute a platform-specific coverage in response to completely different authentication standing values. Once more, the bootkit’s hook modifies it in a method that it at all times returns EFI_SUCCESS, that means that the firmware can use the file no matter its precise authentication standing.

After checking the standing of UEFI Safe Boot, Bootkitty proceeds to load the official GRUB from the hardcoded path on the EFI system partition: /EFI/ubuntu/grubx64-real.efi. This file needs to be a backup, created by the attacker, of a official GRUB. As soon as GRUB is loaded (not but executed), the bootkit begins patching and hooking the next code in GRUB’s reminiscence:

• The start_image operate throughout the peimage GRUB module (a module embedded inside GRUB). This operate is answerable for beginning an already loaded PE picture, and it’s invoked by GRUB to begin the Linux kernel’s EFI stub binary (identified usually as vmlinuz.efi or vmlinuz). The hook operate takes benefit of the truth that in the meanwhile the hook is executed, vmlinuz is already loaded into reminiscence (however hasn’t been executed but), and patches the operate answerable for decompressing the precise Linux kernel picture inside vmlinuz (word that in some circumstances, as a result of method the Linux kernel is compiled, it may be fairly difficult to search out the precise title of the operate being patched; nonetheless, we consider that this time it needs to be the zstd_decompress_dctx operate). Extra particulars in regards to the decompression hook are within the Linux kernel picture decompression hook part.
• The shim_lock_verifier_init operate, which is a part of the shim_lock verifier mechanism inside GRUB – this needs to be activated routinely if UEFI Safe Boot is enabled. It’s answerable for deciding whether or not the recordsdata supplied (e.g., GRUB modules, Linux kernel, configurations…) needs to be verified or not in the course of the boot. The put in hook, nonetheless, is one way or the other complicated and the creator’s intentions are unclear as a result of it modifies shim_lock_verifier_init’s output in a method that it units the output flag to GRUB_VERIFY_FLAGS_SINGLE_CHUNK (worth 2) for any file sort supplied, which ought to, in accordance with the GRUB guide, strengthen the safety much more. Curiously, as a result of hook described within the subsequent level, this shim_lock_verifier_init operate isn’t even referred to as in the course of the boot, thus changing into irrelevant.
• The grub_verifiers_open operate. This operate is invoked by GRUB anytime it opens a file, and is answerable for checking whether or not the put in GRUB file verifiers (this consists of the shim_lock verifier described above) require integrity verification for the file being loaded. The operate is hooked by the bootkit in a method that it returns instantly with out continuing to any signature checks (word that because of this it doesn’t even execute the beforehand hooked shim_lock_verifier_init operate).

Linux kernel picture decompression hook

• Rewrites the kernel model and Linux banner strings with the textual content BoB13 (this has no vital affect on the system).
• Hooks the module_sig_check operate.
• Patches pointer/tackle to the primary surroundings variable of the init course of.

The operate module_sig_check is patched to at all times return 0. This operate is answerable for checking whether or not the module is validly signed. By patching the operate to return 0, the kernel will load any module with out verifying the signature. On Linux techniques with UEFI Safe Boot enabled, kernel modules want to be signed if they’re meant to be loaded. That is additionally the case when the kernel is constructed with CONFIG_MODULE_SIG_FORCE enabled or when module.sig_enforce=1 is handed as a kernel command line argument, as described within the Linux kernel documentation. The possible situation is that no less than one malicious kernel module is loaded at a later part, such because the dropper analyzed under.

The primary course of that the Linux kernel executes is init from the primary hardcoded path that works (beginning with /init from initramfs), together with command line arguments and surroundings variables. The hook code replaces the primary surroundings variable with LD_PRELOAD=/decide/injector.so /init. LD_PRELOAD is an surroundings variable that’s used to load ELF shared objects earlier than others and can be utilized to override features. It’s a widespread approach utilized by attackers to load malicious binaries. On this case, the /decide/injector.so and /init ELF shared objects are loaded when the init course of begins. That is the place the intention turns into much less clear, primarily why the second string /init is a part of LD_PRELOAD.

We’ve got not found any of those presumably malicious ELF shared objects, though simply as this blogpost was being finalized for publication, a write-up describing the lacking elements talked about in our report has been printed. Now it’s clear they’re used simply to load one other stage.

Impression and remediation

Other than loading unknown ELF shared objects, Bootkitty leaves footprints within the system. The primary is the supposed, albeit not mandatory, modification of kernel model and Linux banner strings. The previous will be seen by working uname -v (Determine 9) and the latter by working dmesg (Determine 10).

Throughout our evaluation, the output of the command dmesg additionally included particulars about how the init course of was run. As depicted in Determine 11, the method was run with the LD_PRELOAD surroundings variable (it was initially HOME=/ and was changed with LD_PRELOAD=/decide/injector.so /init by the bootkit).

Word in Determine 11 that the phrase /init within the first line corresponds to the official program in initramfs that finally passes management to systemd on default Ubuntu installations. The presence of the LD_PRELOAD surroundings variable can be verified by inspecting the file /proc/1/environ.

After booting up a system with Bootkitty in our testing surroundings, we observed that the kernel was marked as tainted (command from Determine 12 can be utilized to verify the contaminated worth), which was not the case when the bootkit was absent. One other technique to inform whether or not the bootkit is current on the system with UEFI Safe Boot enabled is by making an attempt to load an unsigned dummy kernel module throughout runtime. If it’s current, the module will probably be loaded; if not – the kernel refuses to load it.

A easy treatment tip to eliminate the bootkit is to maneuver the official /EFI/ubuntu/grubx64-real.efi file again to its authentic location, which is /EFI/ubuntu/grubx64.efi. This can make shim execute the official GRUB and thus the system will boot up with out the bootkit (word that this covers solely the situation when the bootkit is deployed as /EFI/ubuntu/grubx64.efi).

BCDropper and BCObserver

Along with the bootkit, we found a presumably associated unsigned kernel module we named BCDropper, uploaded to VirusTotal across the similar time and by the identical submitter’s ID because the bootkit, containing hints that it may need been developed by the identical creator because the bootkit, reminiscent of:

• a BlackCat string within the output of the modinfo command’s output, proven in Determine 13,
• one other presence of the blackcat string within the debug paths within the module’s binary, proven in Determine 14, and
• it comprises an unused file-hiding operate that hides particular entries from listing listings. As proven in Determine 15, one of many hardcoded filename string prefixes used to filter-out these entries is injector (word that Bootkitty tries to preload a shared-library from the trail /decide/injector.so)

Nonetheless, even with the proof offered, we can not say for positive whether or not or not the kernel module is said to Bootkitty (or was created by the identical developer). Additionally, the kernel model talked about in Determine 13 (6.8.0-48-generic) isn’t supported by the bootkit.

As its title suggests, the kernel module drops an embedded ELF file we named BCObserver, particularly to /decide/observer, and executes it through /bin/bash (Determine 17). On prime of that, the module hides itself by eradicating its entry from the module checklist. The kernel module additionally implements different rootkit-related functionalities like hiding recordsdata (these in Determine 15), processes, and open ports, however they don’t seem to be immediately utilized by the dropper.

BCObserver is a reasonably easy utility that waits till the show supervisor gdm3 is working, after which masses an unknown kernel module from /decide/rootkit_loader.ko through the finit_module system name. By ready for the show supervisor to begin, the code ensures that the kernel module is loaded after the system is totally booted up.

Whereas we can not affirm whether or not the dropper is one way or the other associated to the bootkit, and in that case, how it’s meant to be executed, we’re fairly positive that the bootkit patches the module_sig_check operate for a cause, and loading an unsigned kernel module (such because the dropper described right here) would positively make sense.

Conclusion

Whether or not a proof of idea or not, Bootkitty marks an attention-grabbing transfer ahead within the UEFI menace panorama, breaking the assumption about trendy UEFI bootkits being Home windows-exclusive threats. Though the present model from VirusTotal doesn’t, in the meanwhile, signify an actual menace to the vast majority of Linux techniques, it emphasizes the need of being ready for potential future threats.

To maintain your Linux techniques protected from such threats, make it possible for UEFI Safe Boot is enabled, your system firmware and OS are up-to-date, and so is your UEFI revocations checklist.

For any inquiries about our analysis printed on WeLiveSecurity, please contact us at threatintel@eset.com. 

ESET Analysis affords non-public APT intelligence experiences and knowledge feeds. For any inquiries about this service, go to the ESET Menace Intelligence web page.

IoCs

A complete checklist of indicators of compromise (IoCs) and samples will be present in our GitHub repository.

Information

MITRE ATT&CK methods

This desk was constructed utilizing model 16 of the MITRE ATT&CK framework.