Tuesday’s massive outbreak of malware that shut down computers around the world has been almost universally blamed on ransomware, which by definition seeks to make money by unlocking data held hostage only if victims pay a hefty fee. Now, some researchers are drawing an even bleaker assessment—that the malware was a wiper with the objective of permanently destroying data.
Initially, researchers said the malware was a new version of the Petya ransomware that first struck in early 2016. Later, researchers said it was a new, never-before-seen ransomware package that mimicked some of Petya’s behaviors. With more time to analyze the malware, researchers on Wednesday are highlighting some curious behavior for a piece of malware that was nearly perfect in almost all other respects: its code is so aggressive that it’s impossible for victims to recover their data.
In other words, the researchers said, the payload delivered in Tuesday’s outbreak wasn’t ransomware at all. Instead, its true objective was to permanently wipe as many hard drives as possible on infected networks, in much the way the Shamoon disk wiper left a wake of destruction in Saudi Arabia. Some researchers have said Shamoon is likely the work of developers sponsored by an as-yet unidentified country. Researchers analyzing Tuesday’s malware—alternatively dubbed PetyaWrap, NotPetya, and ExPetr—are speculating the ransom note left behind in Tuesday’s attack was, in fact, a hoax intended to capitalize on media interest sparked by last month’s massive WCry outbreak.
Researchers at antivirus provider Kaspersky Lab, in a blog post published Wednesday, labeled the previous day’s malware a “wiper.” They explained that for attackers to decrypt a paying victim’s computer, they need a “personal infection ID” that’s displayed in the ransom note. In the 2016 version of Petya, the ID contained crucial information for the key recovery. Tuesday’s malware, by contrast, was generated using pseudorandom data that was unrelated to the corresponding key. Kaspersky Lab researchers Anton Ivanov and Orkhan Mamedov wrote:
If we compare this randomly generated data and the final installation ID shown in the first screen, they are the same. In a normal setup, this string should contain encrypted information that will be used to restore the decryption key. For ExPetr, the ID shown in the ransom screen is just plain random data.
That means that the attacker cannot extract any decryption information from such a randomly generated string displayed on the victim, and as a result, the victims will not be able to decrypt any of the encrypted disks using the installation ID.
What does it mean? Well, first of all, this is the worst-case news for the victims – even if they pay the ransom they will not get their data back. Secondly, this reinforces the theory that the main goal of the ExPetr attack was not financially motivated, but destructive.
In an e-mail, they stated the problem this way:
Our analysis indicates there is little hope for victims to recover their data. We have analyzed the high-level code of the encryption routine, and we have figured out that, after disk encryption, the threat actor could not decrypt victims’ disks. To decrypt a victim’s disk, threat actors need the installation ID. In previous versions of “similar” ransomware like Petya/Mischa/GoldenEye, this installation ID contained the information necessary for key recovery. ExPetr does not have that, which means that the threat actor could not extract the necessary information needed for decryption. In short, victims could not recover their data.
Researcher Matt Suiche of Comae Technologies, in his own blog post published Wednesday, also called Tuesday’s malware a wiper. But rather than focus on the pseudo-randomly generated installation ID, he highlighted the overwriting of key files stored on the infected hard drive.
“The ransomware was a lure for the media,” he wrote. “This version of Petya actually wipes the first sectors of the disk like we have seen with malwares such as Shamoon.” He went on to write: “We believe the ransomware was in fact a lure to control the media narrative, especially after the WannaCry incidents, to attract the attention on some mysterious hacker group rather than a national state attacker like we have seen in the past in cases that involved wipers such as Shamoon.”
Suiche provided the above side-by-side code comparison contrasting Tuesday’s payload with a Petya version from last year. Both pieces of code take aim at two small files—the master boot record and master file table—that are so crucial that a disk won’t function if they are missing or corrupted. But while the earlier Petya encrypts the master boot record and saves the value for later decryption, Tuesday’s payload, by contrast, was rewritten to overwrite the master boot record. This means that, even if victims obtain the decryption key, restoring their infected disks is impossible.
“Petya 2016 modifies the disk in a way where it can actually revert its modification,” Suiche told Ars. “Whereas yesterday’s one does some permanent damage to the disk.”
Asked if the recovery made possible by Petya 2016 was related to the master boot record tampering, Suiche pointed to this analysis of the ransomware from researchers at Check Point Software. It described three stages:
- Stage 0 “MBR Overwrite” – Overwrite the hard-drive’s Master Boot Record and implanting custom boot-loader.
- Stage 1 “MFT Encryption” – Use the custom boot-loader introduced in Stage 0 to encrypt all Master-File-Table (MFT) records, which renders the file system completely unreadable.
- Stage 2 “Ransom Demand” – Display the Petya logo and the ransom note detailing what must be done to decrypt the hard-drive.
“Both these values will be used further in the encryption process performed at Stage 1,” Suiche told Ars. “At this point, Petya encrypts the original MBR by XORing its content with 0x37. It then saves this encrypted value to the 56th Disk Sector. Petya continues to encrypt disk sectors 1-34 (the physical range is 0x200h-0x4400h) with the exact same method.”
Tuesday’s malware, by contrast, destroys the 25 first sector blocks of the disk. In Wednesday’s blog post, Suiche wrote:
The first sector block is being reversibly encoded by XORed with the 0x7 key and saved later in the 34th block. But since it replaces it with a new bootloader (
41f75e5f527a3307b246cadf344d2e07f50508cf75c9c2ef8dc3bae763d18ccf)of 0x22B1 bytes it basically sets
v19to 0x19 (25).16.0: kd:x86> ? 0x22B1 - (0x22B1 & 0x1FF) + 0x1024
Evaluate expression: 12836 = 00003224
16.0: kd:x86> ? 0x00003224 >> 9
Evaluate expression: 25 = 00000019
That would mean that 24 sector blocks following the first sector block are being purposely overwritten, they are not read or saved anywhere. Whereas the original 2016 Petya version correctly reads each sector block and reversibly encode them.
Definitely not designed to make money
Another researcher who uses the handle the grugq published an analysis that also supported the theory that Tuesday’s outbreak wasn’t a true ransomware attack. The analysis noted that the malware used a single Bitcoin address to receive ransom payments, a shortcoming that’s not found in most professionally developed ransomware because it requires attackers to manually process large numbers of payments. Tuesday’s malware also required victims to manually type a long string of human-unfriendly characters into an e-mail address, a hurdle professional ransomware developers avoid because it decreases the likelihood that victims will pay. Tuesday’s malware also required victims to contact attackers through an e-mail account that was closed within hours of Tuesday’s outbreak, killing any incentive for victims to pay.
In almost all other aspects, Tuesday’s malware was impressive. It used two exploits developed by and later stolen from the National Security Agency. It combined those exploits with custom code that stole network credentials so the malware could infect fully patched Windows computers. And it was seeded by compromising the update mechanism for M.E.Doc, a tax-filing application that is almost mandatory for companies that do business in Ukraine. The shortcomings in the ransomware functions aren’t likely to be mistakes, considering the overall quality of the malware.
“The superficial resemblance to Petya is only skin deep,” the grugq wrote. “Although there is significant code sharing, the real Petya was a criminal enterprise for making money. This is definitely not designed to make money. This is designed to spread fast and cause damage, with a plausibly deniable cover of ‘ransomware.'”
The theories are consistent with this post from Wired, which reports that Ukrainian government officials are saying Tuesday’s attack was sponsored by a national government. The Ukrainian government has previously blamed Russia for attacks—one in December 2015 and another in December 2016—that both caused blackouts by hacking Ukrainian power facilities. A cover story Wired published last week lays out much of the evidence substantiating the claims of Russian involvement. Asked if Russia was behind Tuesday’s attack, a government official told reporter Andy Greenberg: “It’s difficult to imagine anyone else would want to do this.”
This post was updated to add details starting in the seventh paragraph, on how the permanent data destruction occurs. It was also edited to remove references to permanent hard drive destruction until those claims can be explicitly confirmed.