Cyble – Massive Ransomware Attack Targets VMware ESXi Servers

ESXi Args Ransomware Outbreak Affects Over 1,000 Servers

On February 3rd, CERT-FR warned users about a ransomware attack targeting VMware ESXi servers to deploy ESXi Args Ransomware. The report also stated that the Threat Actors (TAs) leveraging a two-year-old vulnerability tracked as CVE-2021-21974. According to VMware, ESXi versions 7.0 before ESXi70U1c-17325551, 6.7 before ESXi670-202102401-SG, and 6.5 before ESXi650-202102101-SG contain a heap overflow vulnerability in OpenSLP. TAs on the same network as the ESXi machine, which has access to port 427, may be able to exploit this vulnerability to execute code remotely.

The online scanner also shows that the ransomware infection is widespread and has infected close to 1000 servers globally. This ransomware has mostly impacted France, followed by the United States and Germany, as shown below.

Figure 1 Statistics of Args Ransomware Source Shodan — Figure 1 – Statistics of Args Ransomware (Source: Shodan)

Recently, a copy of the ESXiArgs encryptor was retrieved by an admin who shared the samples in the BleepingComputer support forums.

The samples related to this Ransomware attack, which include two files named “encrypt.sh” and “encrypt”, responsible for encryption. The “encrypt.sh” is a shell script that performs several operations before starting the encryption process and executes the “encrypt” ELF executable to encrypt files.

Technical Analysis:

The shell script performs various operations, such as modifying configuration files, encrypting files, establishing persistence for ransomware notes, and removing malware from the ESXi server. This blog provides technical insights into the shell script and the ransomware payload.

Modifying the Config File

The Shell script first identifies the config file of the virtual machine running in the ESXi server using the “esxcli vm process list” –commandandmodifies the path to the virtual disk and swap files. The malware replaces the occurrence of ‘.vmdk’ with ‘1.vmdk’ and ‘.vswp’ with ‘1.vswp’.

Figure 2 Code to modify the config file — Figure 2 – Code to modify the config file

By renaming the file names in the config files, the ransomware makes it difficult for the victims to locate and restore the original data after encryption. After changing the configuration file, the shell script terminates the .VMX file in the ESXi server using the “kill -9 $(ps | grep vmx | awk ‘{print $2}’)” command.

Encrypting Files

Now, the malicious script has full control over the files to start the encryption process. First, It iterates through the volumes present on the ESXi server and searches for files with specific extensions, including “.vmdk”, “.vmx”, “.vmxf”, “.vmsd”, “.vmsn”, “.vswp”, “.vmss”, “.nvram”, and “.vmem” in the encountered volume.

The script then calculates the file sizes and proceeds to encrypt them using a Linux binary executable “encrypt” with an argument file “public.pem”. The “public.pem” file is an RSA public key utilized by the ransomware to encrypt the key that will be employed for encrypting files.

Figure 3 Targets file extension for encryption — Figure 3 – Targets file extension for encryption

Persistence

After encrypting files, the script searches for the file named “index.html” in the directory “/usr/lib/vmware” and replaces it with a ransom note. The original “index.html” file is renamed to “index1.html,” and a new “index.html” file with the ransom note is copied to its place, as shown below.

Figure 4 – copies Ransom Note — Figure 4 – Copying Ransom Note

The script also replaces the original “/etc/motd” file by renaming it to “motd1” and then copying the ransom note from the location “$CLEAN_DIR/motd” to “/etc/motd” effectively replacing the original file.

Replacing these files with a ransom note is a common tactic used by ransomware to display a ransom note to users upon logging in.

Cleanup

The script finds all .log files in the root directory and deletes them recursively to erase all traces created by the ransomware. The script now monitors the completion of the encryption process by checking for running process names that contain the string “encrypt”.

It continually retrieves the count of these processes and waits for 0.1 seconds if the count is not equal to zero. When the script identifies that there are no running processes named “encrypt”, it recognizes that the encryption process has finished and exits the loop.

Figure 5 –Delete logs and checks the status of ransomware infection — Figure 5 – Delete logs and checks the status of ransomware infection.

After this, the script modifies and removes certain files from the victim’s machine. Interestingly, the script deletes a file named ”/store/packages/vmtools.py,” which is similar to a Python backdoor file documented by Juniper in December 2022.

The figure below shows the code snippet used for cleaning up.

Figure 6 code snippet used for cleaning up — Figure 6 – Code snippet used for cleaning up

