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.
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.
Figure 1. NotPetya vs Bad Rabbit SMB credential harvesting via Windows API CredEnumerateW()
Figure 2. NotPetya vs. Bad Rabbit Encrypted Process Name Comparison
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.
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:
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:
HKLM\System\CurrentControlSet\Control\CLASS\{71A27CDD-812A-11D0-BEC7-08002BE2092F}\LowerFilters
HKLM\System\CurrentControlSet\Control\CLASS\{4D36E965-E325-11CE-BFC1-08002BE10318}\UpperFilters
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:
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.
The Tor hidden service displays a dynamically resolving site that repeats the ransom demand.
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.
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:
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.
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 | |||
---|---|---|---|
Administrator Admin Guest User User1 user-1 Test root buh | boss ftp rdp rdpuser rdpadmin manager support work otheuser | operator backup asus ftpuser ftpadmin nas nasuser nasadmin | superuser netguest alex administrator guest user adminTest test |
Hardcoded Passwords | ||||
---|---|---|---|---|
123 1234 12345 123456 | Guest123 guest123 User123 user123 | 77777 777 qwe qwe123 | zxc123 zxc321 zxcv uiop |
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.
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.
Open the LogRhythm console. Navigate to the AI Engine tab via Deployment Manager > AI Engine Tab.
Select the .airx (AI Engine rule file format) files you wish to import, and select “Open.”
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.
With the rise of deepfake technology, the financial sector faces a new and growing threat…
The cybersecurity industry is experiencing significant shifts in 2024. LogRhythm’s State of the Security Team…
The output of a security and information event management (SIEM) platform is only as good…