Updated 2016-05-03: Edited to add some small details about the decryption code.
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:
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.
After the infection, the machine boots to MBR code, which:
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:
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).
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 :).