Bad Rabbit Ransomware Technical Analysis

Update: Further analysis of the code revealed new information regarding the spread of Bad Rabbit across the network. This post has been updated to reflect this new information.

Bad Rabbit Ransomware Background

On the afternoon of October 24, 2017 (BST), a new strain of ransomware, dubbed “Bad Rabbit,” emerged. Early reports have indicated the strain initially targeted the Ukraine and Russia. Group-IB, a Russian Company, first broke the news and reported rapid infection rates as the new strain started to spread. Later reports from Kaspersky confirmed the spread to other parts of Eastern Europe.

The initial infection vector was reported to be a collection of compromised websites that redirected users to another site that was hosting the malicious software. Researchers at Cisco Talos reported that the site 1dnscontrol[.]com hosted the Bad Rabbit dropper in the path /flash_install.php on the server. The malicious download, masked as an Adobe Flash Player update, required user action for infection.

Currently, the original infrastructure used to distribute the malicious files appears to be down. But these, or other websites, hosting the malware could be activated again at any time, so it is important to implement prevention measures and educate users on the Bad Rabbit threat.

Bad Rabbit Ransomware Analysis

The execution of Bad Rabbit reveals several similarities between the ransomware and the behavior of the destructive NotPetya malware discovered in June of this year. The binary Bad Rabbit sample analyzed in this report was SHA-256 579fd8a0385482fb4c789561a30b09f25671e86422f40ef5cca2036b28f99648, while the NotPetya sample analyzed in our previous threat intelligence report was SHA-256 027cc450ef5f8c5f653329641ec1fed91f694e0d229928963b30f6b0d7d3a745.

A comparison of the two samples reveals a great deal of identical code overlap. Although this suggests code reuse, it cannot be confirmed whether the same actors responsible for NotPetya were responsible for the creation of Bad Rabbit.

Despite the code similarities, the two samples demonstrated many functional differences. Similarities and differences between the two samples are detailed below.

Significant Code Similarities

  • The use of the SMB credential harvesting method using the Windows API CredEnumerateW() as well as a version of the Mimikatz tool.
    Figure 1. NotPetya vs Bad Rabbit SMB credential harvesting via Windows API CredEnumerateW()

    Figure 1. NotPetya vs Bad Rabbit SMB credential harvesting via Windows API CredEnumerateW()

  • Method of infection:

    • Dumping SMB credentials from the local host

    • Enumerating network hosts using Windows API calls such as NetServerEnum()

    • Determining DHCP servers and enumerating subnets and subnet clients defined on those servers

    • Testing each host’s 139 and 445 ports for write access

  • Upon identification of a vulnerable host, both connect to the admin$ share of the remote system and perform the following:

    • Check for one or more files, subsequently writing them to the %WinDir% of the remote host if found
  • Both attempt remote registry access control to Windows service functions.

  • Both samples contain additional tools embedded as zlib-compressed (v. 1.2.8) resources in the binaries; however, Bad Rabbit additionally XOR encrypts the resources with 0xED prior to compression.

  • Both samples have the ability to clear Windows event logs and delete the USN journal using the utilities wevutil and fsutil.

  • Most interestingly, the two samples used the same algorithm for encryption of process names to check for particular antivirus products, although the functions were structured slightly differently and used a different seed (0x87654321 vs. 0x12345678). Further analysis is required to determine what these names decrypt to and how they are used.

0x87654321 vs. 0x12345678

Figure 2. NotPetya vs. Bad Rabbit Encrypted Process Name Comparison

Significant Code Differences

  • Unlike NotPetya, Bad Rabbit uses the legitimate program DiskCryptor for full disk encryption, similar to the Mamba ransomware.

  • Bad Rabbit does not enumerate partition information in order to overwrite the MFT.

  • Bad Rabbit does not contain the wiping functionality of NotPetya, nor the custom bootloader.

  • Bad Rabbit does not utilize the EternalBlue SMBv1 exploit or subsequently use psexec to infect remote systems.

  • Bad Rabbit additionally uses UPnP to further fingerprint the remote system and determine available services.

  • Bad Rabbit contains a hardcoded list of usernames and passwords used to try to brute force SMB logons on the local network.

  • If installation and execution of a service on the remote host via svcctl fails, Bad Rabbit attempts to use WMI to infect the remote system.

EternalBlue and EternalRomance both exploit the vulnerability addressed in Microsoft Bulletin MS17-010 that targets SMBv1. LogRhythm Labs analysts believe, but have not definitively verified, that Bad Rabbit reportedly makes use of the EternalRomance exploit as described in the Cisco Talos report referenced earlier. While EternalRomance makes use of the same vulnerability as EternalBlue, it exploits the vulnerability in a different way. One public implementation of the EternalRomance exploit referenced by Talos works by crafting a custom transaction over SMB. If this transaction is crafted properly, the response is expected to contain leaked kernel pool data that can be exploited to open a named pipe over the IPC$ share that allows remote access to the host.

Summary of Execution

