Petya

The jury is still out on whether the malware is Petya or something that just looks like it (it messes with the Master Boot Record in a way which is very similar to Petya and not commonly used in other ransomware).

Hasherzade who is a researcher well known for her great work with the original Petya ransomware, among other things, tweeted a bindiff showing the current strain has very high similarity to the original.

…but internally, not much has changed (comparison with version 3 – Green): pic.twitter.com/c1eZqBySOr

— hasherezade (@hasherezade) June 27, 2017

From Fabian Wosar:

“When people say Petya, they usually mean 3 things:
1. The boot loader that encrypts the MFT.
2. The dropper that installs the boot loader.
3. The normal user mode ransomware, which is also known as Misha.

Now, Petna has all these 3 components as well. But only the boot loader is ripped out of Petya. They have their own dropper, they have their own user mode ransomware. new messages. So if by Petya you refer to the MFT encryption stuff, then yes. Petna and Petya use the same code, just a different message. If by Petya you refer to the dropper as a whole with the optional fallback to encrypt files (Misha), then no. Petya and Petna are nothing alike.”

“Most likely someone ripped the boot loader code straight out of Petya and uses it for their own purposes now. But they implemented their own ransomware, their own worm, their own dropper, and pretty much everything else on top of it.”

Infection Propagation

Although people are calling this WannaCry v2 (or v3 depending on how much misinformation they read) there are some significant differences. WannaCry was spread entirely using the SMBv1 exploit nicknamed EternalBlue, which meant that infected systems would in turn scan and infect other systems which caused it to spread rapidly and exponentially. Had the WannaCry “kill switch” not been activated or not existed at all, the attack would continue to spread indefinitely across the entire internet. The Current Petya attack is different in the sense that the exploits it uses are only used to spread across a local network rather than the internet (i.e. you are extremely unlikely to be infected if you’re not on the same network as someone who was already infected). Due to the fact networks are of limited size and fairly quick to scan, the malware would cease spreading once it has finished scanning the local network and therefore is not anywhere near as infectious as WannaCry, which still continues to spread (though is prevented from activating via the “kill switch”).

The main reason people are saying Petya is bigger than WannaCry is due to the initial infection vector (how the malware started spreading). WannaCry would have likely been started by first infecting a few hundred computers which then scan and infect other computers, creating a snowball effect; however, current data suggests that Petya was deployed onto possibly millions of computers by hacking popular Ukrainian Accounting software “MeDoc”then using the automatic update feature to download the malware onto all computers using the software. All though MeDoc being the initial infection vector is unconfirmed (and even denied by the company itself), current evidence points to them (source1, source2, source3).

Microsoft has stated in their latest blog post that at least some of the infections were started from MeDoc’s legitimate update process, pretty much confirming the above theory.

https://twitter.com/thedefensedude/status/879764193913716737

The important difference between WannaCry and Petya is WannaCry was likely deployed onto a small number of computers and then spread rapidly, whereas Petya seem to have been deployed onto a large number of computers and spread via local network; therefore, in this instance there is low risk of new infections more than 1h after the attack (the malware shuts down the computer to encrypt it 1h after execution, by which time it will already have completed its local network scan).

As well as the use of EternalBlue, Petya can also propagate over the network using WMIC (Windows Management Instrumentation Commandline) by trying credentials gathered from the local machine using Mimikatz (source); this allows it to infect network systems which are patched against EternalBlue or not running SMB.

Again, it’s important to note that spreading appears to be limited to only devices on the local network.

UPDATE: Costin Raiu, CRO of Kaspersky Labs, is now suggesting there was a second initial infection vector where the website for the Ukrainian City of Bahmut (Бахмут) was hacked and used to serve the malware.

Avoid visiting link in below tweet as it may still be infected.

In addition to known vectors, ExPetr/PetrWrap/Petya was also distributed through a waterhole attack on https://t.co/j9DvYcEgW7

— Costin Raiu (@craiu) June 28, 2017

Kill Switch

Although some companies have claimed to have found a kill switch, this is nothing more than PR as the so called “kill switch” is only activated by modifying files on your own system (which can be done to stop most malware) and is not doable remotely like the WannaCry was. Furthermore, as stated above it’s unlikely the Petya ransomware is still spreading and the damage has already been done, thus a kill-switch would be futile.

Email Propagation

There are some claims the malware was sent out via spam as well, but these claims are currently unsubstantiated and though potentially true, likely weren’t responsible for the large number of public sector organisations hit in Ukraine.

File Recovery

DO NOT PAY THE RANSOM The email address the ransomware asks you to contact upon payment has been blocked by the provider, so there is currently little chance files can be recovered by paying the ransom.

According to xXToffeeXx and Emsisoft this variant of the Petya code encrypts the first 1 MB of every file with an extension matching its internal list prior to reboot, so previous claims that files could be recovered by stopping the system rebooting are incorrect. Preventing the encryption during boot will only prevent encryption of the MFT (Master File Table), not the encrypted files. Below is a list of file extensions the malware will encrypt.

