Petya Ransomware X-Rayed !!!

In these days we have seen the new evolution of the Crypto-Malware with the appearance of Petya Ransomware.

In these days we have seen the new evolution of the Crypto-Malware with low level disk cipher by Petya Ransomware.
The Petya was detected on the 24th of March by German researchers of GData.

TG Soft's C.R.A.M. has already analyzed this new type of Crypto Malware called Petya ransomware, whose analysis on the effects can be read from the news "CryptoMalware 2.0 ==> PETYA ransomware the evolution of the species...".

The "static" analysis we have carried out has allowed us to understand better the functionality at low-level of Petya Ransomware.



Running the infected sample by Petya

FILENAME: Bewerbungsmappe-gepackt.exe
MD5: af2379cc4d607a45ac44d62135fb7015
SIZE: 230912 byte

We have tested the sample on a test computer with Widows XP ITA.

During the test of the file Bewerbungsmappe-gepackt.exe infected with the dropper of Petya, the computer crashes displaying the blue screen of BSOD (Blue Screen of Death) reported here by side.
The BSOD displays an error message in Italian language, more the likely due to the Italian version of Windows XP.

At this point the malware infected the hard disk's MBR (Master Boot Record) and it overwrote some sectors between the MBR and the Boot Sector of partition.

Petya CryptoMalware
In this phase it hasn't yet started to cipher the MFT (Master File Table).

Infected disk after running the Petya dropper:

The MBR's sector 0, is infected by Petya's loader code. The length of this code is 147 bytes.

Sectors from 1 to 0x21 are encrypted with XOR 0x37.

From sector 0x22 to 0x35 there are the Petya Ransomware's viral code.

In the sector 0x36 we find the key used for encryption, a vector, the Tor-Onion addresses and ID of the victim.

The sector 0x37 is used to check the key, in this phase each byte contains a 0x37 value.

In the sector 0x38 we find the original MBR encrypted with XOR 0x37.

The sector 0x39 is empty, it contains only zeros.


Sector 0x36
It is quite interestig to analyze in detail the sector 0x36.

The sector 0x36 structure:
off 0x0: 1 byte: value that indicates the disk status
  • 0: disk to be encrypted
  • 1: disk encrypted
  • 2: disk de-encrypted
off 0x01: (32 byte) key used for encryption
off 0x21: (8 byte) vector used for encryption
off 0x29: (128 byte) Tor-Onion addresses to pay the ransom
off 0xa9: (90 byte) victim id

At this point the disk or better the MFT (Master File Table) has still not been encrypted.
If the computer is turned off and restarted from a bootable CD or the hard drive connected as a secondary to another PC, you can remove the infection with FIXMBR command without losing any data.
If on the othe hand is rebooted or turned on, the Petya's viral code will encrypt the Master File Table.

Petya: first boot...

Let's see what happens when the MBR infected with Petya runs for the first time (the first boot).
When you turn on the computer, the BIOS will perform the code contained in disk's 0 sector (MBR).
The MBR code is loaded to the following address: 0:7c00
The infected MBR with Petya go to read 0x20 sectors starting from the sector 0x22 and loads them to the address: 0:8000, where jumps to that address with a JMP.
Now at 0:8000 we will have whole of Petya code active in memory.

The first operation that does is to read the partitions of all of connected discs and store them in a table with the following structure:
  • BYTE: drive (0x80+idx)
  • BYTE: 0/1
  • BYTE: 1
  • BYTE: ?
  • DWORD: end partition  (?)
Now it goes to read the sector 0x36 in memory:

The "sub_51b2"  function is used to read or write disk's sectors.
Prototype: (drive, buffer address, (DWORD) absolute sector,  num. of sectors, 0/1)
The last parameter indicates the reading (0) or writing (1).

At this point, checks the value of the first byte of 0x36th sector, namely that of the "disk status" field.
If set to 0 will start the encryption process, else will view the redemption instructions.

Being the first boot, the viral code will find the value of 0, which indicates that the Petya has to encrypt the Master File Table.

At this point begins the encryption phase, with the display of the false chkdsk messages. Petya CryptoMalware

Let's see in detail this stage of encryption:

