Reversing Petya – Latest Ransomware Variant

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’.
Picture1

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.

Picture2

 

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.

Picture3

Heaven’s Gate, translation from 32bit to 64bit where 32bit debuggers will fail

 

Picture4

Modifies the MBR

 

Picture5

(Stage 1) Hard reset using NtRaiseHardError will force the computer to reboot itself

 

Picture6

 

(Stage 2) Fake Chkdisk in action (This is where the MFT is encrypted)

 

Picture7

Warning Banner

Picture8

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.