NotPetya pulls BadRabbit out of the hat

Technical Report — Group-IB
Rustam Mirkasymov
Threat Intel expert
• It is highly likely that the same group of hackers was behind BadRabbit ransomware attack on October the 25th, 2017 and the epidemic of the NotPetya virus, which attacked the energy, telecommunications and financial sectors in Ukraine in June 2017. Research revealed that the BadRabbit code was compiled from NotPetya sources. BadRabbit has same functions for computing hashes, network distribution logic and logs removal process, etc.

• The distribution of BadRabbit was massive, though there were much fewer victims than in the NotPetya case. The primary high level victims of the BadRabbit attack were: several Ukrainian strategic enterprises (airport, metro, state institutions), in Russia - federal mass media. There were attempts to infect banking infrastructure, but these were confirmed to be unsuccessful.

• BadRabbit was distributed using drive-by download, not a watering hole attack. Several media websites were used to spread the virus in Ukraine and Russia.

• A preliminary study confirmed that the websites used for drive-bys were hacked from targeted attacks. In at least one case the website was compromised as the computer of the website developer was hacked. In a similar manner, if we look back to NotPetya attack, the system administrator of the Ukrainian developer of document management system M.E.Doc was hacked. Through it, attackers gained access to the update server and installed their firmware to infect users with NotPetya virus.

• When a user visited one of the infected websites, a malicious JavaScript sent information to the server, owned by the marketing company Jetmail. We assume that their server had been compromised by exploiting the vulnerability in Apache Tomcat / Coyote JSP engine 1.1. Some time ago North Korean state sponsored hacker group - Lazarus also used avulnerability in this Web-server for targeted attacks on Banks. However, this group is not linked to this attack.

The attacker group changed their tools and tried to disguise themselves as a conventional Cybercrime group. Previously NotPetya used only one Bitcoin wallet for ransom, which suggested that the authors were not going to decrypt victim files, and that their main goal was sabotage. However, in Bad Rabbit a unique key is generated for each infected computer, and for each key, its own Bitcoin wallet. This makes ransom payments harder to track. Additionally, in the BadRabbit attack the same domain name was used, which had previously been employed in conventional cybercriminal activity for phishing and traffic distribution.

• File analysis on the TOR network domain revealed that the site there was prepared at least on October 19, and the malicious program contained a certificate with subscription date on October 25, although the attack started on October 24. Some of malware modules have compilation date on October 22. All this indicates that the attack itself was carefully planned and, most likely, was scheduled for October 25.

• Some modules were compiled in the summer of 2014, which indicates that hacker group used old tools from previous attacks. This corresponds with BlackEnergy timeframes, as the group started its notable activity in 2014 with disk tools.

Attack scheme:
After visiting the drive-by compromised website the victim sees the following message suggesting to update Flash Player.
Requests are sent to 1dnscontrol.com/logo.png and 1dnscontrol.com/flash_install.php, then the executable file 1dnscontrol.com/install_flash_player.exe is downloaded for user to launch.

This is how it appeared on our sensors:
This picture demonstrates that we noticed first attack at 11 am on October, 24th. The malicious file has been detected by Group-IB sandbox - TDS Polygon at downloading stage.

Shortlist of Compromised sites:
This diagram shows compromised sites used to spread the Bad Rabbit Malware.

Attack schematic:
The File install_flash_player.exe is an executable program in PE format that masquerades as an Adobe Flash Player installer.
Some anomalies are obvious from the first glance: future date (25th instead of 24th October when the file appeared). There is a possibility that this attack was initially planned for 25th October.

Compilation date – 22nd October.

SHA256: 630325cac09ac3fab908f903e3b00d0dadd5fdaa0875ed8496fcbb97a558d0da
MD5: fbbdc39af1139aebba4da004475e8839
Size: 441899 bytes

After the malicious program is launched file infpub.dat is extracted and saved into the following folder - %WINDOWS%. Then rundll32.exe is launched with the following parameters C:\Windows\infpub.dat,#1 15. Invocation of a function with the ordinal number 1 and the argument 15, where 15 means the minutes before the system restarts.

