ESXiArgs: response and recovery actions

ESXiArgs is ransomware deployed on VMWare ESXi hypervisor servers (v.6.x versions prior to v.6.7 and potentially v.7.x) since February 3, 2023. Several vulnerabilities have been identified as potential intrusion points and although all of them have been patched to date, it is still a threat to be reckoned with. The country most affected by this campaign is France. In fact, the CISO  of the  French cloud, OVH Cloud, was one of the first to report the existence of the campaign. Today, according to Censys, hundreds of infected servers can still be found.

It should be noted that all the exploited vulnerabilities are quite old, discovered around 2021, some of them with the exploit code publicly available since then. 

Characteristics

The  ESXiArgs malware exhibits a number of distinctive attributes and behaviors that distinguish it in the cybersecurity landscape.

Motivation

The motivation behind the development and deployment of ESXiArgs, a ransomware for VMWare ESXi hypervisors, lies in obtaining economic benefits through extortion. The choice of VMWare ESXi servers as a target reveals a strategic approach, as these servers are critical in virtualization environments, potentially amplifying the impact of the attack on affected organizations. 

Infection and spread

The attack vector is not fully confirmed, as it appears that a wide range of vulnerabilities have been used during the campaign. In all the vulnerabilities exploited, most of them affect the OpenSLP service, an implementation of the Service Location Protocol, which listens on port 427 and is used to allow systems to discover services on a local network without the need to be preconfigured. The following suspicious vulnerabilities are considered by VMware to be those possibly used in the campaigns:

• CVE-2022-31699 (heap overflow).
• CVE-2021-21995 (heap overflow).
• CVE-2021-21974 (heap overflow).
• CVE-2020-3992 (use-after-free).
• CVE-2019-5544 (heap overwrite).  

Some degree of uncertainty remains, as some affected systems were reported to have OpenSLP disabled, meaning the attackers must have used another entry point.

- Example ransom note. Source. -

Once the attackers gain access to the system, the following files are downloaded:  the encrypt.sh script, an  executable binary for Linux called encrypt, an index.html ransom note, another version of the ransom note to be displayed at boot/login motd system boot, the public key for public.pem encryption,  and the payload of the attack. archive.zip. 

Detection evasion and recovery

To evade detection, ransomware uses several techniques: it kills all VMX processes, deletes registries, and modifies files, making them difficult to detect and analyze. 

• Overwrites system file /bin/hostd-probe.sh.
• Overwrites vmware file /etc/vmware/rhttpproxy/endpoints.conf.
• Overwrites system file /etc/rc.local.d/local.sh.
• Overwrites vmware file /store/packages/vmtools.py.
• Delete cron tasks: /var/spool/cron/crontabs/root.
• Delete .log files.
• Delete the attack script: /bin/rm -- "$0".
   

In addition, the attack deploys persistence mechanisms based on the execution of  /bin/auto-backup.sh.

Encryption

The encryption loop searches for all virtual disks and memory files in  /vmfs/volumes. They target the following files with extensions: vmdk, vmx, vmxf, vmsd, vmsn, vswp, vmss, nvram, vmem.

The code structure and encryption process appear to be inspired by the Babuk ransomware whose code was leaked in September 2021 after all operations were shut down. Several malwares derived from it, such as PrideLocker and CheersCrypt. All of them point to ESXi systems and use the Sosemanuk encryption algorithm. For each file, the process generates 32 bytes using the OpenSSL RAND_pseudo_bytes function  . This key is then used with Sosemanuk to encrypt the contents of the file. Finally, the key, unique to the file, is added to the end of the encrypted data after being encrypted with RSA. 

A particularity of this malware is that it optimizes performance by encrypting only fragments of the file. For each, the attack uses an encryption optimization algorithm, which is based on encrypting only a part of the contents of files larger than 128 MB. The security analysts' research made it possible to identify chunks (or chunks) of unencrypted data and rebuild virtual machines from them. Unfortunately, this technique became obsolete once the threat actor discovered it. Thus, the attackers slightly changed the algorithm so that the unencrypted fragments were smaller, making it difficult to reconstruct the files. In addition, flat files were included in the encryption process. With so much information hidden, it is almost impossible to recover from the attack. The second wave of attacks, launched on February 8, already used this new technique.

- Managing the size_step variable to determine the size of cipher blocks. Source. - 

Summary

The figure below presents a visual summary of the attack execution flow, detailing the key steps and interactions that characterize the operation of the  ESXiArgs malware. This schema provides a bird's-eye view of how malware spreads, infects, encrypts, and performs other meaningful actions on VMWare ESXi servers.

- Encryption execution flow. Fuente. -

Response and disinfection

Preventively, all vulnerabilities can be fixed by applying the corresponding patch. Also, the latest versions of  the software solve the problem.

Other ways to anticipate and prevent these types of attacks are: disabling services that could serve as potential entry points, such as the SLP service and ensuring that servers are not exposed to the Internet without adequate security measures or installing a firewall in front of the hypervisor.

As a last resort, it is possible to make use of the decryption tools available to try to reverse the consequences of the incident in case we have been subject to this attack. However, it is important to note that the effectiveness of the decryption process is not assured, as it can vary depending on the specific version of the malware that has been used. Today, the recovery techniques of encrypted files are based on the reconstruction of the encrypted parts from the unencrypted parts.

The CISA tool, based on the findings of Enes Sonmez and Ahmet Aykac, can be used if affected systems were attacked during the first wave of the campaign. It is a simple and intuitive tool; it is only necessary to download the script with wget:

Then, grant the execute privilege to the script and run it from the folder containing the virtual machine file you want to recover, providing the file name as an argument, where [name] follows the [name].vmdk convention.

Utilizar /tmp/recover.sh [nombre] thin if the VM is in thin format.

If successful, the output will indicate it. If unsuccessful, the recovery script may not be able to work on the affected files. If the script was successful, you must re-register the VM. If the ESXi web interface is not accessible, you must first delete the ransom note by following these steps:

By keeping the ransom file.html you can help the security team during the investigation. After you restart the ESXi server, you should be able to access the web interface again. If the restored VM is still registered, you will need to unsubscribe.

- Decommissioning the previous VM. Source. -

Now you can select 'Create/Register VM' and go to 'Register an existing VM'.

 

- Registering New VM. Source. -

When selecting the datastore, choose the recently recovered vmx file. Click 'Next & Finish' to close the wizard and use the VM as usual. 

Conclusions

The case of the ESXiArgs threat clearly illustrates how ransomware is in a constant state of evolution and adaptation, especially in its ability to affect hypervisors, which translates into its ability to lock down and take control of the virtual machines that these hypervisors manage.

Once again, it is important to highlight the critical importance of keeping our systems up to date and adopting active prevention strategies, as cyberattacks continue to increase, adapting to exploit the vulnerabilities of organizations.

The lesson learned from cases like ESXiArgs is that anticipation and proactive action play a critical role in protecting the integrity of systems and data in today's digital environment.