Researchers are digging through samples of the Petya ransomware, and while they’ve learned some about its inner workings, they still haven’t mastered enough to come up with a decryptor.
Petya is the latest twist on crypto-malware. It was found recently targeting companies in Germany in a spam campaign aimed at human resources organizations. The emails contained a link to a Dropbox file that if clicked loads a dropper that installs Petya. Dropbox has since removed the link and several others that were associated that also contained the same malware.
The ransomware will then encrypt the master file table on compromised machines, and demand around $400 in Bitcoin for the decryption key. This is a radical departure from other strains of ransomware that encrypt files stored on the computer, network shares or backups that the computer may have access to.
A Malwarebytes researcher who goes by the handle Hasherezade said on Sunday that she had discovered that the malware encrypts a partition table with XOR and the ASCII character 7, 0x37 in hex.
— hasherezade (@hasherezade) March 27, 2016
Once the dropper loads Petya, the malware overwrites the boot drive’s Master Boot Record with a malicious loader. The malware forces Windows to reboot and displays a phony check disk (CHKDSK) operation to the victim while the malware executes in the background and encrypts the master file table. Hasherezade said in another tweet that once the ransomware makes a XOR encrypted backup of the partition table, it will execute a Blue Screen of Death.
— hasherezade (@hasherezade) March 28, 2016
“Saving data at this point is relatively easy because only the beginning of the attacked disk is overwritten,” she said. “The file system is not destroyed and we can still mount this disk and use its content.”
She recommends that victims not reboot the system and opt instead to do a disk dump and eventually mount the disk to another OS and back it up.
If the second stage of the attack executes—the phone check disk operation—then the file system has been attacked and cannot be read, she said.
Lawrence Abrams of Bleeping Computer said it might be possible to recover data using a file recovery tool that analyzes the disk structure to locate files without using the master file table.
“Unfortunately, this would probably recover the files in a form that the user would have to go through each one trying to identify what type of file it is and then name it to the appropriate name,” Abrams said. “Not a fun or easy task by any means.”
Researcher Fabian Wosar said in a post to the KernelMode.info forums that only certain sections of data are encrypted with ASCII 7 and that the XOR decryption routine depends on the developer’s password.
From his post:
“Sector 0x37 contains the first 512 bytes of the XOR key stream that was used to encrypt the MFT. It is obfuscated using XOR 0x37. It will decrypt the first 8 sectors of the MFT, but the key stream changes after 4096 bytes. From what I can tell the permutation depends on the password you type in, so I don’t think there is a way to use just the information there without either the password or the 32 byte key from earlier to predict the entire key stream. From the looks of it, the only reason it is there at the moment seems to be to verify whether the typed in password is correct as the first 512 bytes generated by the password are compared to the partial key stream stored here to see if the user put in the correct password.”