The program is initialized: process validation, privilege check, debugging prevention and deletion C:\Windows\infpub.dat.
The body contains in resources section 3 modules for operation systems x86 and x64:

1. Driver for the disk.
2. MBR encryptor, which also controls driver for MBR encryption.
3. Mimikatz.

The way these modules are located in resources is the same as NotPetya, but now they are preliminary scored with 0xE9 key. For module compression in resources - zlib 1.2.8 is used – this is the same as in NotPetya. Despite the fact that the most recent version is 1.2.12.

To prevent debugging after launch the program deletes file C:\Windows\infpub.dat, preliminarily having copied it to memory. After it unloads it's body calling API function FreeLibary() and then passing the control flow to memory page, where the content was copied before.

After this the mutex checks synchronization with other instances. If there is a mutex, the program terminates.

If a process has following privileges: SeDebugPrivilege - the driver of opensourced product https://diskcryptor.net is unpacked and saved to C:\Windows\cscc.dat. What is more if the file C:\Windows\cscc.dat is detected, the program will be terminated.
cscc.dat is dcrypt.sys driver included in the diskcryptor package supported by ReactOS Foundation. Driver version – 1.1.846.118, the digital signature is dated 9th July 2014.

SHA256: 682adcb55fe4649f7b22505a54a9dbc454b4090fc2bb84af7db5b0908f3b7806
MD5: b4e6d97dafd9224ed9a547d52c26ce02
Size: 181448 bytes
Date of compilation: July 9th, 2014 6:41:52 AM

Further, all system processes are listed again. And if a process with a hash 0xF4713B0E is found, then the program will try to finish it.

Then the MBR Encryptor program will be extracted and saved. It also sends the opensource commands to the driver diskcryptor for MBR encryption. The driver is used to encrypt MBR and place its own boot subprogram. The program MBR Encryptor will be saved in %WINDOWS % \dispci.exe then the task will be created with the name rhaegal:
dispci.exe is an MBR encryption/decryption program, it also interacts with the driver that encrypts the MBR. The attackers called the program GrayWorm.
SHA256: 8ebc97e05c8e1073bda2efb6f4d00ad7e789260afa2c276f0c72740b838a0a93
MD5: b14d8faf7f0cbcfad051cefe5f39645f
Size: 142848 bytes
Date of compilation: October 22nd, 2017 2:33:09 AM
With the previously installed driver while working it creates a scheduled task the the name viserion to shutown system:
Next, a service is created by SCManager that launches the driver. But if SCManager fails, this will be done by generating registry keys.

The following service should be created:
name: cscc
description: Windows Client Side Caching DDriver
path: C:\Windows\cscc.dat

Or the following keys in the registry would be created:
After that the keys in the registry would be changed:



If the OS is Vista and older, then

Then a task named drogon would be created in order to shutdown the PC.
Security and event logs are deleted in order to complicate data recovery.
Simultaneously a lot of threads are launched to be distributed over the network. The Mimikatz utility is used to extract account data, as well as a hard-coded list of logins and passwords is employed.

The Mimikatz utility exists in the resources of two versions: x86 and x64. The program will be extracted in% WINDOWS% \ <4 random characters>.tmp and launched in the parameter as a pipe, through which results are received.

SHA256 2f8c54f9fa8e47596a3beff0031f85360e56840c77f71c6a573ace6f46412035
MD5: 37945c44a897aa42a66adcab68f560e0
Size: 53624 bytes
Date of compilation October 22nd, 2017 2:31:37 AM

SHA256 579fd8a0385482fb4c789561a30b09f25671e86422f40ef5cca2036b28f99648
MD5: 1d724f95c61f1055f0d02c2154bbccd3
Size: 410760 bytes
Date of compilation: August 5th, 2014 4:54:45 PM

Network objects are enumerated to create tasks and files by using built-in logins and passwords:
At the end, the encryption process starts. It enumerates all the disks in the system from the letter C and then alphabetically 0x1F times. If it is a hard disk drive or a USB flash drive, then for each of them it runs a thread encrypting data with a specially generated key.

