As promised, in this thread I'm going to run a dynamic test of Petya ransomware.
Sample: Malwr - Malware Analysis by Cuckoo Sandbox
File Name : Bewerbungsmappe-gepackt.exe
File Size : 230912 bytes
File Type : PE32 executable (GUI) Intel 80386, for MS Windows
MD5 : af2379cc4d607a45ac44d62135fb7015
PC Test:
Windows 7 x 64 SP1, Intel B830 processor, 4 GB RAM inside in VirtualBox 5.0.16.
Tools: Dskprobe hex disk editor for sectors.
This is the 0 sector of my HDD before the execution of Petya:
Petya seems to be using encryption, anti-debugging and anti-emulation techniques for avoiding the analysis and it uses too much CPU time (causing the sandbox by timeout) or excessive memory allocation and this could explain the error analysis on the main Malwr page.
Executing Bewerbungsmappe-gepackt.exe, the computer stops showing BSOD (Blue Screen of Death) and at this point the malware has infected the Master Boot Record (MBR) of HDD, overwrite certain areas (MBR and the Boot Sector of the partition) but at this stage it has not yet begun to encrypt the MFT (Master File Table).
The ransomware encrypts the current MBR and it is then copied to the HDD and It overwrites the original MBR applying XOR encoding. The intent is to prevent access to the whole disk rather than to individual files.
From my research I have found that the XOR encoding varies on each system, but infecting several times my guest, I saw the exact same MBR.
After running sample, HDD infected:
Sector 0 of the MBR and from 0x22 to 0x35 sectors are infected with the code of Petya.
Sectors from 1 to 0x21 is encrypted with XOR and into 0x38 sector there is the original MBR encoding with XOR.
The sector 0x37 is used to verify key.
Inside in 0x36 sector there is the encryption key, Tor-Onion addresses and the ID of the victim.
Now MFT has not been encrypted and, if the computer is rebooted or powered on, Petya encrypt the Master File Table.
When it runs the first boot, MBR is infected with Petya and the Bios executes the code contained in sector 0 (MBR) of the drive and all code of Petya is active in memory so it reads the 0x36 sector in memory (this step is important).
At this point, it checks the value of the first byte of the sector 0x36 and If it's 0 then encryption begins, otherwise it displays the ransom instructions.
Being the first boot, the malcode find the value 0, which indicates that Petya must encrypt the Master File Table so it begins with false messages about "chkdsk".
Let's see in more detail this encryption step:
Reading the key in memory and its deletion from disk
-Petya reads again the sector 0x36 in memory and It sets to 1 the value of the first byte of the sector 0x36 loaded in memory then It copies the key in an internal buffer and resets the memory of 0x36.
-It writes the 0x36 sector, amended
Sector 0x36, amended:
Now it seems that Petya encrypt the 0x37 sector with the key (resident in memory) and this allows it to check whether the entered key is correct.
Sector 0x37: before encryption:
Sector 0x37: after encryption:
Petya creates a master table which is initialized and then re-processed through various functions and the algorithm used, from the research that I have done, is very similar to Salsa20 Salsa20 - Wikipedia, the free encyclopedia
MFT encryption
-Writing 0x39 sector with all zeros
-Reading the Boot Sector and encryption of MFT sectors with key, writing 0x39 sector with the total number of encrypted cluster.
-Reboot the computer
At this point Petya encrypted the MFT and from the next reboot are displayed the ransom instructions.
When Petya reads the 0x36 sector, It start with value 1, indicating that the MFT has already been encrypted.
Ransom information display
-Reading 0x36 sector for information about Tor-Onion, displaying information for ransom with the request to insert the key
At this point Petya waits for the victim to enter the purchased key.
So if the malware has encrypted the MFT, you cannot log on to the disk without knowing the key used for encryption.
The encryption of the MFT does not mean file encryption, but only the inability to access the disk... and the eventual FixMBR operation can be performed only if the MFT is not yet encrypted, otherwise Windows does not load properly, reporting disk corruption and urges the use of utility type "chkdsk", whose use could further damage the MFT.
Petya Ransomware works at low level at various steps of startup but honestly it is difficult for me to understand as the core computes the key and if there are communications with a command/control server to determine a link between the victim's ID and the key (Malwr analysis did not show network communications).
I stop here and what I've understood so far Petya is like an old DOS master boot malware, very complex about the management of the key and it works in different way than other ransomware.
This analysis represents a long process of interpreting the results of this test according to my knowledge level and this may cause errors, so sorry for that.
Thank you everyone
Sample: Malwr - Malware Analysis by Cuckoo Sandbox
File Name : Bewerbungsmappe-gepackt.exe
File Size : 230912 bytes
File Type : PE32 executable (GUI) Intel 80386, for MS Windows
MD5 : af2379cc4d607a45ac44d62135fb7015
PC Test:
Windows 7 x 64 SP1, Intel B830 processor, 4 GB RAM inside in VirtualBox 5.0.16.
Tools: Dskprobe hex disk editor for sectors.
This is the 0 sector of my HDD before the execution of Petya:
Petya seems to be using encryption, anti-debugging and anti-emulation techniques for avoiding the analysis and it uses too much CPU time (causing the sandbox by timeout) or excessive memory allocation and this could explain the error analysis on the main Malwr page.
Executing Bewerbungsmappe-gepackt.exe, the computer stops showing BSOD (Blue Screen of Death) and at this point the malware has infected the Master Boot Record (MBR) of HDD, overwrite certain areas (MBR and the Boot Sector of the partition) but at this stage it has not yet begun to encrypt the MFT (Master File Table).
The ransomware encrypts the current MBR and it is then copied to the HDD and It overwrites the original MBR applying XOR encoding. The intent is to prevent access to the whole disk rather than to individual files.
From my research I have found that the XOR encoding varies on each system, but infecting several times my guest, I saw the exact same MBR.
After running sample, HDD infected:
Sector 0 of the MBR and from 0x22 to 0x35 sectors are infected with the code of Petya.
Sectors from 1 to 0x21 is encrypted with XOR and into 0x38 sector there is the original MBR encoding with XOR.
The sector 0x37 is used to verify key.
Inside in 0x36 sector there is the encryption key, Tor-Onion addresses and the ID of the victim.
Now MFT has not been encrypted and, if the computer is rebooted or powered on, Petya encrypt the Master File Table.
When it runs the first boot, MBR is infected with Petya and the Bios executes the code contained in sector 0 (MBR) of the drive and all code of Petya is active in memory so it reads the 0x36 sector in memory (this step is important).
At this point, it checks the value of the first byte of the sector 0x36 and If it's 0 then encryption begins, otherwise it displays the ransom instructions.
Being the first boot, the malcode find the value 0, which indicates that Petya must encrypt the Master File Table so it begins with false messages about "chkdsk".
Let's see in more detail this encryption step:
Reading the key in memory and its deletion from disk
-Petya reads again the sector 0x36 in memory and It sets to 1 the value of the first byte of the sector 0x36 loaded in memory then It copies the key in an internal buffer and resets the memory of 0x36.
-It writes the 0x36 sector, amended
Sector 0x36, amended:
Now it seems that Petya encrypt the 0x37 sector with the key (resident in memory) and this allows it to check whether the entered key is correct.
Sector 0x37: before encryption:
Sector 0x37: after encryption:
Petya creates a master table which is initialized and then re-processed through various functions and the algorithm used, from the research that I have done, is very similar to Salsa20 Salsa20 - Wikipedia, the free encyclopedia
MFT encryption
-Writing 0x39 sector with all zeros
-Reading the Boot Sector and encryption of MFT sectors with key, writing 0x39 sector with the total number of encrypted cluster.
-Reboot the computer
At this point Petya encrypted the MFT and from the next reboot are displayed the ransom instructions.
When Petya reads the 0x36 sector, It start with value 1, indicating that the MFT has already been encrypted.
Ransom information display
-Reading 0x36 sector for information about Tor-Onion, displaying information for ransom with the request to insert the key
At this point Petya waits for the victim to enter the purchased key.
So if the malware has encrypted the MFT, you cannot log on to the disk without knowing the key used for encryption.
The encryption of the MFT does not mean file encryption, but only the inability to access the disk... and the eventual FixMBR operation can be performed only if the MFT is not yet encrypted, otherwise Windows does not load properly, reporting disk corruption and urges the use of utility type "chkdsk", whose use could further damage the MFT.
Petya Ransomware works at low level at various steps of startup but honestly it is difficult for me to understand as the core computes the key and if there are communications with a command/control server to determine a link between the victim's ID and the key (Malwr analysis did not show network communications).
I stop here and what I've understood so far Petya is like an old DOS master boot malware, very complex about the management of the key and it works in different way than other ransomware.
This analysis represents a long process of interpreting the results of this test according to my knowledge level and this may cause errors, so sorry for that.
Thank you everyone