Step 1: reading the key in memory and its deletion from the disk
  1. Petya reads again the sector 0x36 in memory
  2. Set to 1 the value of the first byte of the sector 0x36 loaded in memory (state of the disc)
  3. Copy the 32 bytes key into an internal buffer and resets the key in memory of sector 0x36
  4. Rewrite the 0x36th changed sector

Edited sector 0x36:

At this point the 32-byte key for encryption is only present in memory.

Step 2: encryption of the sector 0x37

Now Petya goes to encrypt the 0x37th sector (which contains all the byte value 0x37) with the key to 32 bytes (memory resident))
  1. Reading the sector 0x37 in memory 
  2. Encryption buffer in memory of the 0x37th sector with the 32-byte key and 8-byte vector (0x36 sector)
  3. Writing of the 0x37th sector encrypted
Encrypting of the sector 0x37 allows Petya to verify if the correct key is inserted.
Sector 0x37: before encryption Sector 0x37: after encryption

Now let's see the encryption function:

The "sub_54b2" function is responsible for the encryption key through the 32-byte and 8-byte vector.
The prototype of the function: (ptr Key 32-byte, ptr vector 8 bytes, 0/1, ptr buffer to be encrypted, size)
In the example is encrypted the buffer where is loaded the sector 0x37 whose size is 512 bytes.

The encryption takes place through the XOR function as shown by this diagram:

Petya creates a start "master" table of 0x40 bytes (as shown in the figure), where it is initialized with the following values:
  • "expand 32-byte k"
  • 32 byte key
  • 8 byte vector of the 0x36 sector
  • 8 byte with value 0
The table is re-processed through various functions, which for convenience we have called "Scramble", which goes to scramble the values so as to obtain 16 DWORD in this format: LO Word, HI Word, 0, 0. The algorithm used by the "Scramble" is very similar to Salsa20.

The byte with index 0 is encrypted with XOR taking the byte with index 0 of the index table 0 obtained by the "scramble" of the master table..
The byte with index 1 is encrypted with XOR taking the byte with index 1 of the index table 1 obtained by the "scramble" of the table with index 0...and so on.
Each time it is called the "Scramble" function is re-set the "master" table and increased its internal index, from which we get the new table..

