We have recently been facing a huge outbreak of a new Petya-like malware armed with an infector similar to WannaCry. The research is still in progress, and the full report will be published soon.
In this post, we will focus on some new important aspects of the current malware. The low-level attack works in the same style as the first Petya, described here. As before, the beginning of the disk is overwritten by the malicious Petya kernel and bootloader. When the malicious kernel is booted, it encrypts the Master File Table with Salsa20 and in this way, makes the disk inaccessible.
The code from Petya’s kernel didn’t change much, but the new logic implemented in the high-level part (the Windows executable) caused the change in the malware’s mission. In the past, after paying the ransom, the Salsa key from the victim was restored and with its help, the Petya kernel was able to decrypt the Master File Table. Now, the necessary key seems to be lost for eternity. Thus, the malware appears to have only damaging intentions.
Let’s have a look at the implementation and discuss the details.
- 71b6a493388e7d0b40c83ce903bc6b04 – the main DLL
- f3471d609077479891218b0f93a77ceb – the low level part (Petya bootloader + kernel)
[UPDATE] A small bug in the Salsa20 implementation has been found. Unfortunately, it is not significant enough to help restoring the key.
How is the disk encrypted?
The Salsa20 algorithm that was implemented incorrectly in the early versions of Petya and caused it to be cracked has been fixed in version 3 (read more here). Now it looks almost the same as in Goldeneye (that was the 4th step in the evolution) and it does not seem to have any significant bugs. Thus, once the data is encrypted, having the valid key is the only way to restore it.
Here’s a comparison of the changes in the code between the current version and the Goldeneye one.
Looking inside the code, we can see that the significant changes have been made only to the elements responsible for displaying the screen with information.
Another subtle, yet interesting change is in the Salsa20 key expansion function. Although the Salsa20 algorithm itself was not altered, there is one keyword that got changed in comparison to the original version. This is the fragment of the current sample’s code:
And this is a corresponding fragment from Goldeneye:
Instead of the keyword typical for Salsa20 (“expand32-byte k“) we’ve got something custom: “-1nvald s3ct-id” (that can be interpreted as: “invalid sector id”). As we confirmed, the change of this keyword does not affect the strength of the crypto. However, it may be treated as a message about the real intentions of the attackers.
How is the Salsa key generated?
Generating the Salsa key and the nonce, as before, is done by the PE file (in the higher level of the infector), inside the function that is preparing the stub to be written on the disk beginning.
In all versions of Petya, a secure random generator was used. We can find it in the current version as well—it uses CryptGenRandom.
The generated Salsa key and nonce are stored in the dedicated sector for further use by the kernel during encryption.
Example of the stored data:
The byte at the offset 0x4000 is the flag: 0 means that the disk is not encrypted yet, 1 means encrypted.
From the offset 0x4001, the Salsa20 key starts. It is 32 bytes long. After that, at offset 0x4021 there is the random Salsa20 nonce.
What happens with the Salsa key after the encryption?
After being read and used for the encrypting algorithm, the stored Salsa key is erased from the disk. You can see the comparison of the disk image before and after the encryption phase.
As you can see, after use the key is erased.
What is the relationship between the victim ID and the Salsa key?
In the previous versions of Petya, the victim ID was, in fact, the victim’s Salsa20 key, encrypted with the attacker’s public key and converted to Base58 string. So, although the Salsa key is erased from the disk, a backup was still there, accessible only to the attackers, who had the private key to decrypt it.
Now, it is no longer true. The victim ID is generated randomly, BEFORE the random Salsa key is even made. So, in the current version, the relationship of the Salsa key and the victim ID is none. The victim ID is just trash. You can see the process of generating it on the video.
After the reboot from the infected disk, we can confirm that the random string generated before Salsa key and nonce is the same as the one displayed on the screen as the victim ID (“personal installation key”):
According to our current knowledge, the malware is intentionally corrupt in a way that the Salsa key was never meant to be restored. Nevertheless, it is still effective in making people pay ransom. We have observed that new payments are being made to the bitcoin account. You can see the link to the bitcoin address here: https://blockchain.info/address/1Mz7153HMuxXTuR2R1t78mGSdzaAtNbBWX
If you are a victim of this malware and you are thinking about paying the ransom, we warn you: Don’t do this. It is a scam and you will most probably never get your data back.
We will keep you posted with the updates about our findings.
About the original version (Goldeneye):
This was a guest post written by Hasherezade, an independent researcher and programmer with a strong interest in InfoSec. She loves going in details about malware and sharing threat information with the community. Check her out on Twitter @hasherezade and her personal blog: https://hshrzd.wordpress.com.