Don’t Pay the Ransom: Petya Ransomware Update

June 28, 2017 • Allan Liska

Now that the Petya ransomware attack has settled down and information is not coming quite as fast, it is important to take a minute to review what is known about the attack and to clear up some misconceptions.

Origination of the Attack

While there were initial reports that the attack originated from a phishing campaign, these remain unverified. The few samples that were shared contained different malware and were not related to this attack.

At this point, the most likely culprit is a tampered update from Ukrainian accounting software firm Me.Doc. There is a good deal of evidence that most, if not all, of the initially infected firms use this software and it appears that this software is required by the Ukrainian government for businesses that pay taxes in the Ukraine.

Me.Doc initially posted an apology on their website:

Me.Doc Apology

Though, they also posted a denial on their website:

Me.Doc Denial

Several of the earliest infected companies have confirmed that the initial infection was delivered via a Me.Doc update.

Petya/NotPetya/PetrWrap

There has been some confusion as to whether or not this is really a variant of the Petya ransomware. Kaspersky has released a statement that they do not think this is the Petya ransomware, they are calling it NotPetra. Whatever you want to call it, their statement ignores the evolution of Petya over the last year or so. The initial release of Petya simply replaced the Master Boot Record with a malicious loader that encrypted the Master File Table. The problem with this method is that it requires administrative access, which would prompt a window requiring a user to click, making it a less successful campaign than it could have been.

In May of last year, Petya started to be bundled with Misha, a more traditional ransomware that encrypted individual files, rather than the Master File Table — so if the first ransomware attack didn’t work it would fall back to the second.

The latest iteration of Petya, from March of this year, was called PetrWrap and it had a very similar ransom note to the current variant that is out there (see below), in addition to also spreading via RDP. From an evolutionary standpoint there is a clear line of delineation between the original Petya and the attacks we are seeing today.

PetrWrap Ransom Note

One other thing to keep in mind is that Petya was widely available in underground forums as part of a ransomware-as-a-service (RaaS) offering — which means the code behind Petra was widely distributed. So, while these attackers are most likely not the original developers behind Petra, it would be trivial for them to gain access to original Petya code.

Don’t Pay the Ransom

Security professionals will often tell victims of ransomware attacks to not pay the ransom for a variety of reasons. In this case victims shouldn’t pay the ransom because there is no way to get the key to decrypt the files.

Unlike most ransomware attacks, this attack relies on email to deliver the keys to decrypt the files, using the email address wowsmith123456[at]posteo[.]net. The email provider, Posteo, has decided to disable access to the attackers mail box. This means even if the ransom is paid there is no way to communicate with the attacker.

Posteo Screenshot

That being said, as of 12:00 PM ET, the Bitcoin wallet associated with this attack had received $10,263 in payments from 45 victims.

Indicators and Kill Switches

There are two file hashes that Recorded Future has been able to verify are associated with this attack:

  • 027cc450ef5f8c5f653329641ec1fed91f694e0d229928963b30f6b0d7d3a745
  • 64b0b58a2c030c77fdb2b537b2fcc4af432bc55ffb36599a31d418c7c69e94b1

The first is the main DLL, the second is the 64-bit executable. Both of these hashes are confirmed as associated with the same ransom letter email and Bitcoin address.

There has also been some discussion of a “kill switch” that can be used to prevent the attack. That does not appear to be true. The ransomware does look for a certain file and if that file is present, then it does not execute. This is not a “kill switch” necessarily but a way to “vaccinate” (as one researcher put it) against the malware for a little while.

The file that the ransomware looks for is perfc and it should be located in the c:\windows directory.

Please note, this is not advisable as a single point of protection. This is trivial to change within the Petya code and may not act as a deterrent in future versions of the attack.

Another protection that some researchers have advocated is to shutdown (not reboot) the computer when the fake CHKDSK screen appears.

Fake CHKDSK Screen

CHKDSK is a legitimate Microsoft program that is used to identify potential errors on a computer’s hard drive. This ransomware attack flashes a fake screen while it is encrypting files on the victim machine. If a victim sees this screen they can immediately force a hard shutdown of their computer to stop the encryption process.

While this will work, as with the use of the perfc file, this remediation step should be an absolute last-ditch attempt to stop the attack and there is no guarantee that it will stop all files from being encrypted.

Conclusion

Much like WannaCry, the Petya attacks seem to be dwindling quickly the day after the initial infection. However, given the worm-like nature of the code it is possible that the ransomware will spread indefinitely. It is important to remain vigilant against these types of attacks and to ensure that the protections discussed in the previous blog post are implemented and kept current.

New call-to-action

Related Posts

Prioritize Vulnerabilities With Unprecedented Intelligence for Free

Prioritize Vulnerabilities With Unprecedented Intelligence for Free

May 20, 2020 • The Recorded Future Team

How do you describe vulnerability management in your organization If terms like “rat race” or...

Rise in Retail-Focused Phishing Campaigns During Pandemic

Rise in Retail-Focused Phishing Campaigns During Pandemic

May 19, 2020 • Allan Liska

As people around the world have had to stay home because of the COVID-19 pandemic, there has been a...

Automating Threat Detection and Response With Security Intelligence

Automating Threat Detection and Response With Security Intelligence

May 14, 2020 • The Recorded Future Team

Automating threat detection and response has historically been a very expensive and time-consuming...