NotPetya: Tuesday's massive ransomware attack was actually something much worse
(too old to reply)
2017-07-09 10:19:40 UTC
Raw Message
Tuesday?s massive ransomware attack was actually something much worse

Payload delivered in PetyaWrap attack destroys data, with no hope of

Dan Goodin (US) - 29/6/2017, 14:20


Tuesday's massive outbreak of PetyaWrap 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 PetyaWrap attack actually has the objective of
permanently destroying data.

New ransomware installs in boot record, encrypts hard disk
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
behaviours. With more time to analyse the malware, researchers on Wednesday
are highlighting some curious behaviour 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 analysing 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 capitalise on media interest sparked by last month's massive
WannaCry 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
(41f75e5f527a3307b246cadf344d2e07f50508cf75c9c2ef8dc3bae763d18ccf) of 0x22B1
bytes it basically sets v19 to 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.'"

First known hacker-caused power outage signals troubling escalation
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."
2017-07-09 10:25:31 UTC
Raw Message
Post by Kieren
Tuesday?s massive ransomware attack was actually something much worse

Sorry for the multiple posts - I am on the train and had very poor internet
access, and my usenet client reposted it a few times.
Andy K.
2017-07-09 10:49:54 UTC
Raw Message
On Sun, 9 Jul 2017 11:25:31 +0100
Post by Kieren
Sorry for the multiple posts - I am on the train and had very poor internet
access, and my usenet client reposted it a few times.
Damn, and here I was reading it three times, thinking it was a threeway
find-10-differences thing. :)

2017-07-09 14:04:36 UTC
Raw Message
Post by Andy K.
Post by Kieren
Sorry for the multiple posts - I am on the train and had very poor
internet access, and my usenet client reposted it a few times.
Damn, and here I was reading it three times, thinking it was a threeway
find-10-differences thing. :)
That would have been an excellent idea! On this occasion, in this version of
"Where's Wally"... I was the only Wally :)
RS Wood
2017-07-09 20:35:31 UTC
Raw Message
Post by Kieren
Post by Andy K.
Post by Kieren
Sorry for the multiple posts - I am on the train and had very poor
internet access, and my usenet client reposted it a few times.
Damn, and here I was reading it three times, thinking it was a threeway
find-10-differences thing. :)
That would have been an excellent idea! On this occasion, in this version of
"Where's Wally"... I was the only Wally :)
I found the difference! It's the hash of the PGP signature! Who *are*
you really?


Back on topic, the idea that Berners-Lee has caved to the DRM
concession because it allows him/them "a seat at the table" is
somewhat galling. Every time I've worked for an organization that
conceded some certain point so they could have "a seat at the table"
they eventually learned their bargain was foustian, and rather than
win a seat at the table, they'd announced their weakness, teaching
others it was no longer necessary to bargain for anything whatsoever.

The DRM in HTML concession - plus lost net neutrality - spells bad
times ahead for what we call the Internet.

I foresee a time when what we call the "Internet" is that
corporately-managed thing that got bought out by big business. And
the new thing - whatever we call it - will be "by/for the people" but
look a hell of a lot more like the BBS era.

I'm personally OK with a future like that. BBSes were cool :)