Co-authored by Steve Stone.

After finalizing initial analysis, IBM X-Force Incident Response and Intelligence Services (IRIS) concluded that the Petya variant attacks that started on Tuesday, June 27, were intended as destructive attacks against Ukraine, rather than a means for cybercriminals to make money from ransom payouts. In other words, this attack was not focused on financial gain like the ransomware attack it was veiled to be.

Several pieces of evidence from our research suggest that the attacks were designed to permanently disable as many machines as possible and that the malware was, in fact, more characteristic of a “wiper” attack (intended to destroy data) rather than a ransomware attack.

IBM X-Force IRIS outlined this evidence in technical detail below. However, the main factor leading to this conclusion is that the Personal Installation Key provided on the lock screen instructions is randomly generated and incapable of relaying the information the attacker would need to provide the correct Advanced Encryption Standard (AES) decryption key.

Put simply, the information provided in the “ransomware” is not accurate or relevant to unlocking any affected machine. Additionally, the design of the attack suggests that it was carried out by a technically skilled group of cybercriminals, yet the execution of the ransomware and payment methodology showed little to no expertise or intent to produce financial gains.

Watch the on-demand webinar: An Incident Responder’s POV — Inside the Latest Petya Variant

Further analysis of impacted victims also led our team to conclude that this attack was specifically aimed at organizations within Ukraine:

• IBM has data to confirm that MeDoc, the tax software specific to organizations doing business in Ukraine, was the initial vector for the attacks.
• For all of the attack victims IBM security experts analyzed, the initial host machine infected was based in Ukraine.
• The attackers also leveraged an element of Strategic Web Compromise, or “watering hole” attacks, in which the malware was hidden within compromised websites. The websites that were compromised in this attack were frequented by Ukrainian visitors versus a global audience.

Based on these factors, it’s clear that the Petya variant used in these attacks is not related to the traditional Petya malware in purpose or technical indication. Given this, we believe the attacks were executed by a separate group than the previous Petya attacks.

Additional technical analysis of this evidence is below.

Intent on Destruction

For victims of this attack, following the instructions on the ransomware’s lock screen does not provide the attacker with enough information to derive the recovery key needed to unlock files on impacted machines. This indicates that either the malware was deployed without testing, or the attacker was never serious about unlocking files for those that would pay the ransom.

Given that the attacker accomplished much more technical feats (automated lateral movement and ETERNALBLUE and ETERNALROMANCE propagation), IBM X-Force IRIS believes the attacker was not serious about unlocking files. We know that emailing the address specified by the attacker on the ransomware lock page results in a bounce message due to its shutdown by the provider. This tactic for payment verification is also uncommon and prone to shutdowns by the email provider.

Malware Is More Wiper Than Ransomware

June 30 Update: During our continued analysis, IBM X-Force IRIS researchers identified an additional encryption mechanism utilized by the malware. The MFT is encrypted using the Salsa20 algorithm, but the key is not stored anywhere on disk as-is or in encoded/encrypted format. The MFT encryption, plus the AES encryption of files targeted by the malware, put the odds of data recovery at zero even with access to the attacker’s RSA private key.

A wiper is characterized by unrecoverable file destruction, which is effectively what this new Petya variant accomplished.

IBM X-Force IRIS assessed the following destructive capabilities:

• The malware overwrites the logical sector 1 of the C: drive.
• It also writes a new loader code in physical sector 0, where the master boot record (MBR) is, and succeeding sectors of the physical drive where Windows is installed. The contents of the original MBR is encrypted via byte-wise XOR using 0x07 as the key and then copied to sector 34 of the physical drive. Note that the malware assumes 512 bytes per sector when performing this.
• The malware restarts the machine at a later time by creating a scheduled task that will execute “%WINDIR%\System32\shutdown.exe /r /f.”
• The loader code displays the following fake CHKDSK run when the machine is restarted.

• After the fake CHKDSK run is finished, the system is again restarted and the following ransom message is shown:

IBM X-Force IRIS determined that, theoretically, there is a very narrow path to decryption for those who have access to the attacker’s RSA private key. The RSA private key could be used to decrypt an encrypted AES key present in the readme.txt ransom file. You would need to mount the drive on another system and copy over the infected files, then decrypt them with the unencrypted AES key. Note that only the attacker has access to the RSA private key, and the odds of it becoming public are unlikely (it would need to be released by the attackers themselves or someone who had compromised the private key).

For all intents and purposes, the odds of recovery are nearly zero.

Not Enough Info to Obtain Recovery Key

Files on victim machines are encrypted using a randomly generated AES key that is then encrypted using an RSA public key. The encrypted AES key is then stored as a base64 blob in a readme.txt ransom note created by the malware. The readme.txt contents are not accessible from the lock screen or after the MBR is patched by the malware.

Victims only get a few pieces of information from the lock screen:

• A payment amount ($300);
• A bitcoin wallet address;
• An email address to verify payment; and
• A Personal Installation Key.

The Personal Installation Key is randomly generated. This information is not enough to generate the system-specific AES encrypted or decrypted key. It is impossible for the attacker to provide the required information to unlock files on victim machines when provided with only the requirements on the screen lock page. It should be noted these problematic shifts are different from traditional Petya payment mechanisms, which proved successful in the past.

Victims All Suffered Due to Ukrainian Footprint

Finally, for all active cases that IBM Security is working, the impacted organization suffered due to a footprint in Ukraine. While this event was global in scale, IBM’s experience shows a global impact was produced due to the global nature of companies with assets in Ukraine versus genuine global targeting. In fact, “patient zero,” or the initial host for all impacted clients we investigated, were machines based in Ukraine. It is unlikely that financially motivated actors would limit their targeting — especially for a wormlike tool — to one region or country.

For additional technical details, see the live Petya Ransomware Campaign collection on IBM X-Force Exchange.

Explore the IBM X-Force Exchange Collection

This post was updated on June 30, 2017, to reflect the latest information.