ESET Analysis has found HybridPetya, on the VirusTotal pattern sharing platform. It’s a copycat of the notorious Petya\/NotPetya malware, including the aptitude of compromising UEFI-based programs and weaponizing CVE\u20112024\u20117344<\/a> to bypass UEFI Safe Boot on outdated programs.<\/p>\n

\n
Key factors of this blogpost:<\/strong><\/p>\n
\n
New ransomware samples, which we named HybridPetya, resembling the notorious Petya\/NotPetya malware, have been uploaded to VirusTotal in February 2025.<\/li>\n
HybridPetya encrypts the Grasp File Desk, which incorporates necessary metadata about all of the information on NTFS-formatted partitions.<\/li>\n
Not like the unique Petya\/NotPetya, HybridPetya can compromise fashionable UEFI-based programs by putting in a malicious EFI utility onto the EFI System Partition.<\/li>\n
One of many analyzed HybridPetya variants exploits CVE\u20112024\u20117344 to bypass UEFI Safe Boot on outdated programs, leveraging a specifically crafted cloak.dat<\/span> file.<\/li>\n
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 unique NotPetya.<\/li>\n<\/ul>\n<\/blockquote>\n
Overview<\/h2>\n
Late in July 2025, we encountered suspicious ransomware samples, uploaded to VirusTotal from Poland, beneath numerous filenames, together with notpetyanew.exe<\/span> and different comparable ones, suggesting a reference to the infamously damaging malware that struck Ukraine and lots of different nations again in 2017<\/a>. The NotPetya assault is believed to be probably the most damaging cyberattack in historical past, with greater than $10 billion in whole damages<\/a>. Regardless of NotPetya\u2019s similarity to the Petya ransomware, first found in March 2016<\/a>, NotPetya\u2019s goal was pure destruction, as encryption key restoration from the sufferer\u2019s private set up key was not doable. Due to the shared traits of the at the moment found samples with each Petya and NotPetya, we named the brand new discovery HybridPetya.<\/p>\n
Whereas ESET telemetry exhibits no lively use of HybridPetya within the wild, one necessary element in these samples nonetheless caught our consideration \u2013 not like the unique NotPetya (and Petya ransomware as effectively), HybridPetya can also be able to compromising fashionable UEFI-based programs by putting in a malicious EFI utility to the EFI System Partition. The deployed UEFI utility is then answerable for encryption of the NTFS<\/a>-related Grasp File Desk<\/a> (MFT) file \u2013 an necessary metadata file containing details about all of the information on the NTFS-formatted partition.<\/p>\n
After a bit extra digging, we found one thing much more fascinating on VirusTotal: an archive<\/a> containing the entire EFI System Partition contents, together with a really comparable HybridPetya UEFI utility, however this time bundled in a specifically formatted cloak.dat<\/span> file, susceptible to CVE\u20112024\u20117344 \u2013 the UEFI Safe Boot bypass vulnerability<\/a> \u2013 that our staff disclosed in early 2025.<\/p>\n
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\u2019s private set up key, not like within the unique NotPetya, permits the malware operator to reconstruct the decryption key from the sufferer\u2019s private set up keys. Thus, HybridPetya can function common ransomware (extra like Petya), reasonably than being solely damaging like NotPetya.<\/p>\n
Apparently, on September 9^{th<\/sup>, 2025,}@hasherezade<\/a> revealed a put up<\/a> concerning the existence of a UEFI Petya PoC, with a video demonstrating execution of the malware with UEFI Safe Boot enabled. Despite the fact that the pattern from the video is clearly totally different from the one offered on this blogpost (displaying the everyday 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 menace actor.<\/p>\n
On this blogpost, we deal with the technical evaluation of HybridPetya.<\/p>\n
HybridPetya technical evaluation<\/h2>\n
On this part, we offer a technical evaluation of HybridPetya\u2019s parts: 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. Observe that HybridPetya helps each legacy and UEFI based mostly programs \u2013 on this blogpost, we\u2019ll deal with the UEFI half.<\/p>\n
Apparently, the code answerable for producing the victims\u2019 private set up keys appears to be impressed by the RedPetyaOpenSSL<\/a> PoC. We’re conscious of not less than one different UEFI-compatible PoC rewrite of NotPetya, dubbed NotPetyaAgain<\/a>, which is written in Rust<\/a>; nevertheless, that code is unrelated to HybridPetya.<\/p>\n
UEFI bootkit <\/h3>\n
We obtained two distinct variations of the UEFI bootkit part, each very comparable however with sure variations. When executed, the bootkit first hundreds its configuration from the EFIMicrosoftBootconfig<\/span> file, and checks the encryption flag indicating the present encryption standing \u2013 identical as the unique Petya\/NotPetya samples, the encryption flag can have one of many following values:<\/p>\n
\n
0 – <\/span>prepared for encryption,<\/li>\n
1 – <\/span>already encrypted, or<\/li>\n
2 – <\/span>ransom paid, disk decrypted.<\/li>\n<\/ul>\n
It continues with execution based mostly on the encryption standing flag, as proven in Determine 1.<\/p>\n
$\"Figure$
Determine 1. Overview of HybridPetya\u2019s execution logic<\/em><\/figcaption><\/figure>\nDisk encryption <\/h4>\n
If the worth of the encryption flag is 0<\/span>, the bootkit extracts the 32-byte-long Salsa20<\/a> 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<\/span>. It continues with encryption of the EFIMicrosoftBootverify<\/span> file with the Salsa20 encryption algorithm utilizing the important thing and nonce from the configuration. Then, earlier than continuing to its predominant performance \u2013 disk encryption \u2013 it creates the file EFIMicrosoftBootcounter<\/span> on the EFI System Partition; the aim of this file is defined later.<\/p>\n
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 listing of handles for related storage gadgets, figuring out the person partitions by checking that EFI_BLOCK_IO_MEDIA->LogicalPartition<\/span> is TRUE<\/span>, and eventually verifying whether or not the partition is NTFS formatted by evaluating the primary 4 bytes of the info current within the first partition\u2019s sector with the NTFS signature NTFS<\/span>.<\/p>\n
$\"Figure$
Determine 2. Hex-Rays decompiled code for NTFS partition identification<\/em><\/figcaption><\/figure>\nAs soon as the NTFS partitions have been recognized, the bootkit continues with encryption of the Grasp File Desk<\/a> (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, through the encryption, the bootkit rewrites the contents of the EFIMicrosoftBootcounter<\/span> file with the variety of already encrypted disk clusters, and updates the faux CHKDSK message displayed on the sufferer\u2019s display screen (proven in Determine 4), with the details about the present encryption standing (although, based mostly on the message, the sufferer could consider that the disk is being checked for errors, not being encrypted).<\/p>\n
$\"Figure$
Determine 3. Hex-Rays decompiled code: MFT encryption<\/em><\/figcaption><\/figure>\n $\"Figure$
Determine 4. Pretend CHKDSK message proven by HybridPetya throughout disk encryption (similar with NotPetya and Petya)<\/em><\/figcaption><\/figure>\n
When achieved with the encryption, the bootkit reboots the machine.<\/p>\n
Disk decryption <\/h4>\n
If the bootkit detects that the disk is already encrypted, which means that the worth of the encryption flag from the configuration file is 1<\/span>, 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. Observe that whereas the HybridPetya ransom observe has the identical format as that of the unique NotPetya (proven in Determine 7), the ransom quantity, bitcoin deal with, and the operator\u2019s e mail deal with are totally different. Additionally, the model deployed with the UEFI Safe Boot bypass makes use of a special contact e mail deal with (wowsmith999999@proton[.]me<\/span>) than the model deployed by the obtained installers (wowsmith1234567@proton[.]me<\/span>). It\u2019s price mentioning that the bitcoin deal with is similar in each variations.<\/p>\n
$\"Figure$
Determine 5. Ransom observe from the bootkit put in by the installers with out the UEFI Safe Boot bypass<\/em><\/figcaption><\/figure>\n $\"Figure$
Determine 6. Ransom observe displayed by the bootkit model deployed by exploiting CVE-2024-7344<\/em><\/figcaption><\/figure>\n $\"Figure$
Determine 7. Authentic NotPetya ransom observe<\/em><\/figcaption><\/figure>\nWhen a key with the proper size \u2013 32 characters \u2013 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<\/span> file with the provided key, and checking whether or not the plaintext incorporates solely bytes with worth 0x07<\/span>. Observe that the bootkit variant deployed by way of the UEFI Safe Boot bypass hashes the provided key with an algorithm most likely based mostly on SPONGENT-256\/256\/16<\/a>, utilizing that hash worth because the decryption key, whereas the bootkit deployed by the obtained installers takes the consumer\u2019s enter as is.<\/p>\n
$\"Figure$
Determine 8. Hex-Rays decompiled code: disk-decryption key validity verification<\/em><\/figcaption><\/figure>\nIf the proper secret is entered, the bootkit updates the configuration file with the encryption flag worth set to 2 and in addition fills within the decryption key. Then it reads the contents of the EFIMicrosoftBootcounter<\/span> file (containing the variety of disk clusters beforehand encrypted) and proceeds with disk decryption. For the decryption, the bootkit proceeds with a really comparable 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<\/a><\/em> part. The decryption stops when the variety of decrypted clusters is the same as the worth from the counter<\/span> file. Through the means of MFT decryption, the bootkit exhibits the present decryption course of standing, depicted in Determine 9, on the sufferer\u2019s display screen.<\/p>\n
$\"Figure$
Determine 9. Decryption standing proven to a sufferer after coming into a legitimate key<\/em><\/figcaption><\/figure>\n
Subsequent, the bootkit proceeds with recovering the authentic bootloaders EFIMicrosoftBootbootmgfw.efi<\/span> and EFIBootbootx64.efi<\/span> from the backup file beforehand created through the set up course of: EFIMicrosoftBootbootmgfw.efi.previous<\/span>.<\/p>\n
Lastly, after the decryption course of is completed and the authentic bootloaders recovered, the bootkit prompts the sufferer to reboot the system (Determine 10). If every thing went effectively, the system ought to begin the working system efficiently after the reboot.<\/p>\n
$\"Figure$
Determine 10. Immediate to reboot sufferer system after profitable disk decryption<\/em><\/figcaption><\/figure>\nDeploying the UEFI bootkit part<\/h3>\n
On this part, we deal with the bootkit-installation performance of the found HybridPetya installers. Observe that the installers we have been capable of receive don’t take UEFI Safe Boot into consideration. Nevertheless, as defined within the CVE-2024-7344 exploitation<\/a><\/em> part, there may be possible a variant with such an enchancment.<\/p>\n
To resolve whether or not the system is UEFI based mostly, the installer retrieves the disk info (IOCTL_DISK_GET_DRIVE_LAYOUT_EX<\/span>), checks whether or not the GPT partitioning scheme is used (PARTITION_STYLE_GPT<\/span>), and walks by way of the partitions till it discovers the one with PARTITION_INFORMATION_GPT.PartitionType<\/span> set to PARTITION_SYSTEM_GUID<\/a>, which is the identifier of the EFI System Partition. After discovering the EFI System Partition, it continues:<\/p>\n
\n
Eradicating the fallback UEFI bootloader, saved in EFIBootBootx64.efi<\/span>.<\/li>\n
Dropping a disk-encryption-related configuration together with the encryption flag, to the EFIMicrosoftBootconfig<\/span> file on the EFI System Partition; the encryption configuration incorporates the Salsa20 encryption key, 8-byte nonce, and sufferer\u2019s private set up key (base58-encoded<\/a> knowledge).<\/li>\n
Dropping an encryption-verification array consisting of 0x200<\/span> bytes with worth 0x07<\/span> to the EFIMicrosoftBootverify<\/span> file on the EFI System Partition; this array is later encrypted by the bootkit part 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<\/span>).<\/li>\n
Making a backup of EFIMicrosoftBootbootmgfw.efi<\/span>, the default bootloader for Home windows-based programs, by copying it into EFIMicrosoftBootbootmgfw.efi.previous<\/span>.<\/li>\n<\/ul>\n
When achieved, it triggers a system crash (Blue Display screen Of Demise, BSOD) by utilizing the identical technique that Petya did \u2013 invoking the NtRaiseHardError<\/span> API with the ErrorStatus<\/span> parameter set to 0xC0000350<\/span> (STATUS_HOST_DOWN<\/span>) and the ResponseOption<\/span> set to worth 6<\/span> (OptionShutdownSystem<\/span>), leading to a system shutdown.<\/p>\n
The abovementioned adjustments make sure that on programs with Home windows set as the first OS, the bootkit binary might be executed as soon as the system is powered on once more.<\/p>\n
CVE-2024-7344 exploitation <\/h3>\n
On this part, we study an archive<\/a> that we found on VirusTotal that incorporates a variant of the UEFI bootkit described within the UEFI bootkit<\/a><\/em> part, however this time bundled in a specifically formatted cloak.dat<\/span> file associated to CVE-2024-7344 \u2013 the UEFI Safe Boot bypass vulnerability<\/a> that our staff publicly disclosed in early 2025.<\/p>\n
A listing 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. Observe that we haven\u2019t obtained the installer answerable for deploying this model with the UEFI Safe Boot bypass, however based mostly on the archive\u2019s contents, that are proven in Determine 11, it will be fairly just like the method described within the earlier part. Particularly, the archive incorporates:<\/p>\n
\n
EFIMicrosoftBootcounter<\/span>, a file already containing a non-zero worth representing the variety of disk clusters beforehand encrypted by the bootkit,<\/li>\n
EFIMicrosoftBootconfig<\/span>, a file with the encryption flag worth set to 1<\/span>, which means that the disk ought to be already encrypted and the bootkit ought to proceed with displaying the ransom observe,<\/li>\n
EFIMicrosoftBootbootmgfw.efi.previous<\/span>, a file with the primary 0x400<\/span> bytes XORed with the worth 0x07<\/span>,<\/li>\n
EFIMicrosoftBootbootmgfw.efi<\/span>, a authentic, however susceptible (CVE\u20112024\u20117344) UEFI utility signed by Microsoft (revoked in Microsoft\u2019s dbx since January 2025<\/a>); on this part we\u2019ll seek advice from this file with its unique title reloader.efi<\/span>, and<\/li>\n
EFIMicrosoftBootcloak.dat<\/span>, a specifically crafted file loadable by way of reloader.efi<\/span> and containing the XORed bootkit binary.<\/li>\n<\/ul>\n
$\"Figure$
Determine 11. Archive containing the CVE-2024-7344-exploiting model of the bootkit<\/em><\/figcaption><\/figure>\nAs described in our report<\/a> from January 2025, the exploit mechanism is kind of easy. The cloak.dat<\/span> file incorporates specifically formatted knowledge that incorporates a UEFI utility. When the reloader.efi<\/span> binary (deployed as bootmgfw.efi<\/span>) is executed throughout boot, it searches for the presence of the cloak.dat<\/span> file on the EFI System Partition, and hundreds the embedded UEFI utility from the file in a really unsafe method, fully ignoring any integrity checks, thus bypassing UEFI Safe Boot.<\/p>\n
Observe that our blogpost from January 2025 didn\u2019t clarify the exploitation in high quality element; thus, the malware writer most likely reconstructed the proper cloak.dat<\/span> file format based mostly on reverse engineering the susceptible utility on their very own.<\/p>\n
The vulnerability can’t be exploited on programs with Microsoft\u2019s January 2025<\/a> dbx replace utilized. For steerage on learn how to defend and confirm whether or not your system is uncovered to this vulnerability, examine the Safety and Detection<\/a><\/em> part of our January 2025 blogpost.<\/p>\n
Conclusion<\/h2>\n
HybridPetya is now not less than the fourth publicly recognized instance of an actual or proof-of-concept UEFI bootkit with UEFI Safe Boot bypass performance, becoming a member of BlackLotus<\/a> (exploiting CVE\u20112022\u201121894), BootKitty<\/a> (exploiting LogoFail<\/a>), and the Hyper-V Backdoor PoC<\/a> (exploiting CVE\u20112020\u201126200<\/a>). This exhibits that Safe Boot bypasses aren’t simply doable \u2013 they\u2019re changing into extra frequent and engaging to each researchers and attackers.<\/p>\n
Though HybridPetya will not be actively spreading, its technical capabilities \u2013 particularly MFT encryption, UEFI system compatibility, and Safe Boot bypass \u2013 make it noteworthy for future menace monitoring.<\/p>\n
\n
For any inquiries about our analysis revealed on WeLiveSecurity, please contact us at threatintel@eset.com<\/a>.<\/em><\/div>\n
ESET Analysis provides non-public APT intelligence studies and knowledge feeds. For any inquiries about this service, go to the ESET Risk Intelligence<\/a> web page.<\/em><\/div>\n<\/blockquote>\n
IoCs<\/h2>\n
A complete listing of indicators of compromise (IoCs) and samples will be present in our GitHub repository<\/a>.<\/p>\n
Recordsdata<\/h3>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
SHA-1<\/strong><\/td>\n Filename<\/strong><\/td>\n Detection<\/strong><\/td>\n Description<\/strong><\/td>\n<\/tr>\n<\/thead>\n
BD35908D5A5E9F7E41A61B7AB598AB9A88DB723D<\/span><\/td>\n bootmgfw.efi<\/span><\/td>\n EFI\/Diskcoder.A<\/td>\n HybridPetya – UEFI bootkit part.<\/td>\n<\/tr>\n
9DF922D00171AA3C31B75446D700EE567F8D787B<\/span><\/td>\n N\/A<\/td>\n EFI\/Diskcoder.A<\/td>\n HybridPetya – UEFI bootkit part, extracted from cloak.dat<\/span>.<\/td>\n<\/tr>\n
9B0EE05FFFDA0B16CF9DAAC587CB92BB06D3981B<\/span><\/td>\n N\/A<\/td>\n Win32\/Injector.AJBK<\/td>\n HybridPetya installer.<\/td>\n<\/tr>\n
CDC8CB3D211589202B49A48618B0D90C4D8F86FD<\/span><\/td>\n core.dll<\/span><\/td>\n Win32\/Filecoder.OSK<\/td>\n HybridPetya installer.<\/td>\n<\/tr>\n
D31F86BA572904192D7476CA376686E76E103D28<\/span><\/td>\n f20000.mbam_update.exe<\/span><\/td>\n Win32\/Filecoder.OSK<\/td>\n HybridPetya installer.<\/td>\n<\/tr>\n
A6EBFA062270A321241439E8DF72664CD54EA1BC<\/span><\/td>\n improved_notpetyanew.exe<\/span><\/td>\n Win32\/Kryptik.BFRR<\/td>\n HybridPetya installer.<\/td>\n<\/tr>\n
C8E3F1BF0B67C83D2A6D9E594DE8067F0378E6C5<\/span><\/td>\n notpetya_new.exe<\/span><\/td>\n Win32\/Kryptik.BFRR<\/td>\n HybridPetya installer.<\/td>\n<\/tr>\n
C7C270F9D3AE80EC5E8926A3CD1FB5C9D208F1DC<\/span><\/td>\n notpetyanew.exe<\/span><\/td>\n Win32\/Kryptik.BFRR<\/td>\n HybridPetya installer.<\/td>\n<\/tr>\n
3393A8C258239D6802553FD1CCE397E18FA285A1<\/span><\/td>\n notpetyanew_improved_final.exe<\/span><\/td>\n Win32\/Kryptik.BFRR<\/td>\n HybridPetya installer.<\/td>\n<\/tr>\n
98C3E659A903E74D2EE398464D3A5109E92BD9A9<\/span><\/td>\n bootmgfw.efi<\/span><\/td>\n N\/A<\/td>\n UEFI utility susceptible to CVE-2024-7433.<\/td>\n<\/tr>\n
D0BD283133A80B47137562F2AAAB740FA15E6441<\/span><\/td>\n cloak.dat<\/span><\/td>\n EFI\/Diskcoder.A<\/td>\n Specifically formatted cloak.dat<\/span> associated to CVE-2024-7433, incorporates XORed HybridPetya UEFI bootkit part.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
MITRE ATT&CK strategies<\/h2>\n
This desk was constructed utilizing model 17<\/a> of the MITRE ATT&CK framework.<\/strong><\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Tactic<\/strong><\/td>\n ID<\/strong><\/td>\n Identify<\/strong><\/td>\n Description<\/strong><\/td>\n<\/tr>\n<\/thead>\n
Useful resource Improvement<\/strong><\/td>\n T1587.001<\/a><\/td>\n Develop Capabilities: Malware<\/td>\n HybridPetya is new ransomware with UEFI compatibility and a UEFI bootkit part developed by unknown authors.<\/td>\n<\/tr>\n
T1587.004<\/a><\/td>\n Develop Capabilities: Exploits<\/td>\n HybridPetya\u2019s authors developed an exploit for the CVE\u20112024\u20117344 UEFI Safe Boot bypass vulnerability.<\/td>\n<\/tr>\n
Execution<\/strong><\/td>\n T1203<\/a><\/td>\n Exploitation for Consumer Execution<\/td>\n HybridPetya exploits CVE\u20112024\u20117344 to execute an unsigned UEFI bootkit on outdated programs with UEFI Safe Boot enabled.<\/td>\n<\/tr>\n
T1106<\/a><\/td>\n Native API<\/td>\n HybridPetya installers use undocumented native API NtRaiseHardError<\/span> to trigger a system crash after the bootkit\u2019s set up.<\/td>\n<\/tr>\n
Persistence<\/strong><\/td>\n T1542.003<\/a><\/td>\n Pre-OS Boot: Bootkit<\/td>\n HybridPetya persists utilizing the bootkit part. It helps each legacy and UEFI programs.<\/td>\n<\/tr>\n
T1574<\/a><\/td>\n Hijack Execution Stream<\/td>\n HybridPetya installers hijack the common system boot course of by changing the authentic Home windows bootloader with a malicious one.<\/td>\n<\/tr>\n
Privilege Escalation<\/strong><\/td>\n T1068<\/a><\/td>\n Exploitation for Privilege Escalation<\/td>\n HybridPetya exploits CVE\u20112024\u20117344 to bypass UEFI Safe Boot and execute the malicious UEFI bootkit with excessive privileges throughout bootup.<\/td>\n<\/tr>\n
Protection Evasion<\/strong><\/td>\n T1211<\/a><\/td>\n Exploitation for Protection Evasion<\/td>\n HybridPetya exploits CVE\u20112024\u20117344 to bypass UEFI Safe Boot.<\/td>\n<\/tr>\n
T1620<\/a><\/td>\n Reflective Code Loading<\/td>\n HybridPetya installers use the reflective DLL loading approach.<\/td>\n<\/tr>\n
T1036<\/a><\/td>\n Masquerading<\/td>\n The HybridPetya bootkit shows faux CHKDSK messages on the display screen throughout disk encryption to masks its malicious exercise.<\/td>\n<\/tr>\n
Influence<\/strong><\/td>\n T1486<\/a><\/td>\n Information Encrypted for Influence<\/td>\n The HybridPetya installer encrypts information with specified extensions and the bootkit part encrypts MFT file on every NTFS-formatted partition.<\/td>\n<\/tr>\n
T1529<\/a><\/td>\n System Shutdown\/Reboot<\/td>\n HybridPetya reboots the system after MFT encryption.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
$\"\"$ <\/a><\/p>\n<\/div>\n\n","protected":false},"excerpt":{"rendered":"
ESET Analysis has found HybridPetya, on the VirusTotal pattern sharing platform. It’s a copycat of the notorious Petya\/NotPetya malware, including the aptitude of compromising UEFI-based programs and weaponizing CVE\u20112024\u20117344 to bypass UEFI Safe Boot on outdated programs. Key factors of this blogpost: New ransomware samples, which we named HybridPetya, resembling the notorious Petya\/NotPetya malware, have […]<\/p>\n","protected":false},"author":2,"featured_media":6625,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[58],"tags":[4624,210,5325,5324,282,5326],"class_list":["post-6623","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cybersecurity","tag-boot","tag-bypass","tag-copycat","tag-petyanotpetya","tag-secure","tag-uefi"],"_links":{"self":[{"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=\/wp\/v2\/posts\/6623","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=6623"}],"version-history":[{"count":1,"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=\/wp\/v2\/posts\/6623\/revisions"}],"predecessor-version":[{"id":6624,"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=\/wp\/v2\/posts\/6623\/revisions\/6624"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=\/wp\/v2\/media\/6625"}],"wp:attachment":[{"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=6623"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=6623"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=6623"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}

IoCs<\/h2>\nA complete listing of indicators of compromise (IoCs) and samples will be present in our GitHub repository<\/a>.<\/p>\n

IoCs<\/h2>\n
A complete listing of indicators of compromise (IoCs) and samples will be present in our GitHub repository<\/a>.<\/p>\n