Continuing the theme of analyzing the different ransomware variants, this blog is dedicated to the analysis of Petya that’s introduced a very interesting new technique that’s made it very difficult to detect. This analysis resulted in the identification of a new behavior that we’ve since coded into our Dynamic Behavior Tracking (DBT) engine to ensure we can prevent not only Petya, but any future variant that attempts to use this same technique.
Here’s the sample that we analyzed:
SHA1 |
0107fda3977982491958d7268690817e754d76f9 |
SHA256 |
d8ae5cf8862701b80a0af300f0f35f7e4962f942b9d89a38fb639dcee524335d |
MD5 |
cbaf959a8f427efd0bcc1a97d839cbc6 |
Packer |
VmProtect |
Propagation
Most Ransomware today is spread through common spearphishing emails tied to fairly extensive social engineering. We’ve all heard or read the post-mortem briefs – an email is received with an embedded URL link or an attached document that often utilizes tools such as Microsoft macros to drop and execute the malicious code on the endpoint. In this case Petya did not buck the trend, with maybe one exception in that the initial attacks observed used Dropbox to deliver the Microsoft Word document directly to the endpoint.
Once executed, however, Petya follows a very different approach compared to more “traditional” ransomware samples. These traditional samples typically run through a somewhat laborious process of encrypting files one by one while consuming a decent amount of time and resources that make the process easier to detect. In the case of Petya it attacks low level structures on the disk in two very distinct stages that reduce resource overhead. This efficiency accelerates Petya’s execution speed.
Stage one:
Before executing its main stage, Petya first requires Administrator privilege. It begins this process by launching a UAC request and hoping a less sophisticated target will click ‘yes’.
Prompt UAC
Next, it infects the Master Boot Record (MBR) and reboots the system. Since Petya encrypts the MBR code (extremely small 512 bytes) followed by a RESET (triggering interrupt using the NtRaiseHardFault), the initial process takes only few seconds (possibly due to the small data size) as opposed to the minutes observed in traditional ransomware samples (which gives protection software better opportunity at least to try and block operations).
Stage two:
After the RESET, Petya displays fake CHKDISK screen allegedly impersonating the genuine disk repair utility. This process takes 1.5-2 minutes in which Petya encrypts the NTFS MFT. This is the most critical stage of the overall Petya attack. As opposed to encrypting the entire data set, Petya encrypts the MFT which is the index (pointer) to the actual files. This process is very efficient and fast.
Petya’s Efficiency
Traditionally, when the encryption process takes place during the ransomware attack it uses CPU resources and intensive IO (Disk operation) to read / write every file and then encrypt it.
Windows uses modern file system (NTFS). Every file on an NTFS volume is linked to a record in a special file called master file table (MFT). Petya is encrypting this table ensuring it won’t be usable without decrypting it first, resulting in data being completely encrypted. In other words, unless the Petya authors have bugs in their encryption implementation, the user will be hopeless without paying the ransom. MFT was designed to accelerate file access since it keeps pointers to their physical presence on the hard drive.
Analyzing Petya
The Petya sample is packed and needs to be unpacked in order to follow its trail of execution.
For that purpose, use of a low level debugger is needed.
If you’re using windows 64bit, all 32bit debuggers will fail to analyze Petya due to the known WoW64 limitation which limits 32bit debuggers analyzing 64bit code.
Heaven’s Gate, translation from 32bit to 64bit where 32bit debuggers will fail
Modifies the MBR
(Stage 1) Hard reset using NtRaiseHardError will force the computer to reboot itself
(Stage 2) Fake Chkdisk in action (This is where the MFT is encrypted)
Warning Banner
Ransom Request
Conclusion:
Petya represents a significant step forward in the advancement of ransomware. The authors clearly took a different, more efficient approach. Instead of encrypting the victims entire hard drive and files, the authors decided to alter the master boot record and infect the NTFS MFT. This requires a much deeper, low level analysis on the part of researchers in order to understand. In the end, Petya provides a very fast encryption process that takes no more than 2 minutes in total duration to complete, with the first stage executed in mere seconds.
In analyzing this new variant our focus is on interrupting the initial infection of the MBR. By detecting and preventing use of this tactic in the first stage a victim’s files can be saved.
For more information on how SentinelOne can protect from attacks such as these, download our free whitepaper: The Rise of Ransomware & How to Defend Against It and visit our Products Page.