Ransomware Payload

The sample hash (SHA256), 11b1b2375d9d840912cfd1f0d0d04d93ed0cddb0ae4ddb550a5b62cd044d6b66, was taken for this analysis. Based on static analysis, we found that the malicious file is a 64-bit gcc compiled ELF binary, as shown in the below figure.

Usage:

The malware takes several arguments, including a public key and the file to be encrypted, and has various optional parameters.

encrypt <public_key> <file_to_encrypt> [<enc_step>] [<enc_size>] [<file_size>]enc_step – number of MB to skip while encryptionenc_size – number of MB in encryption blockfile_size – file size in bytes (for sparse files)

Upon execution, the ransomware carries out multiple steps for encryption of the system files, such as:

init_libssl()
get_pk_data()
create_rsa_obj()
encrypt_file()

The ransomware initializes the libssl library and then uses the get_pk_data() function to get public key data. This data is then processed using the create_rsa_obj() function to form an RSA public key. The encrypt_file() function implements the encryption of files by utilizing RSA encryption along with the “Sosemanuk Stream Cipher” algorithm.

The encrypt_file() function further calls the “encrypt_simple()” function to perform the encryption process. The image below shows the code snippet of the encrypt_file()function.

Figure 8 code snippet of encrypt file function — Figure 8 – Code snippet of the *encrypt_file()* function

The figure below shows the code snippet of the encrypt_simple() function using the Sosemanuk_encrypt() for encryption.

Figure 9 code snippet of encrypt simple — Figure 9 – Code snippet of *encrypt_simple()*

Once the files have been encrypted, the victims are displayed with a ransom note, which instructs them to contact the attackers through their TOX_ID to restore the encrypted files or prevent them from being leaked, as shown below.

Figure 10 Ransom note — Figure 10 – Ransom note

Conclusion

Threat Actors (TAs) are utilizing a previously identified vulnerability, CVE-2021-21974, to launch ransomware attacks on VMware ESXi servers. The EXSI Args attack involves using a shell script file “encrypt.sh” that runs an ELF executable “encrypt,” causing file encryption. It has been reported that nearly 1,000 ESXi servers have been affected by the ESXi Args ransomware globally.

CRIL will continue monitoring ESXi Args and update our readers on further developments. We will also monitor any related or similar Ransomware to keep our readers up to date on the TTPs used, our findings, and recommendations to avoid becoming a victim.

Our Recommendations

It is strongly recommended that users and administrators of specific versions of VMware ESXi products update to the latest versions as soon as possible due to a vulnerability that affects these versions.
Conducting a full system scan to identify potential security breaches is highly recommended. Additionally, users and administrators should evaluate if it is feasible to turn off port 427, which was the target of a ransomware attack, without affecting the system’s normal functioning.
Check if the file “vmtools.py” is present in the “/store/packages/” location. If it is found, it is recommended to delete the file immediately.
Conduct regular backup practices and keep those backups offline or in a separate network.
Turn on the automatic software update feature on your computer, mobile, and other connected devices wherever possible and pragmatic.
Install reputable anti-virus and Internet security software on all connected devices, including personal computers, laptops, and mobile phones.
Remove any infected devices connected to the same network and disconnect external storage devices if they are connected.

MITRE ATT&CK® Techniques

Tactic	Technique ID	Technique Name
Execution	T1204 T1059 T1064	User Execution Command and Scripting Interpreter Scripting
Persistence	T1543	Systemd Service
Defense Evasion	T1064 T1222 T1027	Scripting File and Directory Permissions Modification Obfuscated Files or Information
Discovery	T1082 T1083 T1518	System Information Discovery File and Directory Discovery Security Software Discovery
Command and Control	T1071	Application Layer Protocol

Indicators of Compromise (IOCs)

Indicators	Indicator Type	Description
10c3b6b03a9bf105d264a8e7f30dcab0a6c59a414529b0af0a6bd9f1d2984459	Sha256	Encrypt.sh
11b1b2375d9d840912cfd1f0d0d04d93ed0cddb0ae4ddb550a5b62cd044d6b66	Sha256	Encrypt

Reference

https://www.bleepingcomputer.com/news/security/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/

Source: https://blog.cyble.com/2023/02/06/massive-ransomware-attack-targets-vmware-esxi-servers/

Tags: CVE, PERSISTENCE, VULNERABILITY, MOBILE, EXPLOIT, LINUX, BACKDOOR, BACKUP