This research was conducted by Ross Inman (@rdi_x64) and Peter Gurney from NCC Group Cyber Incident Response Team. You can find more here Incident Response – NCC Group

Summary

tl;dr

This blog post documents some of the TTPs employed by a threat actor group who were observed deploying Black Basta ransomware during a recent incident response engagement, as well as a breakdown of the executable file which performs the encryption.

A summary of the findings can be found below:

• Lateral movement through use of Qakbot.
• Gathering internal IP addresses of all hosts on the network.
• Disabling Windows Defender.
• Deleting Veeam backups from Hyper-V servers.
• Use of WMI to push out the ransomware.
• Technical analysis of the ransomware executable.

Black Basta

Black Basta are a ransomware group who have recently emerged, with the first public reports of attacks occurring in April this year. As is popular with other ransomware groups, Black Basta uses double-extortion attacks where data is first exfiltrated from the network before the ransomware is deployed. The threat actor then threatens to leak the data on the “Black Basta Blog” or “Basta News” Tor site. There are two Tor sites used by Black Basta, one which leaks stolen data and one which the victims can use to contact the ransomware operators. The latter site is provided in the ransom note which is dropped by the ransomware executable.

Black Basta TTPs

Lateral Movement

Black Basta was observed using the following methods to laterally move throughout the network after their initial access had been gained:

• PsExec.exe which was created in the C:Windows folder.
• Qakbot was leveraged to remotely create a temporary service on a target host which was configured to execute a Qakbot DLL using regsvr32.exe:
  • regsvr32.exe -s \SYSVOL\.dll

• RDP along with the deployment of a batch file called rdp.bat which contained command lines to enable RDP logons. This was used to allow the threat actor to establish remote desktop sessions on compromised hosts, even if RDP was disabled originally:
  • reg add "HKLMSystemCurrentControlSetControlTerminal Server" /v "fDenyTSConnections" /t REG_DWORD /d 0 /f
  • net start MpsSvc
  • netsh advfirewall firewall set rule group="Remote Desktop" new enable=yes
  • reg add "HKLMSystemCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp" /v "UserAuthentication" /t REG_DWORD /d 0 /f

Defense Evasion

During the intrusion, steps were taken by the threat actor in order to prevent interference from anti-virus. The threat actor was observed using two main techniques to disable Windows Defender.

The first used the batch script d.bat which was deployed locally on compromised hosts and executed the following PowerShell commands:

• powershell -ExecutionPolicy Bypass -command "New-ItemProperty -Path 'HKLM:SOFTWAREPoliciesMicrosoftWindows Defender' -Name DisableAntiSpyware -Value 1 -PropertyType DWORD -Force"
• powershell -ExecutionPolicy Bypass -command "Set-MpPreference -DisableRealtimeMonitoring 1"
• powershell -ExecutionPolicy Bypass Uninstall-WindowsFeature -Name Windows-Defender

The second technique involved creating a GPO (Group Policy Object) on a compromised Domain Controller which would push out the below changes to the Windows Registry of domain-joined hosts:

Discovery

A text file in the C:Windows folder named pc_list.txt was present on two compromised Domain Controllers, both contained a list of internal IP addresses of all the systems on the network. This was to supply the threat actor with a list of IP addresses to target when deploying the ransomware. 

Command and Control

Qakbot was the primary method utilised by the threat actor to maintain their presence on the network. The threat actor was also observed using Cobalt Strike beacons during the compromise.

Impact

Prior to the deployment of the ransomware, the threat actor established RDP sessions to Hyper-V servers and from there modified configurations for the Veeam backup jobs and deleted the backups of the hosted virtual machines.

An encoded PowerShell command was observed on one of the compromised Domain Controllers which, when decoded, yielded a script labelled as Invoke-TotalExec that provided the ability to spread and execute files over the network using WMI (Windows Management Instrumentation). The script appears to have been run to push out the ransomware binary to the IP addresses contained within the file C:Windowspc_list.txt. Analysis of the script indicates that two log files are created:

• C:\Windows\Temp\log.info – Contains log entries for successful attempts.
• C:\Windows\Temp\log.dat – Contains log entries for unsuccessful attempts.

For the incident investigated by NCC Group CIRT, only the latter log file had data. The log file contained entries relating to failed uploads for all the IP addresses from pc_list.txt, indicating that the threat actor attempted to deploy the ransomware executable across all hosts on the network, however this had failed.  Despite this, the ransomware was still deployed to Hyper-V servers and the Domain Controllers.

Recommendations