Each encryption thread recursively traverses the disk from the root and encrypts all files with extensions:
This will ignore the directories \Windows, \Program Files, \ProgramData, \AppData.

Another thread is also launched, creating the Readme.txt file in the root with the instructions. Thus, the Readme.txt file with the instruction is created even before the encryption has ended. At this stage, you can pull the encryption key out of memory OR disconnect the PC and give it to responders.

When encrypting the MBR and rewriting to its subroutine, the original bytes are copied, which allows them to be restored.
Each encrypted computer will have a unique key for input, which means that a unique wallet will also be generated. In this way they will be able to track payments and automatically issue a key. The sequence of characters entered on their site contains the necessary information for decryption.
Fraudsters are able to retrieve the original password from the ID only if they know corresponding private key.

How is the key formed:

With the CryptGenRandom() function, a sequence of 33 bytes consisting of random values is formed.

This sequence is then used as a password for generating the AES128 key. Files with known extensions will be encrypted with this key.

After this, the original sequence is encrypted with the fraudster's public key using the RSA2048 algorithm.
The Encrypted sequence, information about the local machine and information about the time zone are used to form the ID of the attacked computer. This ID is stored in the "Readme.txt" file, and is used later as an Installation key.

The ID is preceded by the following content:

"Oops! Your files have been encrypted. If you see this text, your files are no longer accessible. You might have been looking for a way to recover your files. Don't waste your time. No one will be able to recover them without our decryption service. We guarantee that you can recover all your files safely. All you need to do is submit the payment and get the decryption password.

Visit our web service at caforssztxqzf2nm.onion

Your personal installation key#2:"

Thus, a unique key is generated for each program launch. Therefore, each infected machine will generate its own key, and therefore its own wallet too. This means that the fraudster can control the receipt of funds from each "client" and issue a key automatically.

Victims have to inform fraudsters about this ID on the website "caforssztxqzf2nm.onion"

Comparison with NotPetya:

First of all, there are striking similarities in setting up privilege flags initializing with NotPetya, when researching BadRabbit malicious code:
However these functions match might be accidental and stronger arguments are needed.

Next in the code is checking of certain processes called. Their similarity is a serious reason to consider that BadRabbit and NotPetya were created by one person or at least this person had an access to NotPetya source.

This picture demonstrates the function of computing the hash sum on behalf of the process in NotPetya which is identical to BadRabbit. The only difference is that all the lines in BadRabbit widechar (2 bytes), and in case of BadRabbit the complier has decided to separate the function, additionally initialization vector has been changed from 0x12345678 to 0x87654321.
In both programs logs cleaning is conducted in similar ways:
As we can see similar checks and following PC shutdown are executed.

Also in both attacks modules are packed with zlib 1.2.8 in resources with one difference in BadRabbit which additionally xored them with constant 0xE9.

Based on disassembling and researching the code of BadRabbit we assume that BadRabbit was compiled from NotPetya source code as another project with several additions. Opposite to NotPetya in new project multibyte strings was set by default.

Analysis of caforssztxqzf2nm.onion:
This site was contains two JS scripts all_lib.js and all_js.js and the main page was updated on 19th October. Therefore, the site was developed 5 days before the attack.
Analysis of 1dnscontrol.com

This domain uses Bulletproof hosting Inferno. It was registered on March, 22nd in 2016 and is still active. There are several malicious domains linked to it and some of them were detected in 2011:

You can see that the threat actor used domains which were previously used in cybercriminal activity. It is possible that the domain was bought from the owner or control hijacked to launch the attack.

Compromised site analysis:

Researchers from ESET reported https://www.welivesecurity.com/2017/10/24/bad-rabbit-not-petya-back/ that compromised sites contained malicious code which collects User-agent, referrer, cookie and domain name and sends data to If victim was appropriate then malicious code was injected into page which interacts with 1dnscontrol.com.
There is old Apache JSP web server on this host. This program contains vulnerability through which attacker can gain control over it. Hacker group Lazarus used hosts with this web server in their attacks on banks.
Hi-Tech Crime Trends 2017
Group-IB forecasted these attacks just in our annual research – get full version for more trends and forecasts