H-ISAC Threat Intel Committee Advisory on Improved Petya (1530 EDT 28 June 2017)

*Any reproduction or reposting of this content requires proper credit / attribution to H-ISAC.

This information is marked TLP White for widest distribution. Subject to standard copyright rules, TLP: WHITE information may be distributed without restriction.

Update summarizing H-ISAC current understanding of the event, the ransomware, it’s capabilities, and custom developed mitigations.

What is it?

Petya is a derivative of GoldenEye commodity ransomware, equipped with several self-replicating mechanisms.  The self-replicating behavior is what sets it apart from other ransomware, and it is directly responsible for widespread impact.

What is the initial infection vector?

The only confirmed infection vector is a MeDoc update. MeDoc is accounting software in widespread use in Ukraine produced by a Ukranian company. Virtually all Ukranian companies, in virtually all sectors use MeDoc. This includes American companies operating in Ukraine. The MeDoc software suite features an auto-update mechanism through which software updates can be distributed to clients.  In May 2017, an unidentified attacker compromised the MeDoc autoupdate server and caused it to distribute XData malware to MeDoc customers. Yesterday, a different (or possibly the same) attacker compromised MeDoc autoupdate servers and caused it to distribute the Petya malware. This is the only confirmed initial infection vector at this time.

Additionally, MeDocs appears to still be compromised. We found a webshell backdoor on their main website, and we were able to obtain a copy of the file. MeDoc was made aware of this discovery.

Kaspersky researchers tweeted that Petya was additionally distributed through a watering hole attack using a compromised Ukranian news site. This report is unconfirmed at this time.   

There are no known methods of initial infection other than ones listed above. To put it explicitly – there are no known instances of spread through email, driveby downloads, exploit kits or any other means traditionally associated with delivering malware.

How does it spread?

Once a machine is infected, Petya uses several mechanisms to attempt to spread to other computers, and it uses several mechanisms to decide which computers to attempt to spread to.

To determine which hosts to attempt to infect, Petya uses more than one mechanism. The first mechanism is calling WNetOpenEnum Windows API which returns all active SMB connections on the infected computer.  Each of these connections will be targeted regardless of which network they’re in.  For example, if the infected computer has a mapped drive to a file server that’s on a completely different network, that file server will be targeted by Petya.

The second mechanism is a scan of the local network, as defined by the IP address and network mask of the infected computer.  For example, if the infected machine is, Petya will target all IPs from to

Petya will attempt to copy itself to each identified target.  In order to copy the file to target machine, Petya will harvest credentials from the infected system. There are two types of harvests Petya appears to implement. The first is a call to CredEnumerateW which returns all currently logged on user’s credentials. The second method appears to be MimiKatz (which requires Administrative privileges).

In order to copy itself to targets, Petya will attempt to connect to the ADMIN$ share of each identified target, using the harvested credentials until it either succeeds or it runs out of credentials.  On success, Petya copies itself to C:\Windows\perfc.dat on the target machine.

As a final step, Petya will attempt to execute the new copy of itself on the target.  For this, it uses two methods as well.  First it will invoke psexec. If that approach fails, it will try to do it using WMI.

If the approaches above have failed to result in execution on the target, as a final resort, Petya will attempt to use ETERNALBLUE and ETERNALROMANCE exploits to both copy and execute itself on the target.  The vulnerabilities targeted by these exploits have been patched some months ago under MS17-010.

As with any patch/update, any modifications should be evaluated before implementation by your appropriate system security personnel. H-ISAC Threat Intel Committee has vetted the following mitigations to the extent available.

Killswitch / Vaccine

On execution, the known Petya samples delete themselves and perform a check to verify if this deletion is successful. If the file is still present, Petya will exit. This behavior can be turned into a protection mechanism of sorts.  If you create a vaccine file:


and set the permissions of the file to deny write permissions to everyone, including system administrators, infection can’t succeed as Petya will be unable to copy itself over.

Keep in mind that some security tools operate on very simple signatures, and it’s possible you’ll get alerts. This prevents all currently known lateral spread methods.

Other mitigations:

  • If Petya is unable to reach ports 139 and 445 it can’t spread.  Local firewalls can facilitate this.
  • If Petya is unable to mount the ADMIN$ share it can’t spread (Except through exploits).  You can administratively disable ADMIN$ share through GPO
  • Apply Microsoft Patch MS17-010 to all internal systems.
  • Enable protective signatures on all security devices to prevent EternalBlue from spreading.


 Targeted extensions:







71b6a493388e7d0b40c83ce903bc6b04 (main 32-bit DLL)


e285b6ce047015943e685e6638bd837e (main 32-bit DLL)



7e37ab34ecdcc3e77e24522ddfd4852d (64-bit EXE)


2813d34f6197eb4df42c886ec7f234a1 (32-bit EXE)


 Attacker Email –  (decryption key request after payment) :


Bitcoin Wallet:



*Any reproduction or reposting of this content requires proper credit / attribution to H-ISAC.