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.
