BlackByte Ransomware – Pt. 1 In-depth Analysis | Trustwave

The DLL Payload

The payload is a .NET DLL (managed code) that contains a class named jSfMMrZfotrr.

The main purpose of this DLL is the following:

1. Add .JS and .EXE file extensions into Microsoft Defender's exclusion list.
2. Evade the Microsoft Antimalware Scan Interface (AMSI) DLL so that it will not scan the loaded malware and alert the user for suspicious activity .
3. Check to see if the following DLLs are present:

    - SbieDll.dll (Sandboxie)         
    - SxIn.dll (Qihoo360 Sandbox)
    - Sf2.dll (Avast Antivirus)
    - snxhk.dll (Avast)
    - cmdvrt32.dll (Comodo Internet)

4. Extract and decode the main payload (BlackByte ransomware) from the resources then execute it in the memory.

Extracting the main payload – BlackByte - didn’t come easy, as it turns out that the executable binary is encrypted.

To make it easier and bypass analyzing the encryption and obfuscation layer, we simply let the JScript code run using cscript command:

Then we let the malicious .NET assembly run in memory. Afterward, we dumped all the .NET assemblies including the decrypted BlackByte .NET executable. We used a tool called MegaDumper to achieve this.

BlackByte: Preparing the Infected System

Before encrypting, BlackByte first prepares the system so that nothing may hamper it from its file encryption routine. During the initialization, the ransomware sets the value of essential fields such as the ransom notes, the encrypted file extension, cryptographic salt, OS name, among others. Victim identification is then generated by combining the infected system’s processor ID and the volume serial number and hashing them with MD5. The ransomware creates a mutex named Global\1f07524d-fb13-4d5e-8e5c-c3373860df25 and terminates if that mutex name already exists.

Afterward, it checks if the system language locale is on its list of language codes – as shown below. If the system default language is on the list, BlackByte terminates:

The ransomware also sets its process priority class to above normal and uses SetThreadExecutionState API to prevent the system from entering sleep. It then removes applications and terminates processes that can hinder the encryption of the target files. Below are the actions it does in the system:

It enumerates the registry key:

And then deletes the following subkeys:

1. vssadmin.exe
2. wbadmin.exe
3. bcdedit.exe
4. powershell.exe
5. diskshadow.exe
6. net.exe
7. taskkill.exe
8. wmic.exe

BlackByte terminates Raccine, an anti-ransomware utility, and uninstalls it from the infected system by running the command:

It also deletes any Raccine related registry keys including:

It runs a series of SC commands to disable a list of services:

It also enables the following services:

It uses the Microsoft Restart Manager API RmShutdown to terminate the following processes:

The following living-off-the-land commands are also executed to delete all shadow copies on all volumes, delete Windows restore points, disable controlled folder access, enable network discovery, grant "everyone" full access to target drives, delete the recycle bin, enable file and printer sharing, and enable SMB1 protocol.

icacls.exe" "<DRIVE LETTER>:*" /grant Everyone:F /T /C /Q

The ransomware sets the following registry settings to elevate local privilege, connect mapped drives, enable long paths:

BlackByte uses the mountvol.exe command to mount volume names and leverage the Microsoft Discretionary Access Control List tool – icacls.exe to grant the group to “Everyone” full access to the root of the drive.

BlackByte: Worm

This ransomware also has a worm capability. It first checks if the file %AppData%\<Generated Victim ID> exists. If this file does not exist, it means that the ransomware has not infected the network yet.

When the worm function is called, it initially sleeps for 10 seconds then queries at least 1,000 hostnames in the domain from the active directory. 

It enumerates the returned record of hostnames, sends a wake-on-lan magic packet and then pings the target hosts making sure they are alive. Below is the worm routine and execution flow:

BlackByte then proceeds to infect the host by copying itself to the path <hostname>\c$\Users\Public\obamka.js (if it has admin rights) or <hostname>\Users\Public\obamka.js and then creates a scheduled task in the remote host to execute the file.

BlackByte then creates an infection marker file in the target host in the path c:\Users\Public\blockator.

BlackByte: Encryption Routine

What we found interesting about this ransomware, is that it initially downloads a .PNG file from the link hxxp://45.9.148.114/forest.png which contains a key to be used later to encrypt the files. If the ransomware fails to download the key, it will crash and will save the infected system from getting its files encrypted.

The file it downloaded is not actually a PNG image file, instead:

• The first 40 bytes is the raw key used to encrypt the user's files, this is encrypted with 3DES.
• The last 32 bytes contain the 3DES key used to decrypt the first 40 bytes raw key.
• The raw key then goes through a PBKDF2 derivation function to derive the AES 128-bit key and Initialization Vector for the AES algorithm used to encrypt the user files.
• This raw key is also re-encrypted using RSA with a public key embedded in the module and displayed in the ransom note.
• The attacker can decrypt this key using his private key, but this key is the same - provided the user always gets the same “forest.png” file. Presumably, the file forest.png is replaced periodically.

The first 40 bytes of the PNG file is a key (encrypted in TripleDES) used later for the ransomware’s file encryption.

The TripleDES key to decrypt the key is found in the last 32 bytes of the PNG file.

Below is the decrypted raw key:

This raw key is then re-encrypted with RSA using a public key embedded in the module (shown below) and then after the encryption, the key gets encoded with Base64.

The encrypted raw key is replaced in the ransom note's key placeholder where it gets displayed.

After downloading and decrypting the raw key, it will  derive the raw key using Rfc2898DeriveBytes implementation with the salt byte-array { 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08 } and with 1000 iterations

The graphic below will help visualize the encryption routine:

The ransomware will then start enumerating the drives (excluding the CD-ROM drive) and add them to a list. It makes sure it has full control of the target drives by changing its access control to full.

After gathering all the drives (local and remote) and shared folders on the remote host, the ransomware will start traversing it and searches for all the target files.

It avoids encrypting files with a system file attribute, and also filenames and file extensions from this list:

Filenames:

File extensions:

If the ransomware encounters a virtual hard drive file extension .vhd and .vhdx, it will attempt to dismount these drives using a PowerShell command:

A target file to be encrypted undergoes file size filtering:

• If the file is greater than 150MB
  • encrypt the first 50MB and the last 50MB of the file
• If the file is greater than 15MB
  • encrypt the first 5MB and the last 5MB of the file
• If the file is greater than 3MB
  • encrypt the first 1MB and the last 1MB of the file
• If the file is less than 3MB
  • encrypt the whole file

To encrypt a file, it uses AES symmetric-key algorithm using the RFC2898 derived raw keys from the .png file.

Below is the code snippet of the file encryption routine.

In BlackByte Ransomware – Part 2, we will show you how we de-obfuscated the JScript launcher, decompiled the ransomware code, and analyzed more of its inner workings.

IOCs