themalwareguardian/cve-2024-7344Technical research on a UEFI Secure Boot bypass caused by an unsafe custom PE loader, including root-cause analysis, exploitation workflow, and an educational proof-of-concept.
This repository contains research material related to CVE-2024-7344, a Secure Boot bypass vulnerability affecting UEFI systems. It centralizes technical analysis of the vulnerability, attack flow documentation, and recreated applications designed to reproduce the vulnerable behavior in controlled environments. The repository also includes documentation and research resources intended to help security researchers understand, study, and experiment with the techniques associated with this vulnerability.
CVE-2024-7344 was originally discovered and responsibly disclosed by the ESET Research Team, with coordinated disclosure support from CERT/CC. Official and community references:
This repository includes a simplified educational proof-of-concept that reproduces the same vulnerability class as CVE-2024-7344. In addition, part of the original real-world implementation has been analyzed and documented through a dedicated UEFI security research effort.
Researchers interested in understanding the historical origin of this vulnerability, the original ALRM format, the custom RxPE loader, and the evolution of the affected products after Microsoft's revocation should refer to the companion repository "UEFI-Security-Research-Howyar-SysReturn-NetCopy".
The original x32 vulnerable UEFI application affected by CVE-2024-7344 is included in this repository.
The x64 binary is known to be available inside an archive hosted on VirusTotal. Access to this sample requires a VirusTotal Enterprise account, and at the time of writing we have not had access to download it. For reference, the sample can be found at the following URL for researchers who do have the appropriate access:
CVE-2024-7344 is a UEFI Secure Boot bypass vulnerability caused by a Microsoft-signed third-party UEFI application that improperly loads and executes unsigned UEFI binaries during the boot process. The vulnerability allows attackers to execute untrusted code before the operating system is loaded, effectively breaking the UEFI Secure Boot chain of trust even when Secure Boot is enabled.
Unlike other Secure Boot bypass vulnerabilities based on memory corruption or NVRAM manipulation, CVE-2024-7344 is the result of a logic and design flaw. The affected UEFI application implements its own custom PE loader instead of relying on the standard UEFI services (LoadImage and StartImage), thereby bypassing all cryptographic verification normally enforced by Secure Boot.
Because the vulnerable application is signed with Microsoft's third-party UEFI certificate and trusted by default on most systems, exploitation occurs at a highly privileged and early execution stage of the platform.
Secure Boot is a core security feature of UEFI designed to enforce the platform's chain of trust from firmware to operating system. Its primary purpose is to prevent unauthorized or malicious boot components, such as bootkits, from executing during the boot process.
At a high level, Secure Boot works by cryptographically validating UEFI executables before they are allowed to run. This validation is performed using two firmware-maintained databases:
A UEFI application is allowed to execute if either:
By default, most systems ship with the following certificates trusted in db:
The vulnerable application affected by CVE-2024-7344 is signed with the Microsoft Corporation UEFI CA 2011 certificate. Because this certificate is widely trusted across vendors and platforms, any vulnerability within such a signed application has a global impact and can be exploited on the majority of UEFI systems.
The vulnerability was discovered by ESET Research Team during analysis of UEFI components shipped with several real-time recovery software products. Initial reconnaissance revealed the presence of a Microsoft-signed UEFI application named reloader.efi, deployed alongside a data file named cloak.dat on the EFI System Partition (ESP).
Inspection of the application showed that it was designed to load and execute an additional UEFI payload from disk during system startup. While such behavior is not inherently unsafe, further reverse engineering revealed that the application does not use standard UEFI image loading services and does not enforce Secure Boot verification on the loaded payload. Further investigation confirmed that the same vulnerable bootloader was used across multiple products from different vendors.
The root cause of CVE-2024-7344 lies in the use of a custom PE loader implemented inside a signed UEFI application. Specifically:
By bypassing LoadImage and StartImage, the application completely avoids Secure Boot verification. As a result, any unsigned UEFI binary can be executed regardless of the Secure Boot state. This represents a fundamental violation of Secure Boot assumptions and is classified as a design-level security flaw rather than an implementation bug.
Exploitation of CVE-2024-7344 does not require memory corruption, race conditions, or complex exploitation primitives. Instead, it relies on abusing the vulnerable application's intended functionality.
A typical exploitation workflow involves:
During boot:
This enables reliable deployment of UEFI bootkits such as BlackLotus or HybridPetya on systems with Secure Boot enabled.
The vulnerable bootloader was distributed as part of several legitimate recovery and backup software products, including:
Microsoft mitigated CVE-2024-7344 by revoking the affected UEFI binaries via Secure Boot dbx updates released on January 14th, 2025, so systems that have applied the latest UEFI revocations are protected against the exploitation of this vulnerability.
Working on something similar? Researching UEFI, Kernel security, exploitation, or another interesting security topic? If you need a hand developing an exploit, exploring a technique, or just want to exchange ideas, don't hesitate to reach out. I'm always open to discussing research, helping where I can, and collaborating on interesting projects. Feel free to contact me on LinkedIn.