.3ds .7z .accdb .ai .asp .aspx .avhd .back .bak .c .cfg .conf .cpp .cs .ctl .dbf .disk .djvu .doc .docx .dwg .eml .fdb .gz .h .hdd .kdbx .mail .mdb .msg .nrg .ora .ost .ova .ovf .pdf .php .pmf .ppt .pptx .pst .pvi .py .pyc .rar .rtf .sln .sql .tar .vbox .vbs .vcb .vdi .vfd .vmc .vmdk .vmsd .vmx .vsdx .vsv .work .xls .xlsx .xvd .zip

Destruction of Data (MBR Wiper)

There are currently claims circulating from this blog post that Petya contains a programming error which destroys some of the MBR (Master Boot Record), leading to speculation it is a Wiper and intended to destroy data rather than make money by holding it to ransom. Although I do not disagree that it’s possible the malware was designed to cause chaos and the ransomware was simply a way to disuse the true intentions as a criminal operation gone wrong, the MBR destruction claims are false.

In simple terms the claim is that the malware overwrites the first 25 sectors of the disk (original MBR and the following 24 sectors) with its malicious MBR but only saves the original first sector (MBR) elsewhere, meaning the following 24 sectors are lost. The speculation here is that this is a programming error designed to destroy the first 24 sectors of the disk whilst looking like an accident. What the blog author didn’t take into account is that the 24 sectors following the MBR are completely empty on any standard Windows intstallation. Windows MBRs are a total of 1 sector in size but for legacy reasons Windows will start the partition on sector 64 (this is sector 0 of track 1 on really old hard disks with 512 byte sectors), leaving 63 sectors of free space between the MBR and start of the partition (later raised to 2048 sectors in Windows Vista). Essentially on any standard Windows operating system there is nothing between sector 1 and sector 64, meaning the 24 sectors Petya “destroys” don’t contain anything at all, and the developer likely knows this.

According to Hasherzade this new change wasn’t even part of the Petya we’re seeing now, it was implemented in a much earlier version called GoldenEye.

but Goldeneye has identical layout – nothing has changed here (see: https://t.co/g5LsFyU3pu) pic.twitter.com/WANnbFZFkx

— hasherezade (@hasherezade) June 28, 2017

Destruction Of Data (Buggy CryptEncrypt usage)

Bug in #Petya’s encryption may leave some files damaged and undecryptable. pic.twitter.com/V8agzHocaL

— Ladislav Zezula (@LadislavZezula) June 28, 2017

The bug in the code is very clear. Normally such an encryption would set the IV (Initialization Vector) at the start of encrypting a file and reset it has finished with each file (this is done by setting bFinalBlock to True when calling CryptEncrypt); however, the code here only sets bFinalBlock to true if the file is smaller than 1 MB (0x100000 bytes). so there are 2 negative outcomes here:
1) Should a file with more than 1 MB of data be encrypted, the IV will not be rest until a file with less than 1 MB of data is encrypted.
2) If the file is larger than 1 MB only the first MB will be encrypted and the rest left untouched.

Although the IV not being reset could potentially cause problems, I believe that as long as the files are decrypted in the reverse order they were encrypted, and the same buggy code is used for decryption, all data should be recoverable. The way the code is set out (i.e not setting bFinalBlock to True if the file is larger than 1 MB) suggests the developer was trying to encrypt files 1 MB at a time to avoid using too much RAM, but never got around to writing the code responsible for handling the rest of the file should it exceed 1 MB.

Destruction of Data (Installation ID Loss)

Kaspersky has claimed that the ransomware generated two seperate installation IDs (the real one, and the one displayed to the user), which Haserzade has corroborated.

The Salsa20 key of the new #EternalPetya may, actually, be lost forever: https://t.co/PY4K5BKqMb (research in progress) // #Petya

— hasherezade (@hasherezade) June 29, 2017

If this is true, the MFT (Master File Table) is not decryptable because the installation ID displayed to the user is not real and therefore the data required to decrypt the MFT is not present. Without the MFT it would be extremely difficult to know where files start and end, and in which order the files were encrypted, meaning the CryptEncrypt bug discussed previously would also take effect.

Network Hopping (theory)

Although it still seems like the malware was deployed widespread through another vector, I’ve found a way in which it could possibly escape a network using the EternalBlue exploit.

By default a corporate machine would be behind NAT with an IP address like 10.0.0.2 and a netmask of 255.255.255.0, in this case the malware would use the IP address and net mask to figure out that the network it needs to scan is 10.0.0/24 (10.0.0.1 – 10.0.0.254). However, if the machine were to have a public IP address it might have an IP of 123.123.123.1 and a netmask of 255.255.255.252 the malware would scan 123.123.123.1 – 123.123.123.3 (in this case there’d probably be nothing in that range other than the gateway). But what if we set a netmask that is far too big? If we misconfigured our network and set the netmask to 255.0.0.0 then the malware would scan 123.0.0.0/8 (123.0.0.1 – 123.255.255.254) which is a large amount of IP space and could contain other vulnerable SMB devices. Obviously the gateway should not allow this, but in cases where proxy ARP is enabled the malware could successfully infect another public IP in the same range as the misconfigured netmask.

I’ll be updating this article regularly with various citations and sources to keep everyone up to date. Last update: 2017-06-29 01:56 (UTC)

More info on https://blog.kryptoslogic.com/malware/2017/06/28/petya.html