SonicWall Security Center
Share: Linkedin Share Facebook Like
Back to SonicALERT

BadRabbit ransomware spreads fast through Russia and Ukraine (Oct 24, 2017)


SonicWall Capture Labs Threat Research team became aware of and analyzed the BadRabbit ransomware that has been spreading actively.

Upon execution it drops the following files on the system:
  • c:\Windows\infpub.dat [1d724f95c61f1055f0d02c2154bbccd3 - detected as BadRabbit.CM ( Trojan )]
  • c:\Windows\dispci.exe [b14d8faf7f0cbcfad051cefe5f39645f - detected as BadRabbit.RSM ( Trojan )]
  • c:\Windows\cscc.dat

It then runs it using rundll32 with the following parameters:
C:\\Windows\\system32\\rundll32.exe C:\\Windows\\infpub.dat,#1 15

infpub.dat contains a list of hardcoded Windows credentials, most likely to brute force and get an entry into the machines.

The malware then proceeds to encrypt files on the system with the following extensions:

Below is an instance where an image file Sunset.jpg is affected by this ransomware. The file extensions on the system remain the same but the encrypted file get a marker at the end - e.n.c.r.y.p.t.e.d.:

The ransomware adds two scheduled tasks

  • drogon - C:\WINDOWS\system32\shutdown.exe /r /t 0 /f
  • rahegal - C:\WINDOWS\system32\cmd.exe /C Start "" "C:\Windows\dispci.exe" -id 3642970814 && exit
The task drogon is used to reboot the system whereas task rahegal is used to start the disk encryption.
It is interesting to note that drogon and rahegal are names of two dragons present in the famous TV series Game Of Thrones.

Once the system reboots, we see the ransomware screen once the system is back online:

Sonicwall Capture Labs continues to analyze this threat and will update this blog with the latest findings.

Sonicwall Capture Labs detects this threat via the following signatures:
  • 1d724f95c61f1055f0d02c2154bbccd3 - GAV: BadRabbit.CM (Trojan)
  • b14d8faf7f0cbcfad051cefe5f39645f - GAV: BadRabbit.RSM(Trojan)
  • fbbdc39af1139aebba4da004475e8839 - GAV: BadRabbit.DS(Trojan)

Update 1 - Oct 24,2017

The following steps can be taken to ensure the ransomware does not spread on the system even if it is executed on it:
  • Create and add the following file at the given location:
    • C:\Windows\infpub.dat
  • It is important to give read-only permissions to the file so that the ransomware cannot update it. This stops the ransomware at the step where it drops the file infpub.dat on the system
  • When the malware tries to execute infpub.dat it gets an error as shown below:

Update 2 - Oct 25, 2017

We confirm that BadRabbit is an updated version of NotPetya as the infection chain and component usage is identical.

The dropped c:\windows\infpub.dat DLL file contains 5 AES encrypted payloads.
  • 1) 32 bit Mimikatz binary
  • 2) 64 bit Mimikatz binary
  • 3) 32 bit DiskCryptor driver
  • 4) 64 bit DiskCryptor driver
  • 5) 32 bit Encoder/Decoder binary
Based on the system architecture (32 bit or 64 bit) the Mimikatz binary and the DiskCryptor driver is dropped into the windows folder. Mimikatz binary is named as c:\windows\.tmp and the DiskCryptor driver is named as c:\windows\cscc.dat. This DiskCryptor driver is a valid digitally signed driver released by the ReactOS Foundation ( cscc.dat file can also be used as a measure to stop the infection in the same way the infpub.dat file can be used as mentioned on our last update 1. The 32 bit Encoder/Decoder binary is named as c:\windows\dispci.exe. The actual disk encryption and file decryption is done using this component. Next infpub.dat deletes itself from disk.

File encryption: The infpub.dat DLL next proceeds to enumerate all the files on the local disks and network attached drives checking their extensions as mentioned on the original blog to encrypt them using the public key it contains.

Lateral Propagation: The infpub.dat DLL next executes the dropped Mimikatz binary and connects to it using a named pipe and retrieves the credentials found by Mimikatz before deleting the Mimikatz binary. It then attempts to connect to other computers in the same subnet using the present user credentials, Mimikatz provided list of credentials and a hard coded list of usernames and passwords whichever is successful in accessing the admin$ administrative share of the remote computer. It drops a copy of the DLL and creates a service on the remote computer, first directly by connecting to the remote service manager and if does not work then using wmic. This lateral propagation method is identical to its previous version, the NotPetya malware. Although the NotPetya version was using the EternalBlue exploit and this version is not

Disk Encryption: The infpub.dat DLL creates a scheduled task which reboots the system after 15 mins. The infpub.dat DLL had already registered the DiskCryptor driver (cscc.dat) to load on boot. This driver on load adds itself as a volumn filter driver. The infpub.dat DLL also created another scheduled task to run the Encoder/Decoder binary (dispci.exe) on startup. So once windows boots, the dispci.exe now connects to the DiskCryptor driver using the device \Device\dcrypt and performs rest of the activity. The original MBR is backed up in encrypted form and the custom MBR supplied by the dispci.exe is written by the DiskCryptor driver. Next the dispci.exe also encrypts the logical volumes of the first hard drive before rebooting the system. On reboot the infected MBR presents a password prompt.

Decryption: If the correct password is provided to the boot prompt then the original encrypted MBR is recovered and the logical volumes are also decrypted to perform a complete boot. Next the same Encoder/Decoder binary (dispci.exe) should be executed without any parameters which will present another password prompt. The correct password would decrypt the encrypted files as well. So unlike the previous NotPetya version, this version has capability to completely reverse the encryption and give the files back.

Update 3 - Oct 27, 2017

We confirm the presence of EternalRomance code as additional internal propagation technique. This code starts after a dynamically calculated sleep and this sleep time is variable.

EternalRomance code does its own host discovery / network enumeration (does not rely on network enumeration / host discovery of main code) and there does not seem to be any dependency on the main code. Thus, it seems like the author put this code in as a quick, last minute addition.

Back to top

Back to SonicALERT

Follow: Follow us on Facebook Follow us on Twitter Join the Conversation
© 2017 SonicWall | Privacy Policy | Conditions for use | Feedback | Live Demo | SonicALERT | Document Library | Report Issues
Version: 13.6 | S2MSW02