According to Microsoft, the Petya (also referred to as NotPetya/ExPetr) Ransomware attack started its initial infection through a compromise at the Ukrainian company M.E.Doc, a developer of tax accounting software. We took a closer look and did a full analysis using VMRay Analyzer.
To start, the initial infector executes the following command-line: “C:\Windows\System32\rundll32.exe C:\ProgramData\perfc.dat #1 30”.
Presumably, the attackers exchanged the “perfc.dat” with their “Petya.dll” to run instead. But they had to consider that “rundll32.exe” will call the first exported function of the dll. Hence the “#1” in the command-line.
This is important when we upload the Petya.dll file for analysis because we have to submit the “#1” parameter too. For this case, the analyzer upload dialog has a field for command line arguments (illustrated in Figure 1), where we type the “#1”.
Figure 1: Petya upload with ‘#1’ command line argument
If we forget this argument, the “rundll32.exe” calls the standard EntryPoint in the “Petya.dll”. This works, but the VTI (VMRay Threat Identifier) Score will be low because the malware author of Petya 2017 leaves this function empty. Which means nothing happens, and therefore no score.
After uploading Petya.dll with the command line argument (Figure 2), we get a total VTI Score of 100/100.
Figure 2: Petya’s VTI Score 100/100
The first line in the VTI Information section of the report confirms what we see in the screenshots: a complete new boot-screen with the infamous Petya look.
In the first step, Petya retrieves a list of all running processes and builds a hash for each. Then Petya will decide what configuration to run on if there is a match out of the three fixed hashes. It searches for the hashes
0x2E214B44, 0x6403527E and 0x651B3005 (Figure 3).
Figure 3: Petya searching for hashes
The first hash 0x2E214B44 could be reconstructed to the string “avp.exe”. This process is a part of Kaspersky Security software. If this process is running the Petya ransomware will destroy the master boot record (Figure 4). Otherwise, the master boot record is overwritten with the new Petya bootloader.
Figure 4: Destroying of master boot record if process runs Petya
The other two hashes couldn’t be reconstructed so far, but there is functionality. If one of the hashes were found, Petya does not try to spread itself using the SMB exploit EternalBlue. After this setup, Petya starts its main task: infect, encrypt and clean up.
Petya uses several different tactics to infect other machines. One is to drop and run a credential dumping tool. This strategy leverages a common behavior of users logging into accounts using local admin privileges with sessions running on multiple machines. The credentials stolen by Petya are likely to provide the same level of access to other machines.
If the stolen credentials are valid it scans the network, copies itself to other machines using a normal file transfer protocol and then uses the WMIC (Windows Management Instrumentation Command-line) tools to execute the copies remotely (Figure 5).
Figure 5: Using the WMIC tools to execute the copies remotely
If the WMIC tool does not work it attempts remote execution with the PSEXEC tool which is dropped as “dllhost.dat” (Figure 6).
Figure 6: PSEXEC tool dropped as “dllhost.dat”.
The other option to spread itself is via the EternalBlue exploit (Figure 7).
Figure 7: Another option of spreading itself through EternalBlue exploit
In parallel with the infection tactics, Petya starts its encryption routine. To get a quick overview, we look into the function logfile and search for a well-known suffix, like ”.png” (Figure 8), because we think the ransomware will search for it. As expected, we find a part of the encryption routine.
Figure 8: Searching for .png file in the function logfile
Now we can read out all suffixes, Petya is looking for:
'.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'
If we scroll to the end of the function logfile “FindFistFileW / FindNextFileW”- loop, we reach the encryption part for these files (Figure 9).
Figure 9: “FindFistFileW / FindNextFileW”- loop in the Function Logfile
We notice that the encryption does not use the API function “WriteFile”. Instead, it uses “MapViewOfFile” / “UnmapViewOfFile”, which allows the encryption of the files directly. But with this technique, the encrypted files do not get a new suffix. All files are encrypted with the same AES key. The AES key is encrypted by the malware author’s public RSA key. As a result, the encrypted AES key is written into the README.txt (Figure 10). These techniques were uncovered searching through the function logfile. The keys are securely generated.
Looking at the “Monitored Processes” section of the “Overview” section of Analysis Report we can see the encryption is running two other processes started in independent instances of a command line “cmd.exe”.
The first command executes:
wevtutil cl Setup & wevtutil cl System & wevtutil cl Security & wevtutil cl Application & fsutil usn deletejournal /D C:
This command is actually 5 commands executing at the same time. All “wevutil cl” tasks ensure that the logfiles of System, Setup, Security, and Application are cleared (parameter cl means “clear logfile”). The “fsutil usn deletejournal /D C:” command deletes, as you guessed, the NTFS journal on the system partition C:.
The second command executes:
schtasks /Create /SC once /TN "" /TR "C:\Windows\system32\shutdown.exe /r /f" /ST 17:15
That creates a task which reboots the system at a chosen time. This method is used because if “shutdown.exe” executes with the parameter “/t” (“/t”means timeout before shutdown) a notification pops up and tells the user that the system will restart in x minutes. Now let’s assume the scheduled time is reached and the system reboots. Then a fake disk repair tool is shown (Figure 11).
Figure 11: Fake Disk Tool
After some time, the fake repairing is completed and the next state of the Petya bootloader runs (Figure 12).
Figure 12: Petya bootloader running
The text shown below is mostly the same as the “README.txt”, but the “personal installation key” is different:
Ooops, your important files are encrypted. If you see this text, then your files are no longer accessible, because they have been encrypted. Perhaps you are busy looking for a way to recover your files, but don't waste your time. Nobody can recover your files without our decryption service. We guarantee that you can recover all your files safely and easily. All you need to do is submit the payment and purchase the decryption key. Please follow the instructions: 1.Send $300 worth of Bitcoin to following address: 1Mz7153HMuxXTuR2R1t78mGSdzaAtNbBWX 2. Send your Bitcoin wallet ID and personal installation key to e-mail email@example.com. Your personal installation key: AQIAAA5mAAAApAAANUldtvtKKU1mS2hocPjGIMog8hcf59P2AV+Y9EaPFWZt4SWP WCDsnvQ/6gW6jT5maHjhKQdGATWxtbWdYvIFZuAdM7BZzrSKiH1SFAQpa5gj26o1 i6yFqL6ImeSO9cvmjZP+2TDVIOKcMdFzR7Mv+YDmEo0cEUKijsaYJAv2Ka5Wi8vX TPl0mq+RPnbsRygh3UYnWcpDXEgwwLsC1e5vKSYct9iRF18kOAPOGa2vil5v1sOO iTt9rGyw2EW8BlzgQffr127tWCnT52x11QNLN69bJPmHtKv+SoWJFdNQL2e7Emsd 2kYquDAcmNSFBCLBueXjjGilrteSzk/iflzLSw==
That means after a reboot, the shown “personal installation key” is totally useless and very likely a randomly generated number that does not help to reconstruct the original AES key for the decryption.
The new Petya ransomware is not really a ransomware, but more of a wiper. This is because it changes the master boot record (MBR) without backup and shows a random useless “personal installation key”. The e-mail address “firstname.lastname@example.org” was instantly banned from the mail provider. And looking at the Bitcoin account shows that only a few payments were transacted (Figure 14).
Figure 14: Bitcoin/Email Information – Petya 2017
The 3.99029155 BTC is worth about $10,000 – a trivial amount for a ransomware scheme. The invalid email address along with the Bitcoin inconsistencies indicate that Petya was engineered for destructive intentions rather than for financial gain. Security researcher Nicholas Weaver at the International Computer Science Institute told Krebs on Security, “I’m willing to say with at least moderate confidence that this was a deliberate, malicious, destructive attack or perhaps a test disguised as ransomware,” Weaver said. “The best way to put it is that Petya’s payment infrastructure is a fecal theater.”
For a deeper look at Petya, access our full analysis report.