Attackers Living Outside The Operating System
Like many in our field, I thought we’d seen the last of Petya-style attacks after the chaos of 2017. As it turns out, that was wishful thinking. ESET Research recently uncovered something that caught my attention immediately – a new variant they’ve dubbed “HybridPetya” that combines ransomware with UEFI exploitation techniques and bootkits. HybridPetya represents a concerning milestone: the marriage of legacy destructive techniques with pre-operating system UEFI firmware implants and attack vectors. This isn’t just another ransomware family – it’s a preview of what happens when attackers exploit the UEFI and pre-OS attack surface to their advantage, circumventing traditional operating system controls.
What Makes HybridPetya Different (and Dangerous)
The original Petya (non-destructive ransomware) and NotPetya (destructive malware masked as ransomware) malware were nasty enough. Malware authors have implemented encryption of the NTFS Master File Table, essentially rendering the entire file system unreadable while leaving the actual file data intact.
HybridPetya takes ransomware to a new level. The key innovation is the addition of a UEFI bootkit component that can compromise modern systems by installing a malicious EFI application directly onto the EFI System Partition. This means the malware now operates before the operating system, giving it unprecedented persistence and stealth capabilities. Something that really caught my attention in the ESET analysis is how HybridPetya exploits CVE-2024-7344 to bypass UEFI Secure Boot. This vulnerability enables the malware to exploit a vulnerability in a UEFI application, thereby circumventing one of our most trusted boot integrity mechanisms. ESET discovered CVE-2024-7344 in January of this year, describing the vulnerability as follows:
“The vulnerability is caused by the use of a custom PE loader instead of using the standard and secure UEFI functions LoadImage and StartImage. As a result, the application allows the loading of any UEFI binary – even an unsigned one – from a specially crafted file named cloak.dat, during system start, regardless of the UEFI Secure Boot state.”
—Source
For those of us who’ve been preaching firmware security for years, this is the “I told you so” moment we never wanted to have. The vulnerable UEFI application was bundled with several system recovery tools, including those from Howyar Technologies.
Technical Deep Dive: How the Attack Unfolds
From a technical perspective, HybridPetya follows a multi-stage attack chain that combines the best (worst?) aspects of both traditional malware and modern firmware attacks:
Stage 1: Initial Compromise and Persistence
The malware begins by installing EFI applications and configuration files to the EFI System Partition, including:
- Vulnerable, signed boot loader – HybridPetya copies the file bootmgfw.efi to the EFI partition, replacing the existing bootloader. This new bootloader is reloader.efi, which is signed by Microsoft and distributed by several companies offering system recovery utilities.
- UEFI application – The cloak.dat file is a UEFI application that can be loaded by reloader.efi at runtime (reloader.efi contains logic to look for this file and execute it).
- Configuration files for ransomware – Three configuration files are copied, allowing the ransomware to determine the status of the drive encryption (and decryption).
Stage 2: Secure Boot Bypass
The reloader.efi application is vulnerable to CVE-2024-7344, a vulnerability that allows an attacker to execute unsigned code, thereby bypassing Secure Boot protections. The vulnerability is as follows:
- reloader.efi contains code that looks for and loads a file named cloak.dat
- It checks for not only the file name, but magic bytes (“ALRM”), file structure, and XOR “encryption”; if these characteristics are present, it will begin executing the code.
- reloader.efi’s vulnerability lies in how the external file is called. Rather than using UEFI functions such as LoadImage/StarteImage, which check the signature before loading, it uses a custom PE loader that does not validate the external program against the Secure Boot root of trust.
- This allows an attacker to create a cloak.dat file with the same characteristics as the original and add code that can perform malicious operations, and will still pass Secure Boot checks.
This is particularly concerning because Secure Boot was supposed to be our defense against precisely this type of attack.
Stage 3: Encryption and Deception
Once the bootkit is established, HybridPetya proceeds with its primary payload – encrypting the Master File Table using the Salsa20 encryption algorithm. During this process, it displays fake CHKDSK messages to the user, making it appear as though the system is performing routine maintenance rather than being actively compromised.
The malware also creates backup files and tracks encryption progress, indicating a level of sophistication that exceeds that of typical ransomware. It can even recover legitimate bootloaders after successful decryption, which shows the authors understand the importance of maintaining system functionality for their business model.
Visibility Into The Firmware Blind Spot
As someone who’s spent years trying to convince organizations that firmware security matters, HybridPetya perfectly illustrates why traditional endpoint detection approaches fall short against firmware-level threats. When malware operates at the UEFI level, it resides in what I like to call “the dusty corners” of your IT infrastructure. In these areas, most security tools (and therefore IT and security teams) typically do not provide visibility.
Traditional antivirus solutions, endpoint detection and response (EDR) platforms, and even advanced threat hunting tools typically operate at the OS level or higher. They’re looking for malicious processes, suspicious network connections, and abnormal file system activity. But HybridPetya establishes itself before any of these monitoring systems even start running.
The Secure Boot bypass capability makes detection even more challenging. Organizations that believe UEFI Secure Boot protects them may not realize their systems are vulnerable to CVE-2024-7344, creating a false sense of security that attackers can exploit. For example, simply auditing your systems to verify if Secure Boot is enabled is not enough; you also need to check for outdated certificates and DBX revocation lists.
Defending Against the Hybrid Threat
Here are the key detection strategies defenders should implement:
- Bootloader/EFI Integrity Monitoring: Establish baselines for EFI System Partition contents and monitor for unauthorized changes. Any unexpected EFI applications should trigger immediate investigation. Our platform continuously monitors EFI System Partitions and other firmware components for unauthorized modifications. If HybridPetya attempts to install its malicious EFI application, we’ll detect the change immediately.
- Boot Chain Analysis: Implement continuous monitoring of the entire boot sequence, from firmware initialization through OS loading. Look for anomalies in boot timing, unexpected certificate usage, or modifications to boot configuration. We analyze the entire boot chain, including EFI applications, boot loaders, and configuration files. The installation of HybridPetya’s bootkit component would trigger alerts based on our understanding of normal boot behavior.
- Vulnerability Assessment: Our platform identifies systems vulnerable to CVE-2024-7344 and other firmware-level vulnerabilities that threats like HybridPetya could exploit. This allows organizations to prioritize patching efforts and understand their exposure.
- Secure Boot Status Verification: Regularly verify that Secure Boot is enabled and functioning correctly. More importantly, ensure that systems are patched against CVE-2024-7344 and other Secure Boot bypass vulnerabilities by keeping certificates and revocation lists up to date. Our platform identifies the Secure Boot root of trust and determines if updates are required.
Conclusion: Trust, But Verify Everything
HybridPetya isn’t just another malware family – it’s a signal that attackers are increasingly focused on firmware-level compromise techniques that live outside the operating system. As traditional endpoint security controls become more effective, adversaries are moving down the stack to establish persistence and evade detection.
The use of CVE-2024-7344 to bypass Secure Boot is particularly concerning because it demonstrates that attackers are actively researching and weaponizing firmware vulnerabilities. No longer are UEFI attack techniques limited to sophisticated nation-state attackers; they are now being included in everyday ransomware.
Organizations that treat firmware security as an afterthought are essentially leaving the front door unlocked while installing bars on the windows. You can have the best endpoint detection and response platform in the world. Still, if an attacker can compromise your system at the firmware level, they’re already inside your defensive perimeter before your security tools even begin to run.
The good news is that while HybridPetya represents a significant evolution in attack techniques, it’s still detectable and preventable with the right approach. The key is to extend your security visibility down into the firmware layer and implement continuous monitoring of boot integrity.
Related Resources:
- Podcast: Below the Surface, Episode 60
- Research Blog: One Bootloader to Load Them All
