HybridPetya Ransomware Bypasses UEFI Secure Boot via CVE‑2024‑7344

If you’ve been leaning on UEFI Secure Boot as your last line of defense against bootkits, this one will make you sit up. A new ransomware strain dubbed “HybridPetya” doesn’t just echo the infamous Petya/NotPetya playbook—it escalates it. Researchers at ESET say HybridPetya can bypass UEFI Secure Boot using CVE‑2024‑7344, a now-revoked vulnerability in a third-party UEFI application, to run a malicious bootloader before Windows even starts.

Why that’s a big deal: this ransomware encrypts the Master File Table (MFT) on NTFS disks, stopping Windows from finding your files—even if the files themselves aren’t individually encrypted. And it does this at the firmware-boot level, where your EDR has the least visibility.

Let’s unpack what HybridPetya is, how it works, what the Secure Boot bypass means, and what practical steps you can take today to mitigate risk.

The Two-Minute Summary: Why HybridPetya Matters

It targets modern systems. HybridPetya is designed for UEFI-based machines and can bypass Secure Boot using CVE‑2024‑7344.
It encrypts the Master File Table (MFT). That means Windows can’t locate files on NTFS partitions—a fast way to cause chaos.
It uses a bootkit + installer combo. The installer deploys a bootkit to the EFI System Partition (ESP), then forces a crash so the bootkit runs at startup.
It fakes CHKDSK. Victims see what looks like a disk repair screen while the ransomware is actively encrypting.
It demands $1,000 in Bitcoin. A decryption flow exists, unlike the destructive NotPetya variant.
It may be a proof-of-concept. ESET hasn’t seen in-the-wild attacks yet, but the technique is real and repeatable.
It joins a worrying trend. Secure Boot bypasses aren’t one-offs anymore. Think BlackLotus and LogoFail.

If you manage Windows fleets, endpoints with Secure Boot, or critical infrastructure, this is your cue to verify UEFI security, apply revocations, and add firmware-layer checks to your incident response playbooks.

For the primary research summary, see ESET’s reporting on UEFI bootkits and Secure Boot bypasses at WeLiveSecurity.

What Is HybridPetya?

HybridPetya is a new ransomware family observed by ESET in samples submitted to VirusTotal in February 2025. It borrows its core idea from Petya/NotPetya—encrypt the Master File Table (MFT) to break access to files—but adds a twist: it can deploy a UEFI bootkit to run before the OS and bypass Secure Boot under certain conditions.

A few key points:

It resembles Petya/NotPetya but is not identical. HybridPetya appears more “ransomware-like” than the destructive NotPetya, offering a decryption flow after payment.
It targets the EFI System Partition (ESP). This is the small partition used for bootloaders on UEFI systems.
It combines a traditional installer with a pre-OS bootkit. That makes it evasive and difficult to remediate without full re-imaging.

For quick background on Petya and NotPetya, see CISA’s historical alert on the 2017 outbreak: CISA Alert on Petya/NotPetya.

How HybridPetya Actually Works (Plain-English Walkthrough)

Think of your computer’s boot process like a carefully guarded airport. UEFI Secure Boot checks every “boarding pass” (bootloader) before letting it board the system. HybridPetya sneaks in a forged pass through a vulnerable gate agent—then takes over the flight.

Here’s the high-level flow:

Installer runs in Windows. – It drops a malicious EFI application to the EFI System Partition (ESP). – It alters bootloader paths and triggers a system crash (Blue Screen) to force a reboot.
On reboot, the bootkit takes over before Windows. – It loads configuration, checks status, and starts encryption if not already done. – It displays a fake CHKDSK to keep you calm.
It encrypts the MFT on NTFS partitions. – This breaks file access while appearing like a system fix.
It shows a ransom screen once encryption completes. – Victims are urged to pay $1,000 in Bitcoin.
If a key is entered, it attempts decryption. – It restores legitimate bootloaders and prompts a reboot.

Now let’s go deeper into each stage without getting overly technical.

The Bootkit vs. The Installer

HybridPetya ships as two major components:

The installer (runs in the OS) sets up the environment for persistence and encryption.
The bootkit (runs before the OS) handles the encryption process and ransom flow.

The bootkit tracks progress using a “flag” in its configuration: – 0 = ready for encryption – 1 = disk encrypted – 2 = ransom paid, disk decrypted

If it sees 0, it starts encryption and flips to 1. If it sees 1, it shows a ransom note. If it sees 2, it attempts decryption and cleanup.

The MFT Encryption Trick

Instead of encrypting files one by one, HybridPetya attacks the Master File Table—the index that tells Windows where each file lives on disk. Encrypt that index, and your files might still be present, but Windows is blindfolded.