Upon execution, the dropper creates the DLL file %WinDir%\infpub.dat extracted from its resource section. This DLL is then executed by the dropper from its first ordinal, just as we saw with NotPetya, using the following command:

C:\Windows\system32\rundll32.exe C:\Windows\infpub.dat,#1 15

The “#1” in the above command represents the ordinal executed, and “15” is an argument passed to the DLL, which is used throughout the program as a seed value.

The Bad Rabbit DLL infpub.dat then creates the following files:

At least two scheduled tasks are created to ensure the execution of the encryption, but the DLL first attempts to delete the DiskCryptor client task named “rhaegal” (in case it is already installed) using the following command:

cmd.exe /c schtasks /Delete /F /TN rhaegal

The two scheduled tasks are then created as follows:

  1. cmd.exe /c schtasks /Create /RU SYSTEM /SC ONSTART /TN rhaegal /TR %WinDir%\system32\cmd.exe /C Start \\ \%WinDir%\dispci.exe\ -id 848053675 && exit

  2. cmd.exe /c schtasks /Create /SC once /TN drogon /RU SYSTEM /TR %WinDir%\system32\shutdown.exe /r /t 0 /f /ST ::

The time, denoted by “::”, is calculated as an offset from the current system time. Artifacts of the deletion and creation of these tasks can also be detected in the registry and using SysMon.

A third set of scheduled tasks, named “viserion_", were also observed during the course of analysis, but the significance was not determined. The tasks were short-lived, each created with incrementing numbers beginning with one (i.e., "viserion_1") and quickly deleted as a new task was created with the incremented value.

A service named “cscc” is then created and configured to start the DiskCryptor driver cscc.dat on boot. The service is registered as a Filter driver dependent on the FltMgr service. The malware also installs itself as a DumpFilter in the HKLM\SYSTEM\CurrentControlSet\Control\CrashControl registry key. This action ensures the driver will load upon a system crash. Additionally, the malware is configured to add the cscc service to the following registry keys hardcoded in the binary:



The malware then drops the Mimikatz-like binary to the %WinDir% directory from its resources section, with a four-character alpha-numeric filename and “.tmp” extension. Using the CoCreateGuid() API call, Bad Rabbit creates a unique ID used for a named pipe to assist in communication. The malware then executes the Mimikatz-like binary, as shown in the following example (note: the file name and pipe GUID will vary per execution):

C:\Windows\6ADA.tmp \\.\pipe\{F2B88356-9E50-4107-939C-9ED2CFB4C489}

After harvesting credentials, the malware then attempts to enumerate all vulnerable hosts on the network using the methods previously discussed. Once network hosts are identified, the malware attempts to connect to the remote systems in one of several ways:

  1. Using credentials dumped from the local host using CredEnumerateW()

  2. Using credentials dumped from the local host using the Mimikatz-like binary

  3. Using credentials chosen from the hardcoded list in the DLL

  4. Using svcctl to attempt remote registry control

  5. Using the EternalRomance exploit to gain access without valid credentials (unconfirmed)

Once the malware has gained access to the remote host, it checks for the existence of two files in %WinDir%: cscc.dat and infpub.dat. If these files are not found, the malware attempts to create them on the remote system. At the same time, the Bad Rabbit DLL will also attempt to create the service described previously on the remote system using the svcctl remote service control functionality of Windows. If the malware fails to install and start the service on the remote host, it will attempt to use WMI to remotely execute the malware. Each infected host will perform the same enumeration of the network and attempt to spread to all known hosts using these methods.

Once the time for the scheduled task drogon is reached, the system shuts down, rebooting to a custom MBR that displays a ransom note. The ransom note shown below, similar to that of NotPetya, advises the victim to connect to a Tor hidden service for remittance.

Bad Rabbit Ransom NoteFigure 3. Bad Rabbit Ransom Note

The Tor hidden service displays a dynamically resolving site that repeats the ransom demand.

Figure 4: Video of the Tor Hidden Service Site Generating Figure 4. Video of the Tor Hidden Service Site Generating

Watch the screen capture:

When the malware was initially discovered on Tuesday October 24th, the ransom demanded 0.05 BTC (about $295) and was set to increase after 40 hours have passed. As of Thursday October 26th, the ransom has increased to 0.1 BTC (about $591) and is set to increase again after another set of time.

It is not definitively known if the files can be recovered after the ransom is paid, so the usual recommendations for defending against and remediating ransomware still apply.

Security Recommendations for Mitigating Bad Rabbit Ransomware

