Updated 2016-04-03: Edited to add more details about the encryption scheme.
Petya is a new ransomware with an evil twist: instead of encrypting files on disk, it will lock the entire disk, rendering it pretty much useless. Specifically, it will encrypt the filesystem’s master file table (MFT), which means the operating system is not able to locate files. It installs itself to the disk’s master boot record (MBR) like a bootkit. But instead of covert actions, it displays a red screen with instructions on how to restore the system.
Going after the MFT is a fast attack that takes far less time than encrypting data files, but the overall affect is the same – the data becomes inaccessible.
Petya executes in two stages. The first stage is the main dropper, which:
- Infects the MBR using direct \\.\PhysicalDrive manipulation.
- Generates a set of crypto keys, including a random 16-byte key for disk encryption and an Elliptic Curve (EC) key pair. At this point also the special “decryption code” is prepared.
- Saves the disk encryption key and the decryption code to disk for later use in the MBR infection code. All other generated crypto data is discarded.
- Shuts down the machine without any warning to boot to MBR code.
Petya uses an Elliptic Curve encryption scheme for asymmetric key encryption and delivery. The dropper ships with a 192-bit public key and secp192k1 curve parameters hard coded in the binary. Petya takes the server public key and establishes a shared secret using a Elliptic Curve Diffie-Hellman (ECDH) algorithm. With this shared secret, that only the malware and server can use, the malware encrypts the 16-byte disk encryption key using AES. This is packaged together with the malware EC public key using a Base58 binary-to-ascii encoding scheme. The resulting package is the “decryption code” presented later on the red screen.
Petya dropper Physicaldrive manipulation.
Petya server ECC public key shipped in dropper.
Petya secp192k1 curve parameters shipped in dropper.
Petya dropper ECC public key ASCII encoding.
Petya dropper salsa20 bytes generation.
After the infection, the machine boots to MBR code, which:
- First checks to see if the disk is infected.
- If not, it will present a fake CHKDSK screen and will encrypt the MFT using the shared secret as the encryption key.
- Uses salsa20 for disk encryption, and destroys the key after encryption.
- Presents the red “skull screen” and then the screen with Tor hidden service URLs, and the “decryption code”, which is an encrypted message only the server can open.
Petya reversing environment.
Petya MBR code fake ‘CHKDSK’ encrypting disk with salsa20.
Petya MBR code salsa20 code.
Now only the server can restore the encryption key, using the EC algorithm. This is because the key is destroyed by the malware and even if it were not, the machine is locked and remains unusable. Even restoring the MBR with recovery disk won’t help, because the MFT is still encrypted. In theory, it could be possible to recover the shared secret and to decrypt back the disk encryption key with a recover disk, but for that the original EC keypair needs to be available and all the necessary EC data was discarded by the dropper. It’s like having two keys for the house, and losing the other one on purpose!
On the server side, the decoding of the decryption code supposedly happens in the reverse order:
- Decode the Base58-encoded binary data
- Extract malware public key and encrypted data
- Using the public key, establish the shared secret
- Using the shared secret, the server is able to decypt the disk encryption key, using AES
- Now the attacker can return back encryption key which can open up the locked machine
For example, one of the decryption codes on our labs’ machine looks like this (dashes and two first characters removed – server doesn’t use them for decoding).
Q5rL1YMqnJPCsCgji4KcDv5XnQrtqttBQ7tfbAq7QStmTXNQ6Voepeaiem8uzaQxYq3LwpvMCXBvMx2Mmqkdt8Fi
When this code is decoded using a standard Base58 algorithm, it produces the following data (malware generated public key presented with green color for demonstration purpose, and the encrypted disk key with red).
The only way to restore the machine without the help of the server is to catch the salsa20 key inline of the infection process, using debuggers. Not a very attractive counter measure for the average computer user
.
Trivia:
- Petya seems to be using this salsa20 implementation: https://github.com/alexwebr/salsa20
- Petya is definitely influenced by the “Evil Maid CHKDSK”: https://github.com/alexwebr/evilmaid_chkdsk