1. Hypervisors should be isolated by placing them in a separate domain or by adding them to a workgroup to ensure that any compromise in the domain in which the hosted virtual machines reside does not pose any risk to the Hypervisors.
2. Ensure that both online and offline backups are taken and test the backup strategy regularly to identify any weak points that could be exploited by an adversary.
3. Restrict internal RDP and SMB traffic ensuring only hosts that are required to communicate via these protocols are allowed to.

Indicators of Compromise

Ransomware Technical Analysis 

Shadow Copy Deletion 

Upon execution, Black Basta performs several operations before launching its encryption activities. 

The Mutex ‘dsajdhas.0’ is checked before issuing the two vssadmin.exe commands listed below. Although the Mutex is static in this sample it is expected to change across future samples. 

C:\Windows\SysNative\vssadmin.exe delete shadows /all /quiet 
C:\WindowsSystem32\vssadmin.exe delete shadows /all /quiet 

These result in the deletion of shadow copies ensuring they cannot be used for recovery purposes. 

Wallpaper icon modification 

Following deletion of the shadow copies, two files are obtained from the binary. Firstly, a JPG file in the currently analysed sample is saved as ‘dlaksjdoiwq.jpg’, used as a wallpaper on targeted devices. The image used can be seen below in Figure 2. 

The second dropped file is an icon file obtained from within the binary and used as a default icon for all files with extension. basta. The file is saved in the currently analysed sample with the name fkdjsadasd.ico within the %Temp% directory, for example:

C:\Users\{Username}\AppData\Local\Temp 

The icon used can be seen below in Figure 3. 

The wallpaper is modified to display the dropped JPG through the registry located at HKCUControl PanelDesktopWallpaper, setting the path to the JPG as seen below in Figure 4.  

The next operation creates a new registry key with the name .basta under HKEY_CLASSES_ROOT and sets the DefaultIcon subkey to display the dropped .ico file. This results in files given a .basta file extension inheriting the Black Basta logo. The registry key can be seen below in Figure 5. 

Ransom Note 

The ransomware note is stored within the binary and written to a text file named readme.txt, as shown in Figure 6. This file is written to folders throughout the system. The content comprises a standard Black Basta template with a URL to a Tor site where victims can negotiate with operators. 

A company ID is also present, which varies between compromises. 

Exclusions 

In an attempt to avoid encrypting files or folders that are likely essential to the operation of the target machine or Black Basta itself, several exclusions are in place that will prevent encrypting specific files. This includes several extensions, folders and files listed below. 

Extension exclusions: 

• exe 
• cmd 
• bat 
• com 
• bat 
• basta 

File Folder exclusions: 

• $Recycle.Bin 
• Windows 
• Documents and Settings 
• Local Settings 
• Application Data
• OUT.txt
• Boot
• Readme.txt
• Dlaksjdoiwq.jpg
• NTUSER.DAT
• fkdjsadasd.iso

A copy of the ransom note is placed where an eligible folder is found, and suitable files discovered within the folder are passed for encryption. 

Encryption 

Several threads are created that are responsible for performing the encryption activity. Each file that is not skipped by the previously mentioned exclusions is encrypted using the ChaCha20 cypher. 

The encryption key is generated using the C++ rand_s function resulting in a random 40-byte hexadecimal output.  

The first 32 bytes are used as the ChaCha20 encryption key. 

The last 8 bytes are used as the ChaCha20 nonce. 

The encryption key is encrypted using an implementation of RSA provided through the Mini GMP library. A public key is obtained from the binary that results in an output similar to the below output in Figure 10. 

Black Basta, as with many ransomware variants, doesn’t encrypt the entire file, instead only partially encrypts the file to increase the speed and efficiency of encryption. Black Basta achieves this by only encrypting 64-byte blocks of a file interspaced by 128-bytes. This can be seen in Figure 11 below, where the first two encrypted data blocks are shown.  

To further demonstrate this, an unencrypted version of the file can be seen below in Figure 12. 

Finally, the earlier generated RSA encrypted key and 0x00020000 are appended to the end of the file, which would be used for decryption purposes. 

Following successful encryption of a file, its extension is changed to .basta which automatically adjusts its icon to the earlier drop icon file. An example of what a victim would be presented with can be seen below in Figure 14. 

While the ransom note threatens victims with the publication of data if the ransom is not met, initial analysis has not uncovered a mechanism for exfiltration. With access to the private key counterpart of the public key used earlier, recovery of the ChaCha20 encryption key by operators should be possible allowing for file decryption. No weakness in the encryption was discovered during analysis that would provide an opportunity for decryption without the private RSA key.

NCC Group Incident Response services provide specialists to help guide and support you through incident handling, triage and analysis, all the way through to providing remediation guidance