HybridPetya encrypts using the Salsa20 algorithm (a well-known stream cipher) with a key and nonce stored in configuration. For basics on Salsa20, see Salsa20.
It also writes a “counter” file on the ESP to track how many disk clusters have been encrypted. This lets it show progress and, in theory, reverse operations later.

Why it matters: MFT attacks are fast and devastating. They cause system-wide disruption quickly. And because the attack runs before the OS, conventional EDR tools may miss it.

The Fake CHKDSK Screen

While encryption runs, victims see what looks like a CHKDSK window (“Checking disk for errors”). It’s theater. The malware updates the message with progress to make it feel routine. By the time you realize something’s off, the MFT is already encrypted.

Ransom Note and Wallet

Once encryption finishes, HybridPetya displays a ransom message and demands $1,000 in Bitcoin. A wallet observed in reports (34UNkKSGZZvf5AYbjkUa2yYYzw89ZLWxu2) had only modest activity and was empty at the time of analysis—another signal this may be a proof-of-concept or limited test run, not a wide campaign.

The note includes a field for a “deception key” the victim supposedly receives after paying. When entered, the bootkit attempts to decrypt the MFT and restore normal bootloaders it had backed up earlier.

Important: Paying ransom is high risk and not recommended by most security authorities. It doesn’t guarantee decryption, and it fuels further attacks. See guidance from the FBI and CISA on ransomware response best practices.

The Secure Boot Bypass via CVE‑2024‑7344

Now for the part that should be on every defender’s radar.

HybridPetya variants can exploit CVE‑2024‑7344, a vulnerability in the “Howyar Reloader” UEFI application (reloader.efi). When abused, this allows a malicious bootloader to load during startup—bypassing UEFI Secure Boot integrity checks.

The malicious file is deployed as a replacement for the Windows boot manager file, typically named bootmgfw.efi.
A specially crafted cloak.dat file on the ESP holds the XOR‑obfuscated bootkit.
When the vulnerable reloader.efi runs at boot, it looks for cloak.dat and loads the embedded UEFI application without proper validation. That’s the bypass.

Microsoft has revoked the vulnerable binary as part of its January 2025 Patch Tuesday process, which effectively blocks that boot component from loading on systems with updated revocation lists.

For more on Secure Boot and how it is supposed to work, see UEFI Secure Boot. For the CVE entry, see NVD: CVE‑2024‑7344.

Why Secure Boot Bypasses Keep Happening

Secure Boot is designed to load only signed, trusted bootloaders. But the chain is only as strong as its weakest link. Vulnerabilities in third-party UEFI apps, poorly validated loaders, or unrevoked certificates can create gaps.

HybridPetya isn’t the first to exploit such a gap:

BlackLotus bootkit exploited CVE‑2022‑21894 to bypass Secure Boot on fully patched systems. More from ESET: BlackLotus UEFI bootkit.
“LogoFail” revealed weaknesses in image-parsing during boot on multiple vendors. See Binarly’s analysis: LOGOFAIL.
The Hyper‑V Backdoor PoC showed additional Secure Boot bypass mechanics in earlier research. See NVD: CVE‑2020‑26200.

The lesson: Secure Boot isn’t broken, but it requires regular firmware updates, revocation list (DBX) updates, and disciplined control over what’s allowed to run during boot.

Is HybridPetya Active in the Wild?

ESET reports no confirmed in-the-wild attacks as of their analysis. Samples showed up on VirusTotal in February 2025, and the wallet associated with ransom notes showed limited activity.

There’s also mention of a UEFI Petya proof‑of‑concept from researcher Aleksandra “Hasherezade” Doniec, which could indicate shared ideas or inspiration. HybridPetya might be a weaponized PoC or a testbed for techniques that could surface in future campaigns.

Even if this specific strain is limited, the capability is real. Attackers often follow researcher breadcrumbs. Treat this as an early warning and validate your Secure Boot posture now.

For malware sample tracking, see VirusTotal.

Who’s at Risk?

Enterprises running Windows on UEFI systems, especially where Secure Boot revocations are not up to date.
Organizations with mixed hardware fleets and inconsistent firmware management.
Environments that allow third-party bootloaders or have customized boot flows.
High-value endpoints with weak MDM/EDR coverage at the firmware level.

Individual consumers are less likely targets for firmware bootkits, but not immune—especially if running older systems or dual-boot setups with less strict boot policies.

Defender Playbook: How To Mitigate and Prepare

Here’s the practical checklist your team can act on today. Keep it simple, measurable, and repeatable.

1) Patch, Revoke, and Validate Secure Boot

Apply the latest Windows security updates. Microsoft has revoked the vulnerable reloader.efi via Patch Tuesday (January 2025). Keep your Secure Boot DBX up to date so revoked binaries can’t load.
Confirm Secure Boot is enabled in UEFI settings.
Verify DBX (forbidden signatures) is current. If your org uses golden images, ensure they include the latest DBX.
Work with OEMs for firmware updates. Many vendors push UEFI updates via their update utilities or Windows Update.