for (j=0; j<n; j++) {

    if (j==0)
Table[0] = Scramble (Master Table)
Table[j] = Scramble (Table[j-1])

    Buffer_Cipher[j] = Buffer_Src[j] XOR Table[j].[j & 0x3f]  

Step 3: Encryption of the Master File Table
  1. Writing of the sector 0x39 with all zero (repeating this on all connected disks)
  2. Reading of the Boot Sector
  3. Calculating the MTF position on the disk
  4. Reading 2 MTF's sectors
  5. From the record with 0x80 attribute determines the total number of sectors to be encrypted and the absolute sector from whitch to start
  6. Encryption of MFT sectors with the 32 bytes key and the 8 bytes vector (8 sectors are encrypted at a time until reaching the predetermined number)li>
  7. Writing the 0x39th sector with the total number of encrypted clusters
  8. Computer reboot
In the figure below it is shown the sector 0x39 where is stored the number of encrypted clusters, in this case are 0x1558 clusters (43712 sectors, if 1 cluster = 8 sectors).

Now Petya has encrypted the Master File Table and during the next reboot the redemption instructions will be shown.

Petya: second boot or next

From the second startup, onwards, Petya will show its redemption screens:

Petya CryptoMalware Petya CryptoMalware

When Petya will read the 0x36th sector, this will begin with the value 1 (state of the disk: encrypted), indicates that the MFT has already been encrypted.

Step 1: Viewing the redemption information

  1. Displaying the skull screen (see figure above). To continue you must press a button
  2. Reading the sector 0x36 for the information of the Tor-Onion sites
  3. Viewing redemption information
  4. Asked to enter the Key
At this point Petya is waiting for the victim to insert the purchased Key.

Step 2: Control of the purchased key

The length of inserted key must be between 16 and 73 characters. Only the characters between the space ' ' asc (0x20) and the '~' asc (0x7e) will be printed on the screen.

From the inserted key are taken the first 16 characters that belong to the following set:
this new key will be called 16 bytes Key.
From the 16-byte Key you get a 32 bytes Key as shown in the figure:

The 32-byte Key is used by Petya to decrypt.

Step 3: decipherment phase

Once get the 32-byte Key, Petya does the following operations:
  1. Reading the sector 0x36 in order to read the 8 bytes vector.
  2. Reading the 0x37th sector
  3. Through the 32-bytes Key obtained and the 8-byte vector decrypts the sector 0x37, if every byte of the 0x37th sector has value 0x37, then the 32 bytes key is exact, otherwise displays the message "Invalid key!"
  4. If the key is correct, puts to 2 the first byte of the 0x36th sector and writes the 32-byte key in the same sector.
  5. Decrypts the Master File Table (MFT)
  6. Reads the sector 0x38 where is stored the encrypted MBR with XOR 0x37, after having deciphered it writes it in the sector 0.
  7. Deciphering sectors from 0x1 to 0x21 that they were encrypted with XOR 0x37
  8. In special cases (if in offset 0 x1b8 of the MBR contains the DWORD 0x37373737) then decrypts more sectors always with XOR 0x37
  9. At the end he asks you to restart your computer
Back to top

Can I recover the disk access ?

We saw that Petya uses the 0x37th sector to verify the correctness of the inserted key.
From the sector 0x37 we can determine the Bj-nth values of the j-nth tables used for encryption:

The sector 0x37: encrypted Table with 512 key xor obtained from sector 0x37

From the table obtained with the 512 key xor we can only decrypt the first encrypted MFT's sector from Petya. To decipher the following sectors of the MFT is necessary to know all the other keys obtained from the tables calculated by the method described previously.
However, having available only a value of the Table [0] is not possible to go back to the Master Table and consequently to 32-bytes Key.
Due to time constraints we can not deepen the analysis about the encryption system, although it would be interesting to see if there is the possibility to predict the missing values of the tables or the later xor keys to the 512-th..

So, if the malware has encrypted the MFT (Master File Table), for now, you can not log on to the drive without knowing the key used for encryption.
The encryption of the MFT does not involve encryption of files, but only the inability to access the disk. You can recover the files by accessing to low level disk, but this operation is very time consuming and expensive.

The FixMBR operation can only be performed if the MTF is not yet encrypted. In this case we can restart the PC from a bootable CD or connect the hard drive as a secondary to another computer, and run the FIXMBR command to remove the infection without losing any data.

In case has been done the FIXMBR with MTF encrypted, Windows will not load properly reporting disk corruption and invites using utility like "chkdsk utility", the use of which could further damage the MFT and make even more difficult to recover disk data even after the eventual payment.

Some brave one could try a "Brute Force" attack on the 32-bytes Key, which is obtained from that of 16 bytes, but the maximum number of possible 16-bytes keys on an alphabet of 54 elements is 5416 in verbal terms over 5 quadrillion too many for normal desktop computers.

Back to top

Final thoughts

By Petya Ransomware has started a new evolution of Crypto-Malware that use low-level disk functions to make it unusable and request a ransom. The analysis has shown how Petya Ransomware "works" at low level in different start-up phases, it would be interesting to analyze how the "dropper" calculates the 32-bytes Key and if there are any communications with command servers and control ( C & C) to determine a link between the ID of the victim and the 32-bytes Key generated.

This type of attack to the Master File Table makes very difficult to recover the data. Even if you own your backup data copies, you will need to re-install the operating system and the related applications in addition to recovery of your data from backup copies, with a considerable loss of working hours.

Of course we invite everyone to be careful when opening/running email attachments, even if they arrive from a known sender or browsing disreputable sites, and always making backups even on devices disconnected from the computer.

Author: Eng. Gianfranco Tonello

Back to top

Any information published on our site may be used and published on other websites, blogs, forums, facebook and/or in any other form both in paper and electronic form as long as the source is always and in any case cited explicitly “Source: CRAM by TG Soft www.tgsoft.it” with a clickable link to the original information and / or web page from which textual content, ideas and / or images have been extrapolated.
It will be appreciated in case of use of the information of C.R.A.M. by TG Soft www.tgsoft.it in the report of summary articles the following acknowledgment/thanks “Thanks to Anti-Malware Research Center C.R.A.M. by TG Soft of which we point out the direct link to the original information: [direct clickable link]”

Vir.IT eXplorer PRO is certified by the biggest international organisation: