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()
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.
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:
cmd.exe /c schtasks /Create /RU SYSTEM /SC ONSTART /TN rhaegal /TR %WinDir%\system32\cmd.exe /C Start \\ \%WinDir%\dispci.exe\ -id 848053675 && exit
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_
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):
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:
Using credentials dumped from the local host using CredEnumerateW()
Using credentials dumped from the local host using the Mimikatz-like binary
Using credentials chosen from the hardcoded list in the DLL
Using svcctl to attempt remote registry control
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.
Figure 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
Watch the screen capture: https://www.youtube.com/watch?v=XDWrnXbeH_Q
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:
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.
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)|
|Bad Rabbit DLL – dropped as infpub.dat|
|DiskCryptor Client – dropped as dispci.exe|
|DiskCryptor Driver (x32) – dropped as cscc.dat|
|DiskCryptor Driver (x64) – dropped as cscc.dat|
|Credential dumper (mimikatz-like, x32)|
|Credential dumper (mimikatz-like, x64)|
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.
Figure 5. Bad Rabbit Compromised Domains
Figure 6. Bad Rabbit Hash Values
Figure 7. Bad Rabbit IP Connections
Figure 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.
AI Engine Rule Import Procedure
Open the LogRhythm console. Navigate to the AI Engine tab via Deployment Manager > AI Engine Tab.
Select the pull-down menu “Actions,” and then select “Import.”
Select the .airx (AI Engine rule file format) files you wish to import, and select “Open.”
Upon a successful import, you will be presented with the following pop-up window:
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.
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
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.