Threat Spotlight: Bad Rabbit Ransomware

Introduction

After the very public Petya-Like attack that occurred in June, a new and remarkably similar ransomware has been observed spreading in the wild throughout Russia, Ukraine, and several other countries. Bad Rabbit, as it is known, was initially spread via drive-by downloads, but also contains the ability to propagate via SMB, as well as encrypting files and preventing an infected system from booting properly.

Impact

Bad Rabbit is a nasty ransomware in that it not only modifies files, but also the underlying filesystem and master boot record (MBR). It will harvest credentials using Mimikatz and attempt brute-force logins to propagate using SMB. Once it is active within an organization it will typically spread successfully and rapidly, rendering the system completely inoperable in the process.

Technical Analysis

Overview

The malware comprises a dropper that drops and executes the main payload DLL, which also contains several additional components:

  • Dropper (install_flash_player.exe)
  • Main payload DLL (infpub.dat)
  • Ransomware component (dispci.exe)
  • Mimikatz for x86 and x64
  • Legitimate DiskCryptor drivers for x86 and x64 (C:\Windows\cscc.dat)

Dropper

The dropper is a fake Adobe Flash installer ("install_flash_player.exe",
SHA256: 630325cac09ac3fab908f903e3b00d0dadd5fdaa0875ed8496fcbb97a558d0da). In an attempt to evade detection by antivirus products, the executable has been signed using a digital certificate borrowed from another (legitimate) executable.

Checking the file properties, we can immediately see it's invalid:

Figure 1. Invalid file signing on the dropper

The manifest directives embedded within the executable cause Windows to request elevated runtime privileges. The failed validation causes the "Publisher" field on the UAC consent dialog to show as "Unknown". Tools such as SigThief make it trivial to splice a certificate onto an executable or DLL.

Figure 2. Unknown publisher in UAC dialog

Once active, the first task is to decompress the 371,619 bytes of overlay data using zlib 1.2.8. The decompressed buffer is written to disk as C:\Windows\infpub.dat (SHA256: 579fd8a0385482fb4c789561a30b09f25671e86422f40ef5cca2036b28f99648). Despite the misleading name, the file is actually a Windows DLL with 2 exports, which is also fake-signed with the same Symantec certificate.

Control is now passed over to "infpub.dat" by way of export ordinal #1, together with argument "15." 

Figure 3. rundll32.exe command line to execute the dropper

Payload

Similar to NotPetya, the code attempts to enable 3 process privileges: SeShutdownPrivilege, SeDebugPrivilege, SeTcbPrivilege. Depending on the outcome, a global flag is set which controls various executions paths later on.

Another similarity to NotPetya is the detection of antivirus processes by Xor'ing of process names with a constant and comparing against a set of known values. In Bad Rabbit the Xor constant has been flipped (0x87654321 vs 0x12345678):

Figure 4.

The detection routine is a little more thorough this time, checking for seven (mainly McAfee) specific processes, vs. three for NotPetya:

Figure 5. Check for McAfee processes

Analysis indicates the constants map to the following values:

        4A241C3Eh: dwwatcher.exe

        923CA517h: McTray.exe

        966D0415h: dwarkdaemon.exe

        AA331620h: dwservice.exe

        C8F10976h: mfevtps.exe

        E2517A14h: dwengine.exe

        E5A05A00h: mcshield.exe

An already-publicized inoculation against Bad Rabbit is the creation of "c:\windows\cscc.dat". This is the file name of the DiskCryptor kernel mode driver written to disk by Bad Rabbit during execution. If the file is found on disk, the process will terminate before any file or disk encryption takes place.

If running as a 32-bit process, embedded resource #7 is decompressed and written to disk. Similarly, if running as 64-bit, embedded resource #8 is used. The decompressed buffer is written as "c:\windows\cscc.dat":

32-bit DiskCryptor/cscc.dat = b4e6d97dafd9224ed9a547d52c26ce02
64-bit DiskCryptor/cscc.dat = edb72f4a46c39452d1a5414f7d26454a

Embedded resource #9 is decompressed and written to disk as "c:\windows\dispci.exe". We believe this file is responsible for performing encryption of the MBR (analysis is ongoing).


Figure 6. Dropping components

The DiskCryptor component, cscc.dat, is registered as a boot-time driver:

Figure 7. Boot-time driver cscc

After dropping the components, the malware adds a scheduled task for System Reboot:

Figure 8. Scheduled task to reboot the system

A second scheduled task will execute the ransomware payload at system startup:

Figure 9. Scheduled task to start the ransomware payload on reboot

The ransomware encrypts files using a randomly generated 128-bit AES key, which is encrypted with an RSA 2048-bit public key embedded in the malware. The following extensions are targeted:

.3ds.7z.accdb.ai.asm.asp.aspx.avhd.back.bak.bmp.brw.c.cab.cc.cer.cfg.conf.cpp.crt.cs.ctl.cxx.dbf.der.dib.disk.djvu.doc.docx.dwg.eml.fdb.gz.h.hdd.hpp.hxx.iso.java.jfif.jpe.jpeg.jpg.js.kdbx.key.mail.mdb.msg.nrg.odc.odf.odg.odi.odm.odp.ods.odt.ora.ost.ova.ovf.p12.p7b.p7c.pdf.pem.pfx.php.pmf.png.ppt.pptx.ps1.pst.pvi.py.pyc.pyw.qcow.qcow2.rar.rb.rtf.scm.sln.sql.tar.tib.tif.tiff.vb.vbox.vbs.vcb.vdi.vfd.vhd.vhdx.vmc.vmdk.vmsd.vmtm.vmx.vsdx.vsv.work.xls.xlsx.xml.xvd.zip