Helpful references: – Microsoft Secure Boot overview: UEFI Secure Boot – Microsoft Security Update Guide: MSRC Update Guide

2) Harden the Boot Process and ESP

Lock down the EFI System Partition (ESP). Limit write permissions and monitor for changes to:
\EFI\Microsoft\Boot\bootmgfw.efi
\EFI\Boot\bootx64.efi
Suspicious files like cloak.dat or unexpected “counter” files.
Enforce measured boot where possible. Use TPM-backed attestation to detect boot tampering.
Enable BitLocker with TPM + Secure Boot integration. Validate PCR bindings so changes in bootloaders trigger recovery prompts.
Minimize third‑party boot components. If you don’t need them, don’t allow them.

For platform resiliency, see NIST SP 800‑193: Platform Firmware Resiliency Guidelines.

3) Monitor for Bootkit Tradecraft

Bootkits are stealthy, but they often leave traces:

Look for unusual BSOD followed by persistent CHKDSK screens at boot.
Monitor for writes to the ESP from non‑privileged processes.
Baseline and alert on changes to bootloader hashes.
Watch for NTFS volumes becoming inaccessible despite healthy SMART metrics.
Keep an eye on ETW and Windows event logs for firmware/boot anomalies after updates.
Map detections to MITRE ATT&CK T1542.003 (Boot or Logon Autostart Execution: Bootkit): MITRE ATT&CK T1542.003

If your EDR supports UEFI scanning, turn it on everywhere. If not, consider periodic offline checks. Frameworks like CHIPSEC can validate certain firmware integrity properties in a lab setting: CHIPSEC. Use caution and follow vendor guidance—firmware tools can be invasive.

4) Prepare an Incident Response Path for UEFI-Level Threats

Bootkits change your response sequence. Here’s a high‑level response flow:

Isolate the affected device from the network. Don’t keep rebooting.
Preserve evidence. If feasible, capture forensic images including the ESP.
Assume OS-level tools may be blind to pre‑OS components.
Engage your IR team or a trusted partner with firmware expertise.
Plan to re‑provision. A clean, known‑good rebuild is often the safest route after a bootkit.
Restore from verified, offline backups. Validate integrity before bringing systems back online.
Rotate credentials and review lateral movement telemetry. Bootkits may be part of a broader intrusion.

For general ransomware readiness and response guidance, see CISA and partners’ advisories on ransomware best practices: CISA Ransomware Resources.

How HybridPetya Differs From NotPetya

Secure Boot bypass capability. NotPetya primarily hit via supply chain/lateral movement and targeted MBR/MFT. HybridPetya adds a UEFI bootkit angle.
A working decryption flow. Unlike NotPetya’s destructive design, HybridPetya provides a path for decryption after a ransom payment—at least in current samples.
Modern UEFI attack surface. HybridPetya targets the ESP and abuses a specific UEFI app vulnerability (CVE‑2024‑7344), keeping it relevant to current hardware.

In short: the family resemblance is clear, but the tactics reflect today’s platform realities.

What About Home Users and Small Teams?

You don’t need a SOC to get safer:

Keep Windows fully updated. Install firmware updates from your device maker.
Turn on Secure Boot, BitLocker, and virtualization‑based security (VBS) if supported.
Avoid untrusted boot tools, USBs, or “recovery” utilities from unknown sources.
Back up critical files to an offline or immutable location regularly.
If you see repeated CHKDSK messages at boot without explanation, don’t ignore them.

If your PC behaves strangely after an update or crash, reach out to a trusted technician or your OEM support for guidance before continuing to reboot repeatedly.

The Bigger Picture: Secure Boot Bypasses Are Getting Easier to Find

ESET notes HybridPetya is at least the fourth public example of a UEFI bootkit with Secure Boot bypass functionality, joining BlackLotus, BootKitty/LogoFail, and the Hyper‑V Backdoor PoC. That’s a trend, not a blip.

Here’s why that matters:

Offense informs offense. Once techniques are public, others can adapt them.
Fragmented firmware ecosystems slow patch adoption. Mixed fleets with varied OEM/BIOS versions increase exposure windows.
DBX management is still maturing. Many orgs don’t routinely verify revocation lists.

The takeaway is not to panic—but to normalize firmware hygiene as part of your patch cycle and endpoint hardening.

Action Plan You Can Execute This Week

Verify Secure Boot is enabled on all endpoints.
Confirm your estate has received the latest Secure Boot DBX updates and January 2025 Windows updates.
Audit the ESP on a sample of endpoints. Check for unexpected files like cloak.dat or modified bootmgfw.efi.
Ensure BitLocker with TPM integration is enabled and recovery keys are backed up securely.
Update IR runbooks with a “UEFI bootkit suspected” branch, including imaging the ESP and re‑provision steps.
Brief IT operations and help desk. Teach them to escalate odd CHKDSK behavior and unexplained BSOD loops.

