ESET Analysis has found HybridPetya, on the VirusTotal pattern sharing platform. It’s a copycat of the notorious Petya/NotPetya malware, including the potential of compromising UEFI-based techniques and weaponizing CVE‑2024‑7344 to bypass UEFI Safe Boot on outdated techniques.
Key factors of this blogpost:
New ransomware samples, which we named HybridPetya, resembling the notorious Petya/NotPetya malware, had been uploaded to VirusTotal in February 2025.
HybridPetya encrypts the Grasp File Desk, which incorporates essential metadata about all of the information on NTFS-formatted partitions.
In contrast to the unique Petya/NotPetya, HybridPetya can compromise trendy UEFI-based techniques by putting in a malicious EFI software onto the EFI System Partition.
One of many analyzed HybridPetya variants exploits CVE‑2024‑7344 to bypass UEFI Safe Boot on outdated techniques, leveraging a specifically crafted cloak.dat file.
ESET telemetry exhibits no indicators of HybridPetya getting used within the wild but; this malware doesn’t exhibit the aggressive community propagation seen within the authentic NotPetya.
Overview
Late in July 2025, we encountered suspicious ransomware samples, uploaded to VirusTotal from Poland, below varied filenames, together with notpetyanew.exe and different related ones, suggesting a reference to the infamously damaging malware that struck Ukraine and lots of different nations again in 2017. The NotPetya assault is believed to be probably the most damaging cyberattack in historical past, with greater than $10 billion in complete damages. Regardless of NotPetya’s similarity to the Petya ransomware, first found in March 2016, NotPetya’s objective was pure destruction, as encryption key restoration from the sufferer’s private set up key was not potential. Due to the shared traits of the presently found samples with each Petya and NotPetya, we named the brand new discovery HybridPetya.
Whereas ESET telemetry exhibits no energetic use of HybridPetya within the wild, one essential element in these samples nonetheless caught our consideration – in contrast to the unique NotPetya (and Petya ransomware as properly), HybridPetya can be able to compromising trendy UEFI-based techniques by putting in a malicious EFI software to the EFI System Partition. The deployed UEFI software is then chargeable for encryption of the NTFS-related Grasp File Desk (MFT) file – an essential metadata file containing details about all of the information on the NTFS-formatted partition.
After a bit extra digging, we found one thing much more attention-grabbing on VirusTotal: an archive containing the entire EFI System Partition contents, together with a really related HybridPetya UEFI software, however this time bundled in a specifically formatted cloak.dat file, weak to CVE‑2024‑7344 – the UEFI Safe Boot bypass vulnerability – that our workforce disclosed in early 2025.
Apparently, regardless of the filenames on VirusTotal and the format of the ransom observe within the present samples suggesting that they is likely to be associated to NotPetya, the algorithm used for the technology of the sufferer’s private set up key, in contrast to within the authentic NotPetya, permits the malware operator to reconstruct the decryption key from the sufferer’s private set up keys. Thus, HybridPetya can function common ransomware (extra like Petya), reasonably than being solely damaging like NotPetya.
Apparently, on September ninth, 2025, @hasherezade printed a put up concerning the existence of a UEFI Petya PoC, with a video demonstrating execution of the malware with UEFI Safe Boot enabled. Although the pattern from the video is clearly completely different from the one introduced on this blogpost (displaying the standard Petya ASCII artwork cranium, which isn’t current within the samples we found), we suspect that there is likely to be some relationship between the 2 circumstances, and that HybridPetya may also be only a proof of idea developed by a safety researcher or an unknown risk actor.
On this blogpost, we concentrate on the technical evaluation of HybridPetya.
HybridPetya technical evaluation
On this part, we offer a technical evaluation of HybridPetya’s elements: the bootkit and its installer. We additionally individually dissect a model of HybridPetya that’s able to bypassing UEFI Safe Boot by exploiting CVE-2024-7344. Word that HybridPetya helps each legacy and UEFI primarily based techniques – on this blogpost, we’ll concentrate on the UEFI half.
Apparently, the code chargeable for producing the victims’ private set up keys appears to be impressed by the RedPetyaOpenSSL PoC. We’re conscious of at the least one different UEFI-compatible PoC rewrite of NotPetya, dubbed NotPetyaAgain, which is written in Rust; nevertheless, that code is unrelated to HybridPetya.
UEFI bootkit
We obtained two distinct variations of the UEFI bootkit element, each very related however with sure variations. When executed, the bootkit first hundreds its configuration from the EFIMicrosoftBootconfig file, and checks the encryption flag indicating the present encryption standing – identical as the unique Petya/NotPetya samples, the encryption flag can have one of many following values:
0 – prepared for encryption,
1 – already encrypted, or
2 – ransom paid, disk decrypted.
It continues with execution primarily based on the encryption standing flag, as proven in Determine 1.
Determine 1. Overview of HybridPetya’s execution logic
If the worth of the encryption flag is 0, the bootkit extracts the 32-byte-long Salsa20 encryption key and 8-byte-long nonce from the configuration knowledge, and subsequently rewrites the configuration file, now with the encryption key zeroed and the encryption flag set to 1. It continues with encryption of the EFIMicrosoftBootverify file with the Salsa20 encryption algorithm utilizing the important thing and nonce from the configuration. Then, earlier than continuing to its predominant performance – disk encryption – it creates the file EFIMicrosoftBootcounter on the EFI System Partition; the aim of this file is defined later.
The disk encryption course of begins with identification of all NTFS-formatted partitions. As proven in Determine 2, the pattern does so by getting the record of handles for linked storage units, figuring out the person partitions by checking that EFI_BLOCK_IO_MEDIA->LogicalPartition is TRUE, and at last verifying whether or not the partition is NTFS formatted by evaluating the primary 4 bytes of the info current within the first partition’s sector with the NTFS signature NTFS.
Determine 2. Hex-Rays decompiled code for NTFS partition identification
As soon as the NTFS partitions have been recognized, the bootkit continues with encryption of the Grasp File Desk (MFT) file, the important metadata file containing details about different information and the situation of their knowledge on the NTFS-formatted partition. As proven in Determine 3, throughout the encryption, the bootkit rewrites the contents of the EFIMicrosoftBootcounter file with the variety of already encrypted disk clusters, and updates the pretend CHKDSK message displayed on the sufferer’s display screen (proven in Determine 4), with the details about the present encryption standing (although, primarily based on the message, the sufferer might imagine that the disk is being checked for errors, not being encrypted).
Determine 3. Hex-Rays decompiled code: MFT encryption
Determine 4. Pretend CHKDSK message proven by HybridPetya throughout disk encryption (similar with NotPetya and Petya)
When accomplished with the encryption, the bootkit reboots the machine.
If the bootkit detects that the disk is already encrypted, that means that the worth of the encryption flag from the configuration file is 1, it exhibits the ransom observe proven in Determine 5 or Determine 6 (relying on the bootkit model), and asks the sufferer to enter the decryption key. Word that whereas the HybridPetya ransom observe has the identical format as that of the unique NotPetya (proven in Determine 7), the ransom quantity, bitcoin handle, and the operator’s e-mail handle are completely different. Additionally, the model deployed with the UEFI Safe Boot bypass makes use of a unique contact e-mail handle (wowsmith999999@proton(.)me) than the model deployed by the obtained installers (wowsmith1234567@proton(.)me). It’s value mentioning that the bitcoin handle is similar in each variations.
Determine 5. Ransom observe from the bootkit put in by the installers with out the UEFI Safe Boot bypass
Determine 6. Ransom observe displayed by the bootkit model deployed by exploiting CVE-2024-7344
Determine 7. Authentic NotPetya ransom observe
When a key with the proper size – 32 characters – is entered and confirmed by the sufferer urgent Enter, the bootkit proceeds to verification of the important thing. As depicted in Determine 8, key validity is established by making an attempt to decrypt the aforementioned EFIMicrosoftBootverify file with the provided key, and checking whether or not the plaintext incorporates solely bytes with worth 0x07. Word that the bootkit variant deployed through the UEFI Safe Boot bypass hashes the provided key with an algorithm most likely primarily based on SPONGENT-256/256/16, utilizing that hash worth because the decryption key, whereas the bootkit deployed by the obtained installers takes the person’s enter as is.
Determine 8. Hex-Rays decompiled code: disk-decryption key validity verification
If the proper key’s entered, the bootkit updates the configuration file with the encryption flag worth set to 2 and likewise fills within the decryption key. Then it reads the contents of the EFIMicrosoftBootcounter file (containing the variety of disk clusters beforehand encrypted) and proceeds with disk decryption. For the decryption, the bootkit proceeds with a really related course of to that of NTFS partition discovery and MFT decryption (the Salsa20 encryption and decryption course of is similar) as described within the Disk encryption part. The decryption stops when the variety of decrypted clusters is the same as the worth from the counter file. In the course of the means of MFT decryption, the bootkit exhibits the present decryption course of standing, depicted in Determine 9, on the sufferer’s display screen.
Determine 9. Decryption standing proven to a sufferer after getting into a legitimate key
Subsequent, the bootkit proceeds with recovering the reliable bootloaders EFIMicrosoftBootbootmgfw.efi and EFIBootbootx64.efi from the backup file beforehand created throughout the set up course of: EFIMicrosoftBootbootmgfw.efi.previous.
Lastly, after the decryption course of is completed and the reliable bootloaders recovered, the bootkit prompts the sufferer to reboot the machine (Determine 10). If all the pieces went properly, the machine ought to begin the working system efficiently after the reboot.
Determine 10. Immediate to reboot sufferer machine after profitable disk decryption
Deploying the UEFI bootkit element
On this part, we concentrate on the bootkit-installation performance of the found HybridPetya installers. Word that the installers we had been in a position to get hold of don’t take UEFI Safe Boot into consideration. Nevertheless, as defined within the CVE-2024-7344 exploitation part, there may be seemingly a variant with such an enchancment.
To determine whether or not the system is UEFI primarily based, the installer retrieves the disk data (IOCTL_DISK_GET_DRIVE_LAYOUT_EX), checks whether or not the GPT partitioning scheme is used (PARTITION_STYLE_GPT), and walks by the partitions till it discovers the one with PARTITION_INFORMATION_GPT.PartitionType set to PARTITION_SYSTEM_GUID, which is the identifier of the EFI System Partition. After discovering the EFI System Partition, it continues:
Eradicating the fallback UEFI bootloader, saved in EFIBootBootx64.efi.
Dropping a disk-encryption-related configuration together with the encryption flag, to the EFIMicrosoftBootconfig file on the EFI System Partition; the encryption configuration incorporates the Salsa20 encryption key, 8-byte nonce, and sufferer’s private set up key (base58-encoded knowledge).
Dropping an encryption-verification array consisting of 0x200 bytes with worth 0x07 to the EFIMicrosoftBootverify file on the EFI System Partition; this array is later encrypted by the bootkit element utilizing the identical Salsa20 key as used for disk encryption. The aim of this array is to confirm whether or not the sufferer entered a legitimate decryption key (by decrypting the array with the entered key, and verifying that the plaintext incorporates an array of bytes with worth 0x07).
Making a backup of EFIMicrosoftBootbootmgfw.efi, the default bootloader for Home windows-based techniques, by copying it into EFIMicrosoftBootbootmgfw.efi.previous.
When accomplished, it triggers a system crash (Blue Display Of Loss of life, BSOD) by utilizing the identical methodology that Petya did – invoking the NtRaiseHardError API with the ErrorStatus parameter set to 0xC0000350 (STATUS_HOST_DOWN) and the ResponseOption set to worth 6 (OptionShutdownSystem), leading to a system shutdown.
The abovementioned adjustments make sure that on techniques with Home windows set as the first OS, the bootkit binary will likely be executed as soon as the machine is powered on once more.
CVE-2024-7344 exploitation
On this part, we look at an archive that we found on VirusTotal that incorporates a variant of the UEFI bootkit described within the UEFI bootkit part, however this time bundled in a specifically formatted cloak.dat file associated to CVE-2024-7344 – the UEFI Safe Boot bypass vulnerability that our workforce publicly disclosed in early 2025.
An inventory of the information current within the archive together with their contents means that this EFI System Partition was copied from a system already encrypted by this Petya/NotPetya copycat variant. Word that we haven’t obtained the installer chargeable for deploying this model with the UEFI Safe Boot bypass, however primarily based on the archive’s contents, that are proven in Determine 11, it will be fairly just like the method described within the earlier part. Particularly, the archive incorporates:
EFIMicrosoftBootcounter, a file already containing a non-zero worth representing the variety of disk clusters beforehand encrypted by the bootkit,
EFIMicrosoftBootconfig, a file with the encryption flag worth set to 1, that means that the disk must be already encrypted and the bootkit ought to proceed with displaying the ransom observe,
EFIMicrosoftBootbootmgfw.efi.previous, a file with the primary 0x400 bytes XORed with the worth 0x07,
EFIMicrosoftBootbootmgfw.efi, a reliable, however weak (CVE‑2024‑7344) UEFI software signed by Microsoft (revoked in Microsoft’s dbx since January 2025); on this part we’ll discuss with this file with its authentic title reloader.efi, and
EFIMicrosoftBootcloak.dat, a specifically crafted file loadable by reloader.efi and containing the XORed bootkit binary.
Determine 11. Archive containing the CVE-2024-7344-exploiting model of the bootkit
As described in our report from January 2025, the exploit mechanism is kind of easy. The cloak.dat file incorporates specifically formatted knowledge that incorporates a UEFI software. When the reloader.efi binary (deployed as bootmgfw.efi) is executed throughout boot, it searches for the presence of the cloak.dat file on the EFI System Partition, and hundreds the embedded UEFI software from the file in a really unsafe means, utterly ignoring any integrity checks, thus bypassing UEFI Safe Boot.
Word that our blogpost from January 2025 didn’t clarify the exploitation in superb element; thus, the malware creator most likely reconstructed the proper cloak.dat file format primarily based on reverse engineering the weak software on their very own.
The vulnerability can’t be exploited on techniques with Microsoft’s January 2025 dbx replace utilized. For steerage on how one can shield and confirm whether or not your system is uncovered to this vulnerability, verify the Safety and Detection part of our January 2025 blogpost.
Conclusion
HybridPetya is now at the least the fourth publicly identified instance of an actual or proof-of-concept UEFI bootkit with UEFI Safe Boot bypass performance, becoming a member of BlackLotus (exploiting CVE‑2022‑21894), BootKitty (exploiting LogoFail), and the Hyper-V Backdoor PoC (exploiting CVE‑2020‑26200). This exhibits that Safe Boot bypasses usually are not simply potential – they’re changing into extra frequent and engaging to each researchers and attackers.
Though HybridPetya just isn’t actively spreading, its technical capabilities – particularly MFT encryption, UEFI system compatibility, and Safe Boot bypass – make it noteworthy for future risk monitoring.
For any inquiries about our analysis printed on WeLiveSecurity, please contact us at threatintel@eset.com.
ESET Analysis gives non-public APT intelligence stories and knowledge feeds. For any inquiries about this service, go to the ESET Risk Intelligence web page.
IoCs
A complete record of indicators of compromise (IoCs) and samples could be present in our GitHub repository.
Recordsdata
SHA-1
Filename
Detection
Description
BD35908D5A5E9F7E41A61B7AB598AB9A88DB723D
bootmgfw.efi
EFI/Diskcoder.A
HybridPetya – UEFI bootkit element.
9DF922D00171AA3C31B75446D700EE567F8D787B
N/A
EFI/Diskcoder.A
HybridPetya – UEFI bootkit element, extracted from cloak.dat.
9B0EE05FFFDA0B16CF9DAAC587CB92BB06D3981B
N/A
Win32/Injector.AJBK
HybridPetya installer.
CDC8CB3D211589202B49A48618B0D90C4D8F86FD
core.dll
Win32/Filecoder.OSK
HybridPetya installer.
D31F86BA572904192D7476CA376686E76E103D28
f20000.mbam_update.exe
Win32/Filecoder.OSK
HybridPetya installer.
A6EBFA062270A321241439E8DF72664CD54EA1BC
improved_notpetyanew.exe
Win32/Kryptik.BFRR
HybridPetya installer.
C8E3F1BF0B67C83D2A6D9E594DE8067F0378E6C5
notpetya_new.exe
Win32/Kryptik.BFRR
HybridPetya installer.
C7C270F9D3AE80EC5E8926A3CD1FB5C9D208F1DC
notpetyanew.exe
Win32/Kryptik.BFRR
HybridPetya installer.
3393A8C258239D6802553FD1CCE397E18FA285A1
notpetyanew_improved_final.exe
Win32/Kryptik.BFRR
HybridPetya installer.
98C3E659A903E74D2EE398464D3A5109E92BD9A9
bootmgfw.efi
N/A
UEFI software weak to CVE-2024-7433.
D0BD283133A80B47137562F2AAAB740FA15E6441
cloak.dat
EFI/Diskcoder.A
Specifically formatted cloak.dat associated to CVE-2024-7433, incorporates XORed HybridPetya UEFI bootkit element.
MITRE ATT&CK methods
This desk was constructed utilizing model 17 of the MITRE ATT&CK framework.
Tactic
ID
Title
Description
Useful resource Improvement
T1587.001
Develop Capabilities: Malware
HybridPetya is new ransomware with UEFI compatibility and a UEFI bootkit element developed by unknown authors.
T1587.004
Develop Capabilities: Exploits
HybridPetya’s authors developed an exploit for the CVE‑2024‑7344 UEFI Safe Boot bypass vulnerability.
Execution
T1203
Exploitation for Consumer Execution
HybridPetya exploits CVE‑2024‑7344 to execute an unsigned UEFI bootkit on outdated techniques with UEFI Safe Boot enabled.
T1106
Native API
HybridPetya installers use undocumented native API NtRaiseHardError to trigger a system crash after the bootkit’s set up.
Persistence
T1542.003
Pre-OS Boot: Bootkit
HybridPetya persists utilizing the bootkit element. It helps each legacy and UEFI techniques.
T1574
Hijack Execution Stream
HybridPetya installers hijack the common system boot course of by changing the reliable Home windows bootloader with a malicious one.
Privilege Escalation
T1068
Exploitation for Privilege Escalation
HybridPetya exploits CVE‑2024‑7344 to bypass UEFI Safe Boot and execute the malicious UEFI bootkit with excessive privileges throughout bootup.
Protection Evasion
T1211
Exploitation for Protection Evasion
HybridPetya exploits CVE‑2024‑7344 to bypass UEFI Safe Boot.
T1620
Reflective Code Loading
HybridPetya installers use the reflective DLL loading approach.
T1036
Masquerading
The HybridPetya bootkit shows pretend CHKDSK messages on the display screen throughout disk encryption to masks its malicious exercise.
Affect
T1486
Information Encrypted for Affect
The HybridPetya installer encrypts information with specified extensions and the bootkit element encrypts MFT file on every NTFS-formatted partition.
T1529
System Shutdown/Reboot
HybridPetya reboots the machine after MFT encryption.
