Three lingering questions around the NotPetya attack

Two weeks after the NotPetya attack disrupted organizations across the world, especially those in the Ukraine, researchers agree that the malware propagating by corrupted software updates of an accounting program from the Ukrainian company M.E.Doc. In this blog, the Cybereason Intelligence Group asks how NotPetya was installed on machines, how the malicious code ended up on M.E. Doc’s servers and why the attackers didn’t carry out a more advanced attack. Understanding the how NotPetya was installed on victim’s machines and M.E. Doc’s servers can help all researchers better understand and detect these types of threats while knowing if two actors were involved in the attack can help refine the overall investigation.

How was NotPetya installed on machines?

No one knows how NotPetya ended up on the victim’s machines. Researchers agree that the malware propagated by the M.E. Doc software update process (EzVit.exe) Microsoft, for example, showed how EZVIT.exe calls two different process that install NotPetya, but does not explain how those files got into the ProgramData or AppData folders on the target host. Also, the NotPetya payload was not flagged in any of the EZVIT updates. But we don’t know if two separate infections happened simultaneously or if the backdoor was just one part of a multistage attack.

Here are three options that could explain how NotPetya infected computers.

1. The backdoor contains NotPetya as a payload. This is unlikely because researchers have already reversed the backdoor module and haven’t seen any files connected to NotPetya.
2. There’s the unlikely possibility that the backdoor connects to a server and downloads NotPetya.
3. The M.E. Doc update server also hosted the NotPetya payload. Here’s how this theory would play out: first, the backdoor is downloaded as a dropper. If the victim is identified as a high-value target (remember, the attackers could identify the victim organizations using their Ukraine tax code information) then the attacker sends a command to the backdoor to download NotPetya from the update server and install it on the host machine.
4. The OVH server contained the NotPetya payload and was pulled down on June 27 when the traffic to the update server was forwarded to the OVH server.

How did malicious code end up in the update server?

One option is that it was placed in the software during the development process. Another possibility is that a genuine update was uploaded to the server but the attackers accessed the server and replaced the legitimate update with a malicious one. To pull this off the attackers would have targeted a M.E. Doc server with weak security, allowing anyone to connect to it.

There’s the chance that attackers accessed M.E. Doc’s network either by launching an attack against the company or infiltrating a third party that M.E. Doc works with, giving adversaries access to the server and allowing them to upload the malicious code.

Researchers later said that NotPetya was more of a wiper than ransomware. If attackers knew they had access to high-value targets, why would they not carry out an advanced persistent threat (APT)?

This feeds into theory that two threat actors were involved. The hypothesis is that one threat actor was indeed in M.E. Doc’s network carrying out an APT. But another threat actor found its way onto M.E. Doc’s network and launched a wiper that knocked out the APT.