Files under the following directories will not be encrypted:

  • \AppData
  • \ProgramData
  • \Program Files
  • \Windows

The Unicode string “encrypted” is appended along with key information to each encrypted file.

Figure 10. Key information appended to an encrypted file

The malware then drops a ransom note to C:\Readme.txt:

Figure 11. Ransom note

Bootloader

The bootloader component looks substantially different from NotPetya, with the kernel code and data residing at the end of the disk, and the MBR loader appearing to be somewhat more advanced:

Figure 12. MBR entry point

The MBR and kernel seem to be based on code used in the open source project Disk Cryptor:

Figure 13. Comparison of BootLoader for Bad Rabbit (left) and Disk Cryptor (right)

Once the system is rebooted, the ransom boot-locker screen is displayed, containing the user’s personal key and a website to visit in order to obtain a password to unlock the system:

Figure 14. Boot-locker screen

Payment

As shown above, payment instructions are contained both in the initial C:\Readme.txt ransom note and on the post-reboot screen. These instructions include directions to an .onion webpage http [://] caforssztxqzf2nm [dot] onion (accessible via the TOR browser), a unique 365 character “personal installation key” required to generate your decryption key, and assurances that once payment is received via BitCoin you will receive the required password necessary to decrypt your drive.

The final line has a text input section to allow you to manually type your decryption key “Password #1” that you (should) receive after they have received payment. The requested ransom amount of 0.05 bitcoins currently equates to about $274 / €233 / к15853.

style="text-align:center"

Figure 15. The Bad Rabbit payment site

The payment page is located on a dark web server, accessible via the TOR browser (hxxps://www (dot) torproject.org/projects/torbrowser (dot) html). On the right-hand side of the page you see a countdown timer, which has been steadily decreasing towards zero since the initial outbreak. This suggests that once this timer hits zero, the requested ransom payment amount will increase, but the rate at which it will do so is unspecified.

This behavior is a common “pressure” tactic employed by ransomware gangs to push those affected into paying immediately rather than waiting to see if weaknesses can be found in the encryption application by researchers enabling decryption without payment.

As of midday GMT, this site became inaccessible. This could be due to a number of reasons, ranging from amount of traffic from both those infected attempting to make payment, from media interests and the security research community or malicious actors conducting a DDoS attack on the site. 

Propagation

Bad Rabbit spreads through local shares, but unlike Petya-Like/NotPetya, there is no evidence to suggest that the malware is using any of the Eternal* exploits for propagation. Instead, an embedded list of usernames and passwords is used in order to bruteforce access to the shares.

First, the malware performs ARP scanning on the local network to discover all active hosts:

Figure 16. ARP scanning

The malware then cycles through LAN IP addresses attempting to connect to open SMB ports.

Figure 17. Checking for SMB ports

For each host with open SMB port, the malware will try to authenticate using a combination of usernames and passwords from a hardcoded list.

Figure 18. Passwords

It will then try to connect to one of the following services on the SMB share:

  • admin
  • atsvc
  • browser
  • eventlog
  • lsarpc
  • netlogon
  • ntsvcs
  • spoolss
  • samr
  • srvsvc
  • scerpc
  • svcctl
  • wkssvc

Upon successful connection, the malware will attempt to copy both cscc.dat and infpub.dat to that share, and run the payload using WMIC command:

  • process call create "C:\Windows\System32\rundll32.exe \"C:\Windows\%s\" #1

Figure 19. Procmon Output Showing Transfer of cscc.dat and infpub.dat

Conclusion

At a code level, Bad Rabbit shares many similarities with the recent Petya-Like/NotPetya attack, and there are strong indications that the same author is involved. From a technical perspective, Bad Rabbit is a far more complete and functional ransomware than NotPetya, and relies on the slightly more robust TOR service to provide decryption keys and payment information, and therefore appears to be a fully functional ransomware.

To restate what we said above, a few of the key differences between Bad Rabbit and NotPetya are that there is no evidence to suggest that the Bad Rabbit malware is using any of the Eternal* exploits for propagation. Instead, an embedded list of usernames and passwords is used in order to bruteforce access to the shares, alongside harvested credentials from Mimikatz.

Cylance researchers will continue to analyze this threat over the coming days to determine whether there are implementation weaknesses in the encryption process that can be leveraged to decrypt users' data.

If you use our endpoint protection product CylancePROTECT®, you were already protected from this attack. If you don't have CylancePROTECT, contact us to learn how our AI-driven solution can predict and prevent unknown and emerging threats.

Indicators of Compromise (IoCs)

Filenames

C:\Windows\cscc.dat

C:\Windows\infpub.dat

C:\Windows\dispci.exe

Network

(hxxp://) 1dnscontrol.com/flash_install (dot) php

SHA256

630325cac09ac3fab908f903e3b00d0dadd5fdaa0875ed8496fcbb97a558d0da – Dropper

579fd8a0385482fb4c789561a30b09f25671e86422f40ef5cca2036b28f99648 – Payload DLL

2f8c54f9fa8e47596a3beff0031f85360e56840c77f71c6a573ace6f46412035 – Mimikatz x86

301b905eb98d8d6bb559c04bbda26628a942b2c4107c07a02e8f753bdcfe347c – Mimikatz x64

682adcb55fe4649f7b22505a54a9dbc454b4090fc2bb84af7db5b0908f3b7806 – DiskCryptor driver x86

0b2f863f4119dc88a22cc97c0a136c88a0127cb026751303b045f7322a8972f6 – DiskCryptor driver x64

8ebc97e05c8e1073bda2efb6f4d00ad7e789260afa2c276f0c72740b838a0a93 – Ransomware