As with most malware mitigations, regular system backups and patch management are the most useful measures in preventing widespread damage from ransomware. Maintaining good security measures such as password complexity enforcement, security product maintenance, and limiting user privileges also help to defend against attacks. Security measures, specific to Bad Rabbit, include:

  • Patching:

    • Due to the capacity to spread internally over SMB, it is important that any users with administrative access on the domain keep up to date on software patches as they come available and minimize their footprint on the network.

    • As Bad Rabbit can use WMI for remote execution, it is imperative to evaluate the administrative rights of users with access to the system. Users who do not require administrative rights should be removed from the membership of such groups.

    • Bad Rabbit still contains functionality to spread via the EternalRomance SMB exploit, so it is imperative to patch the vulnerability fixed in security update MS17-10 as soon as possible.

  • Use of advanced monitoring tools:

    • Employing a tool that can monitor and verify the integrity of the MBR on the system can prevent its manipulation. If you are a LogRhythm customer, please reference the Appendix or the Community to access AI Engine and NetMon DPA rules to help you detect these threats.

Final Thoughts

Although the actors and motivation behind these attacks have not been definitively determined, LogRhythm Labs analysts have come to some conclusions. Due to the seemingly targeted attacks on Russia and the Ukraine, these attacks may not have intended to spread beyond these regions. Also, given the large overlap of code between the Bad Rabbit samples in this attack and the NotPetya samples seen in June of this year, it seems plausible that the same authors could be behind both attacks. Even though Bad Rabbit did not cause mass, widespread damage like NotPetya, incidents such as these still serve as a reminder of the importance of sound security practices.

Appendix A: IOCs

Dropper - Adobe_Flash_Player.exe (originally Flashutil.exe)
MD5 1d724f95c61f1055f0d02c2154bbccd3
SHA-256 630325cac09ac3fab908f903e3b00d0dadd5fdaa0875ed8496fcbb97a558d0da
Bad Rabbit DLL – dropped as infpub.dat
MD5 fbbdc39af1139aebba4da004475e8839
SHA-256 579fd8a0385482fb4c789561a30b09f25671e86422f40ef5cca2036b28f99648
DiskCryptor Client – dropped as dispci.exe
MD5 b14d8faf7f0cbcfad051cefe5f39645f
SHA-256 8ebc97e05c8e1073bda2efb6f4d00ad7e789260afa2c276f0c72740b838a0a93
DiskCryptor Driver (x32) – dropped as cscc.dat
MD5 b4e6d97dafd9224ed9a547d52c26ce02
SHA-256 682adcb55fe4649f7b22505a54a9dbc454b4090fc2bb84af7db5b0908f3b7806
DiskCryptor Driver (x64) - dropped as cscc.dat
MD5 edb72f4a46c39452d1a5414f7d26454a
SHA-256 0b2f863f4119dc88a22cc97c0a136c88a0127cb026751303b045f7322a8972f6
Credential dumper (mimikatz-like, x32)
MD5 37945c44a897aa42a66adcab68f560e0
SHA-256 2f8c54f9fa8e47596a3beff0031f85360e56840c77f71c6a573ace6f46412035
Credential dumper (mimikatz-like, x64)
MD5 347ac3b6b791054de3e5720a7144a977
SHA-256 301b905eb98d8d6bb559c04bbda26628a942b2c4107c07a02e8f753bdcfe347c
Hardcoded Usernames
Hardcoded Passwords

Appendix B: AI Engine Rules and NetMon Queries

AI Engine Rules

The following are screenshots of AI Engine rules that can be deployed to detect specific Bad Rabbit IOCs. The exported rules are attached to the end of this blog post along with a NetMon DPA rule.

Bad Rabbit Compromised DomainsFigure 5. Bad Rabbit Compromised Domains

Bad Rabbit Hash ValuesFigure 6. Bad Rabbit Hash Values

Bad Rabbit IP ConnectionsFigure 7. Bad Rabbit IP Connections

Bad Rabbit Malware File NamesFigure 8. Bad Rabbit Malware File Names

AI Engine Rules for LogRhythm Customers

In our ongoing effort to analyze and respond to Bad Rabbit, we’ve created a set of exported rules for our customers. Following are step-by-step instructions for importing the rules into your LogRhythm environment. Download the AI Engine Rules

AI Engine Rule Import Procedure

Open the LogRhythm console. Navigate to the AI Engine tab via Deployment Manager > AI Engine Tab.

AI Engine TabSelect the pull-down menu “Actions,” and then select “Import.”

Pull-Down Menu > Actions > Import

Select the .airx (AI Engine rule file format) files you wish to import, and select “Open.”

Import .airx FilesUpon a successful import, you will be presented with the following pop-up window:

Rule Import Confirmation

It is possible that an error will appear stating that the KB version is out of date with the AI Engine rules selected for import. If this occurs, upgrade your KB to the latest version, and perform this procedure again.

NetMon Queries

The following NetMon query will tailor the dashboard to identify instances of Bad Rabbit moving laterally. The query is designed for a NetMon dashboard and will display the establishment of an SMB connection, transmitting either a Bad Rabbit encryption or Mimikatz executable.

Application:smb AND Path:%$ AND Filename:cscc.dat OR infpub.dat

Download the AI Engine Rules


Thanks to LogRhythm Labs team members Erika Noerenberg, Andrew Costis, Nathanial Quist, and Brian Coulson for their continued work analyzing and reporting on Bad Rabbit ransomware.