Petya.2017 is a wiper not a ransomware

Ransomware-as-a-service soon to be renamed Lure-as-a-Service

Dubbed Fakesomware by Comae (Also called ExPetr, PetrWrap, NotPetya, DiskCoder).
TL;DR: The ransomware was a lure for the media, this variant of Petya is a disguised wiper.

Update1: Few hours later, Kaspersky’s research led to a similar conclusion.

Update2: Added more info on the wiper command & comparative screenshots of the two keys that visually confirms Kaspersky’s finding and why the MBR copy routine didn’t make sense.

What’s the difference between a wiper and a ransomware ?

The goal of a wiper is to destroy and damage. The goal of a ransomware is to make money. Different intent. Different motive. Different narrative. A ransomware has the ability to restore its modification such as (restoring the MBR like in the 2016 Petya, or decrypting files if the victim pays) — a wiper would simply destroy and exclude possibilities of restoration.

Yesterday, we provided a preliminary analysis where we demonstrated that the 27th June 2017 version of Petya leveraged SMB exploits ETERNALBLUE and ETERNALROMANCE.

Today, we spent more time to understand how the files could be retrieved and how the actual MBR and MFT was being encoded.

Sloppy sector blocks modifications

Fortunately, there are multiple excellent existing analysis from 2016 Petya that have been published last year in multiple languages such as French, or English [1, 2]. Today, Microsoft published a very descriptive analysis of the 2017 Petya but for some reasons missed the below part.

After comparing both implementation, we noticed that the current implementation that massively infected multiple entities in Ukraine was in fact a wiper which just trashed the 18 first sector blocks of the disk while replicating itself. Some noted that this was mainly slack space as only the first sector is relevant for most of machines — except few exceptions. I mainly note that since this can be used in some scenarios, this is why I consider it a sloppy overwrite.


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 v19 to 0x13 (19).

16.0: kd:x86> ? 0x22B1 - (0x22B1 & 0x1FF) + 0x400  
Evaluate expression: 9728 = 00002600  
16.0: kd:x86> ? 0x00002600 << 9  
Evaluate expression: 19 = 00000013

That would mean that 18 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.

2016 Petya modifies the disk in a way where it can actually revert its changes. Whereas, 2017 Petya does permanent and irreversible damages to the disk.

On the left, we can see the current version of Petya clearly got rewritten to be a wiper and not a actual ransomware.


Left (2017 Petya) with the wiper code — Right (2016 Petya) which reads and encode sector blocks.

This means the MBR section of the disk is purposely over written by the new bootloader

No more email address for payment

Moreover, the payment email address isn’t accessible anymore if victims would happen to send payments.

Wiper function executed under some conditions

After further analysis, (see Appendix A) we also discovered that the attackers implemented a function that wipes the first 10 sectors of \\\\.\\PhysicalDrive0 including the MBR under two conditions:

  • If the hash command computed from a running process name (“avp.exe”) returns 0x2E214B44
  • If the function that replaces the actual MBR returns an error. Probably as a generic way to detect EDR trying to prevent bootloader modifications.



The hash command generation, and flag gestion for the different modes can be found in our decompiled version here.

UPDATE: After further research, we determined that the mysterious hash command is generated from lower case “avp.exe” process name which correspond to the Kaspersky Anti-Virus.

Key inconsistency

As Kaspersky reported, the key generated itself on the screen is fake and randomly generated. After looking more at how the encryption file key was generated, we also notice an inconsistency that reinforces this statement. This can also be proven by comparing “installation key” displayed in the README.txt and on the screen — as you can see the format is clearly different.

On the left is the display by the MBR code we described above as sloppy written, on the right the content of the README.txt with an actual key generated by the ransomware.


This means that assuming a decryptor would come to be released, the input required would have to come through the README.txt — not from the screen.

Buggy encryption process

BOOL WINAPI CryptEncrypt(  
  _In_    HCRYPTKEY  hKey,  
  _In_    HCRYPTHASH hHash,  
  _In_    BOOL       Final,  
  _In_    DWORD      dwFlags,  
  _Inout_ BYTE       *pbData,  
  _Inout_ DWORD      *pdwDataLen,  
  _In_    DWORD      dwBufLen  

As described by Ladislav Zezula, the boolean Final flag in the function CryptEncryptis incorrectly initialized during the encryption.

Salsa20 Key sets to “invalid”

The Salsa20 key appears to have been modified with an hexadecimal editor and not recompiled. The new value is also set to the cryptic value “-1nvalid s3ct-id” which can be read as “invalid secret identifier”.


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.

The attacker took an existing ransomware which he repackaged.

Lately, the number of attacks against Ukraine increased from Power Grids being shut down to the car a top military intelligence officer exploding yesterday — the day Petya.2017 infected Ukraine.

The fact of pretending to be a ransomware while being in fact a nation state attack — especially since WannaCry proved that widely spread ransomware aren’t financially profitable — is in our opinion a very subtle way from the attacker to control the narrative of the attack.

Additional note,_ tomorrow Thursday 29 @ 10AM EST _for a technical webinar on Petyacome join Kaspersky & Comae— no sales pitch. We promise ! Only technical stuff.

Appendix A — Caller