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.

More from Malware

Kronos Malware Reemerges with Increased Functionality

The Evolution of Kronos Malware The Kronos malware is believed to have originated from the leaked source code of the Zeus malware, which was sold on the Russian underground in 2011. Kronos continued to evolve and a new variant of Kronos emerged in 2014 and was reportedly sold on the darknet for approximately $7,000. Kronos is typically used to download other malware and has historically been used by threat actors to deliver different types of malware to victims. After remaining…

A View Into Web(View) Attacks in Android

James Kilner contributed to the technical editing of this blog. Nethanella Messer, Segev Fogel, Or Ben Nun and Liran Tiebloom contributed to the blog. Although in the PC realm it is common to see financial malware used in web attacks to commit fraud, in Android-based financial malware this is a new trend. Traditionally, financial malware in Android uses overlay techniques to steal victims’ credentials. In 2022, IBM Security Trusteer researchers discovered a new trend in financial mobile malware that targets…

RansomExx Upgrades to Rust

IBM Security X-Force Threat Researchers have discovered a new variant of the RansomExx ransomware that has been rewritten in the Rust programming language, joining a growing trend of ransomware developers switching to the language. Malware written in Rust often benefits from lower AV detection rates (compared to those written in more common languages) and this may have been the primary reason to use the language. For example, the sample analyzed in this report was not detected as malicious in the…

Raspberry Robin and Dridex: Two Birds of a Feather

IBM Security Managed Detection and Response (MDR) observations coupled with IBM Security X-Force malware research sheds additional light on the mysterious objectives of the operators behind the Raspberry Robin worm. Based on a comparative analysis between a downloaded Raspberry Robin DLL and a Dridex malware loader, the results show that they are similar in structure and functionality. Thus, IBM Security research draws another link between the Raspberry Robin infections and the Russia-based cybercriminal group 'Evil Corp,' which is the same…