What is this all about?
Earlier this week a new ransomware attack dubbed ‘Bad Rabbit’ broke out and has so far affected The Ukraine, Russia, Turkey and Bulgaria. Various healthcare, media, software and distribution companies and critical infrastructure, such as the Ukranian train services, Odessa airport and The Ukranian Ministries of Finance and Infrastructure all suffered down time.
What is the initial infection vector?
A drive-by-download type of attack, delivered mainly via popular Russian media sites, infects victims by tempting them to accept a fake Adobe Flash update. This is not a case of malvertising as our research indicates the tracker is embedded into the site code itself. Although the attack site is currently down, below is a partial list of the trackers that we can still see as active.
Is there a lateral movement activity?
It is important to note that there is no presence of the EternalBlue exploit used in previous ransomware attacks. However, there is evidence of Bad Rabbit using mimikatz tools to move across the network via SMB open shares.
Is this attack connected to Petya or NotPetya?
No. There is so far no connection between Petya or NotPetya as this attack is built on entirely new code base.
Please see below for a full flow of how Bad Rabbit operates.
The malware consists of the following modules:
|Credentials grabber, 32bit
|Credentials grabber, 64bit
||Legitimate signed file dcrypt.sys
||Legitimate signed file dcrypt.sys
The diagram below represents the overall malware flow of execution. An interactive version of this diagram can be found here.
The following contains a detailed technical explanation of each of Bad Rabbit module.
The Dropper module starts its execution by unpacking and running embedded an executable, which is run via `rundll32.exe` call.
The purpose of this unpacked DLL is to perform some preparatory actions before executing the main payload and setting up the driver.
Once executed, it initially checks if the directory `c:\Windows\cscc.dat` exists, if it is the case. If not then the process is terminated.
It then chooses the appropriate driver from within its embedded resource (32 or 64 bit versions) which is written to `c:\windows\cscc.dat`. The driver is executed via the service manager at the time of booting.
The main payload executable is then written to ‘C:\windows\dispci.exe’ Following a creation of a scheduled task named `rhaegal` which is used to execute it on every system restart using this command line:
schtasks /Create /RU SYSTEM /SC ONSTART /TN rhaegal /TR “C:\WINDOWS\system32\cmd.exe /C Start \”\” \”C:\Windows\dispci.exe\” -id %d && exit”
The -id argument in the above command line is set with randomly generated 4 bytes.
Following the dropper module, it schedules a system shutdown by creating yet another scheduled task named – `drogon` by using this command line.
schtasks /Create /SC once /TN drogon /RU SYSTEM /TR “C:\WINDOWS\system32\shutdown.exe /r /t 0 /f” /ST hh:mm:ss
It also deletes windows events and the USN drive c:\journal by using this command line.
wevtutil cl Setup & wevtutil cl System & wevtutil cl Security & wevtutil cl Application & fsutil usn deletejournal /D %c:
Once these actions are complete, the dropper deletes the `drogon` scheduled task and starts a separate thread in order to encrypt each of the system drives.
Finally, a file named ‘Readme.txt` is created which contains the ransom note:
A public RSA-2048 key is used in order to encrypt the drives. This key`s value is:
E5 C9 43 B9 51 6B E6 C4 31 67 E7 DE 42 55 6F 65
C1 0A D2 4E 2E 09 21 79 4A 43 A4 17 D0 37 B5 1E
8E FF 10 2D F3 DF CF 56 1A 30 BE ED 93 7C 14 D1
B2 70 6C F3 78 5C 14 7F 21 8C 6D 95 E4 5E 43 C5
71 68 4B 1A 53 A9 5B 11 E2 53 A6 E4 A0 76 4B C6
A9 E1 38 A7 1B F1 8D FD 25 4D 04 5C 25 96 94 61
57 FB D1 58 D9 8A 80 A2 1D 44 EB E4 1F 1C 80 2E
E2 72 52 E0 99 94 8A 1A 27 9B 41 D1 89 00 4C 41
C4 C9 1B 0B 72 7B 59 62 C7 70 1F 53 FE 36 65 E2
36 0D 8C 1F 99 59 F5 B1 0E 93 B6 13 31 FC 15 28
DA AD 1D A5 F4 2C 93 B2 02 4C 78 35 1D 03 3C E1
4B 0D 03 8D 5B D3 8E 85 94 A4 47 1D D5 EC F0 B7
43 6F 47 1E 1C A2 29 50 8F 26 C3 96 D6 5D 66 36
DC 0B EC A5 FE EE 47 CD 7B 40 9E 7C 1C 84 59 F4
81 B7 5B 5B 92 F8 DD 78 FD B1 06 73 E3 6F 71 84
D4 60 3F A0 67 06 8E B5 DC EB 05 7C 58 AB 1F 61
File extensions to be encrypted
BadRabbit can perform both encryption and decryption of the MBR and of system files. Below is the list of file extensions that are encrypted:
In order to spread across the network, Bad Rabbit enumerates all local subnet IP addresses and attempts to reach the following predefined SMB shares:
In order to authenticate to these network shares an embedded Mimikatz tool is utilized and the credentials retrieved by it is used for authentication.
Additionally a predefined set of usernames and passwords are also attempted as login credentials.
Once authenticated into a network share, the dropper will drop itself into it by copying these files:
These files are then remotely executed via the following WMI command:
c:\Windows\system32\wbem\wmic.exe process call create “C:\Windows\System32\rundll32.exe ” \”C:\Windows\%s\” #1″
The main module contains logic for both the encryption and decryption routines. It is able to decrypt files, however it does not encrypt them since this is done in the dropper itself. Instead, this module is used to encrypt the disk after the system reboot has taken place.
It interacts with a pre-loaded driver for files encryption via opening this device:
It then sends custom commands via `DeviceIOControl` in order to perform different actions which include:
||Lock memory previously allocated by VirtualAlloc
||Wipe passwords in memory
||Add randomness to the generator
||Start of encryption routine
It then enumerates all the system volumes while collecting the following information:
Mouse and keyboard hooks are then set in order to generate random values bases on mouse movements and key presses.
The module retrieves the boot device by querying for:
After this the previously created scheduled tasks named ‘rhaegal` and `drogon` are deleted.
Finally, the main module proceeds into the MBR replacement functionality in which it unpacks resources that contain a new MBR and 2nd stage loader. It then rewrites the old MBR with the new one. After which it starts the files encryption routine which is done by sending `DC_CTL_ENCRYPT_START` and `DC_CTL_ENCRYPT_STEP` commands to the previously installed driver and by using the same public key used by the dropper module.
Finally, the main module wipes passwords from memory with the same command request sent to the driver. It then executes shutdown.exe /r /t 0 /f to force system restart. It waits for five seconds and then creates a link to itself on the desktop: \\Desktop\\DECRYPT.lnk.
The new (malicious) MBR and two second stages loaders are present in the main module`s resources section and have the following IDs:
#define IDR_MBR 139
#define IDR_DCLDR 140
#define IDR_DCLDR_SMALL 141
There are two different passwords used to encrypt the files. In order to decrypt them, they should be entered one by one.
First, one should be entered at system boot. The second one is used to decrypt the files with the mentioned extensions and is entered after the system boots successfully. The malware module then enumerates files and decrypts them one by one.
The driver being used by Bad Rabbit for encryption is a part of an open source utility called `DiskCryptor`.
The DiskCryptor driver embedded in the malware is a completely legitimate binary and is signed with a digital certificate:
As part of the driver installation, the following registry changes take place.
These changes ensure that the following system files are also encrypted:
Further, if someone decides to analyze the malware via crashing the system and further obtaining the generated crash dump, this attempt will fail because crash dumps will be also encrypted due to the set filter.
||possible adware dropper of the malware
Petya overview on Check Point blog:
Warnings about the Bad Rabbit attack:
DiskCryptor main page and source code:
Visual overview along with technical details from Check Point: