Bad Rabbit ransomware

UPDATE 27.10.2017. Decryption opportunity assessment. File recovery possibility. Verdicts

What happened?

On October 24th we observed notifications of mass attacks with ransomware called Bad Rabbit. It has been targeting organizations and consumers, mostly in Russia but there have also been reports of victims in Ukraine. Here’s what a ransom message looks like for the unlucky victims:

What is Bad Rabbit?

Bad Rabbit is a previously unknown ransomware family.

How is Bad Rabbit distributed?

The ransomware dropper was distributed with the help of drive-by attacks. While the target is visiting a legitimate website, a malware dropper is being downloaded from the threat actor’s infrastructure. No exploits were used, so the victim would have to manually execute the malware dropper, which pretends to be an Adobe Flash installer. However, our analysis confirmed that Bad Rabbit uses the EternalRomance exploit as an infection vector to spread within corporate networks. The same exploit was used in the ExPetr.

We’ve detected a number of compromised websites, all of which were news or media websites.

Whom does it target?

Most of the targets are located in Russia. Similar but fewer attacks have also been seen in other countries – Ukraine, Turkey and Germany. Overall, there are almost 200 targets, according to the KSN statistics.

Since when does Kaspersky Lab detect the threat?

We have been proactively detecting the original vector attack since it began on the morning of October 24. The attack lasted until midday, although ongoing attacks were detected at 19.55 Moscow time. The server from which the Bad rabbit dropper was distributed went down in the evening (Moscow time).

How is it different to ExPetr? Or it is the same malware?

Our observations suggest that this been a targeted attack against corporate networks, using methods similar to those used during the ExPetr attack. What’s more, the code analysis showed a notable similarity between the code of ExPetr and Bad Rabbit binaries.

Technical details

According to our telemetry, the ransomware is spread via a drive-by attack.

The ransomware dropper is distributed from hxxp://1dnscontrol[.]com/flash_install.php

Also according to our telemetry data, victims are redirected to this malware web resource from legitimate news websites.

The downloaded file named install_flash_player.exe needs to be manually launched by the victim. To operate correctly, it needs elevated administrative privileges which it attempts to obtain using the standard UAC prompt. If started, it will save the malicious DLL as C:\Windows\infpub.dat and launch it using rundll32.

Pseudocode of the procedure that installs the malicious DLL

infpub.dat appears to be capable of brute-forcing NTLM login credentials to Windows machines that have pseudo-random IP addresses.

The hard-coded list of credentials

infpub.dat will also install the malicious executable dispci.exe into C:\Windows and create a task to launch it.

Pseudocode of the procedure that creates the task which launches the malicious executable

What’s more, infpub.dat acts as a typical file encrypting ransomware: it finds the victim’s data files using an embedded extension list and encrypts them using the criminal’s public RSA-2048 key.

The public key of the criminals and the extension list

The criminal’s public key parameters:

Public-Key: (2048 bit)
Exponent: 65537 (0x10001)

The executable dispci.exe appears to be derived from the code base of the legitimate utility DiskCryptor. It acts as the disk encryption module which also installs the modified bootloader and prevents the normal boot-up process of the infected machine.

An interesting detail that we noticed when analyzing the sample of this threat: it looks like the criminals behind this malware are fans of the famous books & TV show series Game Of Thrones. Some of the strings used throughout the code are the names of different characters from this series.

Dragon names from Game Of Thrones

Character name from Game Of Thrones

Encryption scheme

As we mentioned, the Bad Rabbit ransomware encrypts a victim’s files and disk. Files are encrypted with the following algorithms:

  1. AES-128-CBC
  2. RSA-2048

It is a default encryption scheme for ransomware.

An interesting fact is that the ransomware enumerates all running processes and compares the hashed name of each process with embedded hash values. It is important to mention that the hashing algorithm is similar to the ExPetr one.

Comparing of Bad Rabbit and ExPetr hashing routines


Special branch


Runtime flags initialization routine

The full list of embedded hashes of process names:

Hash Process name
0x4A241C3E dwwatcher.exe
0x923CA517 McTray.exe
0x966D0415 dwarkdaemon.exe
0xAA331620 dwservice.exe
0xC8F10976 mfevtps.exe
0xE2517A14 dwengine.exe
0xE5A05A00 mcshield.exe

The partitions on the victim’s disks are encrypted with the help of the DiskCryptor driver dcrypt.sys (which is installed into C:\Windows\cscc.dat). The ransomware sends the necessary IOCTL codes to this driver. Some functions are taken as is from the sources of DiskCryptor (drv_ioctl.c), others seem to be implemented by the malware developers.

The disk partitions on the infected machine are encrypted by the DiskCryptor driver using the AES cipher in XTS mode. The password is generated by dispci.exe using the WinAPI function CryptGenRandom and has a length of 32 symbols.

Decryption opportunity assessment

Unlike ExPetr, the evidence suggests that Bad Rabbit is not intended as a wiper. Previously, in our article we wrote that the threat actors behind ExPetr were technically unable to decrypt MFT that was encrypted with the GoldenEye component. In the case of Bad Rabbit, however, the malware algorithm suggests that the threat actors have the technical means to decrypt the password necessary for disk decryption.

The data shown on the screen of an infected machine as “personal installation key#1” is an encrypted by RSA-2048 and base64-encoded binary structure that contains the following information gathered from the infected system:

The threat actors can use their own private RSA key to decrypt this structure. After decryption they can send this information to the victim.

Please note that, despite what it says in other vendors’ reports, the value of the id field which is passed to dispci.exe is just a 32-bit number used to distinguish different infected machines, and not the AES key which is used for disk encryption.

As part of our analysis, we extracted the password generated by the malware during a debugging session and attempted to enter this password when the system was locked after reboot. The password indeed worked and the boot-up process continued.

Unfortunately, we have to conclude that at this point there’s no way to decrypt disk and victim files without the threat actor’s RSA-2048 private key. The symmetric encryption keys are securely generated on the ransomware side which makes attempts to guess the keys unfeasible in practice.

However, we found a flaw in the code of dispci.exe: the malware doesn’t wipe the generated password from the memory, which means that there is a slim chance to extract it before the dispci.exe process terminates. In the picture below, note that while the variable dc_pass (which will be passed to the driver) is securely erased after use, that’s not the case for the variable rand_str which holds the original copy of the password.

Pseudocode of the procedure that generates the password and encrypts the disk partitions

File encryption

As we wrote before, the trojan uses a common file encryption scheme. It generates a random 32-bytes-length string and uses it in the key derivation algorithm. Unfortunately, the trojan uses the CryptGenRandom function when generating this string.

Key derivation algorithm

The encrypted password, along with information about the infected system is written into Readme file as “personal installation key#2”.

Ransom note creation routine

An interesting fact is that the trojan cannot encrypt files which have a Read-only attribute.

File recovery possibility

We have discovered that Bad Rabbit does not delete shadow copies after encrypting the victim’s files. It means that if the shadow copies had been enabled prior to infection and if the full disk encryption did not occur for some reason, then the victim can restore the original versions of the encrypted files by the means of the standard Windows mechanism or 3rd-party utilities.

Shadow copies remain unharmed by Bad Rabbit


Kaspersky Lab corporate customers are also advised to:

  • make sure that all protection mechanisms are activated as recommended; and that KSN and System Watcher components (which are enabled by default) are not disabled.
  • update the antivirus databases immediately.

The abovementioned measures should be sufficient. However, as additional precautions we advise the following:

  • restricting execution of files with the paths c:\windows\infpub.dat and C:\Windows\cscc.dat in Kaspersky Endpoint Security.
  • configuring and enabling Default Deny mode in the Application Startup Control component of Kaspersky Endpoint Security to ensure and enforce proactive defense against this and other attacks.

Kaspersky Lab products detect this threat with the following verdicts:

  • Trojan-Ransom.Win32.Gen.ftl
  • Trojan-Ransom.Win32.BadRabbit
  • DangerousObject.Multi.Generic
  • PDM:Trojan.Win32.Generic

fbbdc39af1139aebba4da004475e8839 – install_flash_player.exe
1d724f95c61f1055f0d02c2154bbccd3 – C:\Windows\infpub.dat
b14d8faf7f0cbcfad051cefe5f39645f – C:\Windows\dispci.exe


Related Posts

There are 4 comments
  1. just4u2know

    Not sure,
    perhaps legit

    v4 = “please accept source –>

    if v4 = accepted source

    need to differ 0

    else no random string
    Kaspersky Lab experts are working on a detailed analysis of multibyte2wide to find possible flaws in its cryptographic routines.

    sorry for nag

  2. Fola Bolodeoku

    As part of the full list of embedded hashes of process names, I see three McAfee Endpoint Security 10.x processes (0xE5A05A00 mcshield.exe {McAfee Scanner Service}; 0xC8F10976 mfevtps.exe {McAfee Process Validation Service}; 0x923CA517 McTray.exe {McTray Application}), kindly clarify what role they play Runtime flags initialization routine.

  3. FRBA


  4. Chris

    Normally, WMI is subject to UAC-filtering. Is BadRabbit able to spread to another machine when it’s run by a local administrator (not domain user or local “administrator”)?

Leave a Reply to Fola Bolodeoku Cancel Reply

Your email address will not be published. Required fields are marked *