The attack surface Eclypsium set out to defend extends to areas in our systems that many security teams and monitoring tools are either overlooking or trusting someone else has secured for them. This pre-operating system attack surface includes components such as UEFI and bootloaders. At a very high level, UEFI initializes the hardware, and the bootloader helps to load the operating system kernel. These attacks underscore the strategic value of compromising bootloaders: once an attacker controls the boot process, they can subvert all higher-layer security controls, maintain deep persistence, and potentially evade detection by traditional security tools. We gain a false sense of security as we lock down our operating system attack surface with configuration settings (hardening) and 3rd party software such as EDR. Even at the kernel level, security controls can be bypassed using bootkits and UEFI malware.
Our latest product enhancements to the Eclypsium Supply Chain Security Platform deliver comprehensive detection and remediation capabilities for various conditions in pre-operating system components. Each is mapped to real-world threats and attack techniques. Below, we break down each new or enhanced detection, the threats it addresses, and recommended remediation strategies.
Suspicious Bootloader Behaviors
Bootloaders bridge firmware and the operating system by initializing the system and verifying the OS before handing over control. As the first code to execute after firmware, bootloaders operate with elevated system privileges, making them a prime target for attackers seeking persistent and stealthy control over devices. The attack surface of bootloaders has grown significantly as they have evolved to support more features, such as handling multiple storage types, file systems, network booting, and user interfaces. This increased complexity introduces more opportunities for vulnerabilities, particularly memory safety issues. Vulnerabilities in bootloaders could be exploited to bypass security measures. Recent research has identified storage, network, and console input as the primary vectors for attacking bootloaders, with vulnerabilities in these areas enabling attackers to achieve denial of service, bypass Secure Boot, or install persistent malware such as bootkits and rootkits.
Notable real-world examples include the BlackLotus bootkit, which exploited a vulnerability in the Windows bootloader (CVE-2022-21894, “Baton Drop”) to bypass UEFI Secure Boot, and the BootHole vulnerability in GRUB2, which allowed arbitrary code execution even with Secure Boot enabled. Other attacks, such as EFILock ransomware, have replaced legitimate bootloaders with malicious ones to prevent systems from booting, demanding ransom for recovery. Additionally, advanced persistent threats (APTs) and ransomware groups have leveraged bootloader and UEFI vulnerabilities to implant malware that survives OS reinstalls and hardware replacements, as seen with LoJax, MosaicRegressor, and TrickBoot.
The growing number of vulnerabilities—such as the 39 new flaws discovered in recent systematic analyses of widely used bootloaders like GRUB, U-Boot, and Barebox—highlights the urgent need for increased security in bootloaders and ongoing integrity monitoring in operational environments.
Given the growing threat landscape surrounding bootloaders (and other UEFI applications), we’ve enhanced our detections to include analyzing binaries in the EFI partition for:
- Evidence of runtime services overwriting (e.g., SetVariable, UpdateCapsule, etc.). A UEFI binary attempting to overwrite the Runtime Services Table pointers suggests malware is hijacking or subverting critical firmware-level functions to persist across operating system boot, enabling stealthy control or tampering (Example: MoonBounce UEFI Malware).
- Evidence of Boot services overwriting (e.g., ImageLoad or ExitBootServices). A UEFI binary attempting to overwrite the Boot Services Table pointers suggests potential malicious behavior intended to manipulate or disable essential pre-boot functionality. Malware may have compromised system initialization or attempted to evade security checks before the OS loads. (Example: Glupteba Malware)
- Malware attempts to disable CET (Control-flow Enforcement Technology), potentially undermining system security before the operating system initializes. Disabling CET prevents the activation of features like Shadow Stack and Indirect Branch Tracking, allowing the use of classic exploitation techniques such as ROP.
- Malware attempting to patch the KeInitAmd64SpecificState function to skip its logic, effectively disabling PatchGuard initialization. This allows kernel modifications without triggering a system crash.
- The NX bit is a hardware feature that marks memory regions as non-executable, blocking code execution from areas like the stack or heap. Malware commonly disables this feature to enable other attacks.
- Flag excessively long strings or malformed entries in GRUB configuration files (e.g., grub.cfg). This condition was used to exploit vulnerable GRUB packages dubbed Boothole.
- Identification of lingering or misconfigured bootloaders, including mismatches between bootloaders and installed operating systems (e.g., a Linux bootloader on a Windows system).
- UEFI Shell is present in the boot order, which could indicate a potential security risk. For example, attackers can use the UEFI shell’s functionality to disable Secure Boot.
Threats Detected:
- Attackers may leave behind rogue bootloaders as a persistence mechanism, even after OS reinstallation.
- Mismatched bootloaders can be exploited to bypass Secure Boot or load unsigned, malicious payloads.
- UEFI Shell in boot order may allow attackers to gain interactive access before the OS loads.
- Disabling CET, NX-bit, or PatchGuard undermines OS-level protections, enabling classic exploitation techniques (e.g., ROP and execution from non-executable memory regions).
Secure Boot Failures
Secure Boot’s effectiveness relies on a tightly maintained chain of trust, but several configuration conditions can render it ineffective and expose systems to attack. One of the most critical issues is an out-of-date DBX (the UEFI Secure Boot revocation list), which allows known-vulnerable bootloaders to remain trusted and executable even after discovering severe vulnerabilities. Similarly, outdated or misconfigured SBAT (Shim Boot Advanced Targeting) policies can allow legacy or insecure versions of bootloaders to run, as seen when recent SBAT policy updates began blocking all shim versions before 15.8, causing “Secure Boot Violation” errors on systems using older installation media. These lapses are often compounded by inconsistent distribution of DBX updates across vendors and platforms, as highlighted by incidents where the UEFI Forum’s official DBX list lagged behind Microsoft’s, leaving many devices exposed to known Secure Boot bypasses. Ultimately, Secure Boot only delivers on its security promise when DBX and SBAT policies are current and the platform is configured to enforce signature checks on all boot components. To aid in this analysis, we’ve implemented a couple of new enhancements (as we already check the DBX versions):
- Identifies binaries that fail Secure Boot verifications (against DBX, SBAT, or signature checks) or are missing required SBAT sections.
- Detects downgrades in firmware or software components between scans, especially missing DBX hashes, which are critical for Secure Boot integrity.
Threats Detected:
- Indicates attempts to load unsigned or revoked binaries, potentially as part of a bootkit or firmware-level attack.
- Missing or outdated DBX entries may allow known threats to bypass Secure Boot.
- Attackers may downgrade components to exploit older, vulnerable versions or remove DBX entries to re-enable revoked binaries.
BootKitty Detection: Patterns and Hashes
Initially analyzed by ESET and later revealed to be a student project from Korea’s Best of the Best (BoB) training program, Bootkitty was designed to raise awareness about the risks posed by bootkits rather than to serve as an active threat. The bootkit itself does not bypass Secure Boot on its own, as it relies on self-signed certificates; however, when combined with Secure Boot bypass vulnerabilities, attackers can inject a Machine Owner Key (MOK) to allow Bootkitty’s malicious bootloader and kernel to pass Secure Boot verification without user interaction. This technique leverages the exploitation of UEFI vulnerabilities to facilitate the installation of backdoored boot components. While Bootkitty is not a persistent UEFI implant—meaning it does not modify UEFI firmware directly and can be remediated by restoring a known-good bootloader—it exemplifies the types of pre-OS attacks that can evade detection. The emergence of Bootkitty underscores the need for continuous monitoring of bootloader integrity and detection of infection techniques. Similar techniques may quickly transition from proof-of-concept to use by a real-world threat actor. Therefore, we’ve implemented detections that recognize known patterns and hashes associated with BootKitty.
Remediation
Recovering from a compromised or misconfigured boot environment requires a comprehensive approach to restore a system’s integrity and re-establish trust in the boot process. Start by rebuilding the bootloader using trusted installation media to ensure no malicious code persists from previous infections. Carefully verify all boot entries, removing any that do not correspond to legitimate operating system installations, and eliminate unauthorized UEFI Shell entries from the boot order. Next, re-enable and strictly enforce Secure Boot, ensuring that keys, the DBX (revocation list), and SBAT policies are fully up to date to block known vulnerable or malicious bootloaders. Hardware security features such as Control-flow Enforcement Technology (CET) and the NX bit should be re-enabled to provide additional layers of protection. Audit UEFI settings and restore them to manufacturer defaults, as attackers may have altered configurations to weaken security. Remove or quarantine any non-compliant binaries that could bypass Secure Boot or introduce risk. Apply the latest firmware and Secure Boot updates, and, if necessary, immediately reflash the firmware with a clean, vendor-supplied image to eliminate any persistent implants. Conduct a full system integrity check and rotate credentials to mitigate the risk of credential theft or privilege escalation. Finally, investigate system logs for evidence of unauthorized downgrade activity and implement strict update and rollback prevention policies to prevent future attacks that rely on reverting to vulnerable states. This layered, methodical process is essential to fully eradicate threats and restore a trusted, resilient boot environment.
Conclusion
Attackers are increasingly targeting the boot process and firmware to gain persistence, evade detection, and undermine platform security. For more details, check out our recent webinar on the Top Firmware and Hardware Attack Vectors. To defend this increasingly targeted attack surface, our enhanced detection capabilities provide deep visibility into bootloaders, bootkits, and Secure Boot integrity, surfacing known and novel threats. Remediation requires a combination of firmware restoration, Secure Boot enforcement, and ongoing monitoring—empowering defenders to reclaim the “home-field advantage” and prevent attackers from creating their playing field at the firmware level.
