We focus on the behavior of the DarkSide variant that targets Linux. We discuss how it targets virtual machine-related files on VMware ESXI servers, parses its embedded configuration, kills virtual machines (VMs), encrypts files on the infected machine, collects system information, and sends it to the remote server.
Updated June 1, 2021, 12:02 am ET: This article has been updated to remove the Command-and-Control (C&C) URI String field in Table 1. Further study showed that it does not apply consistently to a number of samples.
As we discussed in our previous blog, the DarkSide ransomware is targeting organizations in manufacturing, finance, and critical infrastructures in regions such as the United States, France, Belgium, and Canada. The DarkSide ransomware targets both Windows and Linux platforms. We also noticed that the Linux variant, in particular, targets ESXI servers.
In this blog, we focus on the behavior of the variant that targets Linux. This entry also discusses how this variant targets virtual machine-related files on VMware ESXI servers, parses its embedded configuration, kills virtual machines (VMs), encrypts files on the infected machine, collects system information, and sends it to the remote server.
This table summarizes some of the differences between the behavior of the DarkSide ransomware on Windows and on Linux:
|Windows Variant||Linux Variant|
|Encryption Mechanism||Salsa20 with RSA-1024||ChaCha20 with RSA-4096|
|Cipher Blocks||Salsa20 matrix is custom and randomly generated using “RtlRandomExW”||ChaCha20 initial block is standard, built using “expand 32-byte k” as a constant string|
|Target Files||All files on the system except the files, folders, and file extensions mentioned in the configuration||VM-related files on VMware ESXI servers, with specific file extensions mentioned in the configuration|
|New Extension||Generated by applying CRC32 several times on the HWID of the victim machine as “.4731c768”||Hard-coded in the embedded configuration as “.darkside” or passed by execution parameters|
|Ransom Note File Name||Consists of hard-coded part in the configuration as “README.” and the generated ID mentioned previously: for example, “README. 4731c768.TXT”||Hard-coded in the embedded configuration as “darkside_readme.txt” or passed by execution parameters|
Analysis of the Linux Variant
As we noted earlier, DarkSide also has a Linux variant to infect more machines and cause more damage in the victim network. However, this variant is quite specific, as its main configuration targets VM-related files on VMware ESXI servers as seen in the following figure:
Unlike the Windows variant, the Linux variant’s strings and configuration are not obfuscated. The configuration of the Linux variant specifies features of the sample, such as the extension for encrypted files, C&C URL, number of threads, and a constraint on a minimum size of the target files to be encrypted.
Note that the root path — the starting point for encryption — in the following figure is “/vmfs/volumes/”, which is the default location for the VM files on ESXI hosts.
In addition to the hard-coded configuration, the ransomware executable can accept parameters to infect more files and change its default settings. Figure 3 shows where the malware parses execution parameters.
DarkSide runs several ESXCLI commands (such as the command- line interface framework in vSphere) in order to collect information about the infected ESXI host, such as the running virtual machinesVMs, storage- related information, and vSAN- related information.
Table 2 shows a list of ESXCLI commands run by DarkSide on the victim machine.
|esxcli –formatter=csv –format-param=fields==”Device,DevfsPath” storage core device list||List the Devfs Path of the devices currently registered with the storage|
|esxcli –formatter=csv storage filesystem list||List the logical sections of storage currently connected to the ESXI host|
|esxcli –format-param=fields==”WorldID,DisplayName” vm process list||List the running VMs on the ESXI host|
|esxcli vsan debug vmdk list||List the status of VMDKs in vSAN|
|esxcli –format-param=fields==”Type,ObjectUUID,Configuration” vsan debug object list||List the UUID of the vSAN objects|
Figure 4 shows how the DarkSide ransomware lists the running virtual machines on the ESXI.
Killing Virtual Machines
Before encryption, the Linux variant of the DarkSide ransomware can power off running VMs on the ESXI server using the following ESXI command:
“esxcli vm process kill –type= force –world-id= <WorldNumber>”
The Linux variant of the DarkSide ransomware uses a ChaCha20 stream cipher with RSA-4096 to encrypt targeted files on the victim machine.
It loops across the files on the root path mentioned in the embedded configuration or in the given parameter, as shown in Figure 7.
Before encryption, the ransomware performs a file size check to make sure that this is more than the minimum file size given in the embedded configuration or in the parameters.
The malware then opens the target file, reads the content based on the part and space size given in the configuration or in the parameters, encrypts them, and writes to the file as shown in the following code:
Unlike the Windows variant that randomly generates its custom Salsa20 matrix by calling “RtlRandomExW” several times, the malware uses the standard constant “expand 32-byte k” in the Chacha20 cipher used to encrypt files on the victim machine, as shown in the next figure.
After encryption, the malware then adds a header and a cipher at the end of the encrypted files as shown in Figure 11.
The ransomware output console shows the results of the encryption, the encrypted filenames, the discarded files after size check, the time of encryption, and more.
Ransom note and added extensions
The Linux variant drops a ransom note on the victim machine and adds a new file extension to the encrypted files.
Unlike the Windows variant, the ransom note file name and the new extension for encrypted files are hard-coded in the malware configuration file or given in a parameter, and the malware does not add any ID at the end of it.
For the analyzed samples, the new extension was “.darkside” and the hard-coded ransom note file name was “darkside_readme.txt”.
The DarkSide ransomware can send a C&C beaconing message with the collected system information to a remote server hardcoded in the configuration. It collects system information on the victim machine, such as host name, domain, and disk information, as evidenced in Figure 15.
The ransomware then puts the collected system information of the victim machine with a hard-coded UID value in the following format:
It hashes the collected information before sending it to the URL mentioned in the embedded configuration of the sample. DarkSide also uses a random parameter of eight characters in the request body to make its C&C traffic more difficult to detect by IPS/IDS devices on the victim network. The request body has the following format:
<Random 8-character variable> = <Encrypted collected information> & <Random 8-character variable> = <hardcoded UID>
Figure 17 shows the HTTP POST request sent by the malware to the remote server with the collected information.
The DarkSide ransomware family targets both Windows and Linux platforms. There are similarities between the Linux and Windows variants, but they are different with regard to some features, such as encryption mechanism, target files, ransom note name, extension, C&C URL, and more.
The Linux variant uses a ChaCha20 stream cipher with RSA-4096 in order to encrypt the files on the victim machine. It mainly targets VM-related files on VMWare ESXI servers, such as VMDK files. It can also accept parameters to infect more files on the victim machine. Additionally, the DarkSide ransomware runs ESXCLI commands to get vSAN and storage information on the victim machine. It also lists and kills running VMs on the infected ESXI host before encryption. Lastly, it drops a ransom note on the encrypted directories on the victim machine.
Indicators of Compromise
|SHA256||Trend Micro Detection Name|
Read More HERE