Petya? I hardly know ya! - an ISC update on the 2017-06-27 ransomware outbreak

Published: 2017-06-28
Last Updated: 2017-06-28 17:10:43 UTC
by Brad Duncan (Version: 1)
7 comment(s)

This is a follow-up the our previous diary on the ransomware outbreak that happened yesterday on Tuesday 2017-06-27.


By now, it seems almost everyone has written something about yesterday's ransomware outbreak.  This led to some confusion after more information became available, and initial reports were updated.  This diary acts as a summary of what we know so far.

Shown above:  Screen shot from a host infected with this ransomware.

What we know so far

This ransomware targets systems running Microsoft Windows.  Although initial reporting called this ransomware Petya or a Petya variant, Kaspersky researchers reported it's a new ransomware.  Kaspersky has been calling the malware NotPetya, and other names have been floating around for it.  However, many people and organizations still call the ransomware Petya or a Petya variant.

This ransomware uses a modified version of the EternalBlue SMB exploit, and it also spreads using other methods like WMI commands, MimiKatz, and PSExec.  Although exploits for EternalBlue are relatively recent, malware has been using file shares and WMI to spread for years, and these older techniques don't require any vulnerabilities.

During the infection process, this ransomware overwrites the MBR with a custom boot loader that implements a tiny malicious kernel.  That tiny kernel encrypts the master file table (MFT) so the file system is unreadable.  The result is an unbootable system that demands a ransom to restore it.  The victim is asked to send $300 USD in Bitcoin to a Bitcoin wallet at 1Mz7153HMuxXTuR2R1t78mGSdzaAtNbBWX.

Shown above:  Nearly 4 Bitcoin received for that Bitcoin wallet as of 2017-06-28 at 16:44 UTC.

Based on public reports, this attack appears to have originated in Ukraine.  According to Krebs on Security the Ukrainian Cyber Police tweeted this attack may have started through a software update mechanism built into M.E.Doc, an accounting program used by companies working with the Ukrainian government.  From the Ukraine, it spread to major European firms like Maersk.

Although we've seen some information on files related to this ransomware, we can only confirm two DLL files as samples of the actual ransomware.  The SHA256 file hashes are:

How can you protect yourself against this threat?  Steps include:

  • Deploy the latest Microsoft patches, especially MS17-010.
  • Consider disabling SMBv1.
  • Restrict who has local administrative access.  Most people can operate with Standard User accounts instead of Administrator accounts.
  • If you have a large or complex infrastructure, segment your network.
  • Keep your anti-virus software up-to-date.  Vendors are constantly updating definitions to cover the latest malware samples.

Most importantly, you should implement a solid backup and recovery procedure for your critical data, just in case the worst happens and you get infected.

Final words

The day after this ransomware attack, our initial excitement has died down a bit.  Affected organizations are conducting response actions, and many others are implementing (or confirming) proper countermeasures.

We hope your organization is following best security practices and is protected against this latest threat.

Brad Duncan
brad [at]

7 comment(s)


Received an email from one of our IPS's stating that in response to this latest attack they are installing MS17-010 patch -_-
Not sure if it's related to this latest ransomware outbreak, but I have seen an uptick in fake invoice emails over the last couple days. A couple have gotten through while the majority have been blocked by Mimecast. They do not include attachments, but the links within them point to .doc files hosted on compromised websites. I'm not an oledump/deobfuscating expert, so if anyone wants to take a crack at them, let me know.
"That tiny kernel encrypts the master file table (MFT) so the file system is unreadable. "

Humm. Does that mean that files could possibly recovered using a forensic tool like foremost? Perhaps not to recover everything but enough of the important files to overcome the temptation to pay the ransom?

Yes, if the MFT is encrypted through the MBR code, all your data is still there and since the communications channel is down, this is the only way to recover files that aren't on backup.
I am probably missing something, but does this mean that a system can be completely recovered with a boot disk and "chkdsk /f" ?
From my reading it looks like the files are encrypted then the MBR is overwritten. So your files are there but they are not recoverable through forensics or other off the shelf utilities. Microsoft coverers the mechanics quite nicely here:

Seriously first and foremost why wasn't everyone smart enough to disable smb version 1 2 and 3 when shadow brokers broke...

Even still after wannacrypt was us national news.

It's funny cause I just turned V1 on so maybe I could get windows system image back up to back up to my 64Gig thumb drive, apparently that's to small for MS and they refused to let me do it period.... I was offline though.

If it is just the file table that is encrypted (really lazy coders if you ask me) then photorec should be able to recover all files. If the coders where even lazier still, then maybe there are some back ups. Not my area of specialty, but there are for sure MBR backups later on in the disk. If there are backups of the file table or pieces or maybe just the MBR use photorec's sibling testdisk.

I myself have worked many miracles on drives.

Diary Archives