It’s not glamorous work, but it’s the stuff that blocks the next wave of boot-level ransomware.

Frequently Asked Questions (FAQ)

Q: What is HybridPetya? A: HybridPetya is a ransomware strain that encrypts the Master File Table (MFT) on NTFS partitions. It uses a UEFI bootkit to run before Windows starts, and some variants bypass Secure Boot using CVE‑2024‑7344. ESET observed samples uploaded to VirusTotal in February 2025. See WeLiveSecurity for related research.

Q: How does HybridPetya bypass UEFI Secure Boot? A: Certain variants misuse a vulnerable UEFI application (Howyar Reloader, reloader.efi). When deployed as the Windows boot manager and paired with a crafted cloak.dat file, the loader can import a malicious UEFI application without proper integrity checks, bypassing Secure Boot. Microsoft has revoked the vulnerable binary via its Secure Boot revocation process. See NVD: CVE‑2024‑7344.

Q: Does Secure Boot still protect me? A: Yes—if it’s enabled and up to date. Secure Boot relies on current revocation lists (DBX) and trusted certificates. If you haven’t applied recent Windows updates and firmware updates, outdated DBX entries may allow vulnerable bootloaders to run. Review UEFI Secure Boot and ensure your devices have the latest revocations.

Q: What’s the difference between encrypting files and encrypting the MFT? A: File encryption locks each file individually. MFT encryption scrambles the index Windows uses to locate files on NTFS volumes. The files may still exist on disk, but the system can’t find or open them. It’s a fast way to make a system unusable.

Q: Is HybridPetya widespread? A: Not at this time. ESET has not seen confirmed in‑the‑wild deployments. That said, the technique is viable, and similar Secure Boot bypasses have been used operationally before (e.g., BlackLotus). Treat this as a chance to get ahead.

Q: Should I pay the ransom if impacted? A: Paying is risky and not recommended by most authorities. Decryption isn’t guaranteed, and payments incentivize attackers. Work with incident response professionals to explore remediation and recovery options. See CISA’s Stop Ransomware resources.

Q: How can I tell if my system is vulnerable to CVE‑2024‑7344? A: Ensure you have installed the latest Windows updates and Secure Boot DBX updates published by Microsoft. If your organization uses the Howyar Reloader component or custom bootloaders, consult your vendor and verify they are not using revoked binaries. The Microsoft Security Update Guide is here: MSRC Update Guide.

Q: What indicators should I monitor? A: Watch for unusual modifications to the ESP, unexpected files like cloak.dat or \EFI\Microsoft\Boot\counter, changes to bootmgfw.efi, unexplained BSOD followed by CHKDSK at boot, and NTFS volumes that become inaccessible. Map detections to MITRE ATT&CK T1542.003.

Q: How do I remove a UEFI bootkit? A: Removal typically requires trusted-boot media, full disk imaging for forensics, wiping or re‑provisioning the ESP and OS, and restoring from clean backups. This is sensitive work—engage experienced IR teams or your OEM. Plan for credential resets and thorough post‑incident validation.

Q: What else should I do to protect against firmware-level threats? A: Keep firmware and OS patched, enforce Secure Boot with up-to-date DBX, enable BitLocker with TPM, restrict third‑party boot components, monitor the ESP, and rehearse incident response that includes pre‑OS persistence. NIST SP 800‑193 offers solid guidance: Platform Firmware Resiliency.

Bottom Line and Next Steps

HybridPetya is a wake‑up call, not a world‑ender. It confirms a trend security teams already suspected: boot‑level ransomware and Secure Boot bypasses are maturing. The good news? You can get ahead of it.

Validate Secure Boot and revocation lists across your fleet.
Patch aggressively—including firmware and DBX updates.
Monitor the EFI System Partition and lock it down.
Add a UEFI bootkit branch to your IR plan.
Practice clean rebuilds and test your backups.

If this was helpful and you want more deep‑dive, actionable security analysis, subscribe for future updates. We’ll keep translating complex threats into clear steps you can take right now to reduce risk.

Discover more at InnoVirtuoso.com

I would love some feedback on my writing so if you have any, please don’t hesitate to leave a comment around here or in any platforms that is convenient for you.

For more on tech and other topics, explore InnoVirtuoso.com anytime. Subscribe to my newsletter and join our growing community—we’ll create something magical together. I promise, it’ll never be boring!

Stay updated with the latest news—subscribe to our newsletter today!

Thank you all—wishing you an amazing day ahead!

HybridPetya Ransomware Bypasses UEFI Secure Boot via CVE‑2024‑7344 — What Security Teams Must Do Now

The Two-Minute Summary: Why HybridPetya Matters

What Is HybridPetya?