Active ESXiArgs Ransomware Campaign Targeting ESXi Servers Worldwide

Summary 

Early Friday morning, February 3, 2023, Arctic Wolf Labs began monitoring a new ransomware campaign targeting public-facing ESXi servers. The campaign has grown exponentially over the weekend, with approximately 3,000 victims worldwide as of early-Monday morning. Based on reporting from OVH, the threat actors behind this campaign are likely leveraging a nearly two year old heap overflow vulnerability (CVE-2021-21974) in VMware ESXi’s OpenSLP service.  

What We Know 

• Worldwide targeting with at least 3,000 victim servers based on reporting from services like Shodan and Censys. 
  • The victim count is likely higher due to Internet search engines being a point-in-time scan and devices being taken offline for remediation before a second scan. 
• Based on the ransom note, the campaign is linked to a sole threat actor or group.  
  • Each ransom note has an identical Tox ID, which is used to contact the threat actor. A Tox ID is used to add a person to a contact list within Tox Chat, a peer-to-peer (P2P) instant messaging platform. 
• Due to the relatively low ransom demand (2 BTC) and widespread, opportunistic targeting, we assess with moderate confidence this campaign is not tied to ransomware groups known for “Big Game Hunting”.  
  • More established ransomware groups typically conduct OSINT on potential victims before conducting an intrusion and set the ransom payment based on perceived value.  
• Security Researcher Michael Gillespie from ID Ransomware has assessed the ransomware variant is likely based on Babuk source code, due to the unique usage of the Sosemanuk algorithm.  
  • Babuk source code was leaked in September 2022.  
• The ransomware’s encryption process is targeting virtual machine files with the following extensions: .vmdk, .vmx, .vmxf, .vmsd, .vmsn, .vswp, .vmss, .nvram, and .vmem
• Although the ransom note indicates the threat actors exfiltrated data, we have not observed reporting supporting this claim. 

Technical Analysis 

The Arctic Wolf Labs team analyzed the malicious Shell Script used by the ESXiArgs group along with their ransomware binary deployed. This analysis was based on the following artifacts: 

• ESXiArgs Script 
  • Filename: encrypt.sh 
  • SHA256: 10c3b6b03a9bf105d264a8e7f30dcab0a6c59a414529b0af0a6bd9f1d2984459 

• ESXiArgs Encryptor 
  • Filename: encrypt 
  • SHA256: 11b1b2375d9d840912cfd1f0d0d04d93ed0cddb0ae4ddb550a5b62cd044d6b66 

ESXiArgs Script Analysis 

The ESXiArgs script is used to facilitate the attack by staging the environment for encryption, enumeration, and cleaning up files used during the attack.   

The script can be broken down to the following stages: 

1. Preparing the system 
2. Stopping processes 
3. Finding files to encrypt  
4. Defacement  
5. Cleaning up files used during the attack 

Stage 1: Preparing the system 

The script makes use of the ‘/tmp/’ directory to stage the encryptor, message of the day banner and other attack files.  The script will attempt to modify the virtual machine configuration files and change the names of the ‘vmdk’ and ‘vswp’ to include a ‘1.’ prior to the name.

Stage 2: Stopping processes  

Prior to encryption, the script will attempt to kill processes which matches the string ‘vmx’ using the system signal SIGKILL (9) and the process ID. 

Stage 3: Finding files to encrypt 

The script will make the /tmp/encrypt binary executable which will be used to encrypt each file.  Prior to encrypting, the ‘esxcli storage filestystem list’ command is used to find mounted or unmounted volumes.  Once found, a list of files is searched for to identify potential targets for encryption.   

Script searches for files with the following extensions: 

• .vmdk
• .vmx
• .vmfx
• .vmsd
• .vmsn
• .vmswp
• .vms
• .nvram
• .vmem

For each file that is found, the script will invoke the /tmp/encrypt binary and pass in a public key, name of the file, number of megabytes to skip while encrypting and number of megabytes per block.  This technique ensures that the files are sufficiently encrypted and in a timely manner regardless of the size of the file. 

Example: search for and encrypt files 

Stage 4: Defacement 

Once the encryption process is complete, the SSH message of the day is updated to contain the ransomware note as well as the ESXi index.html.  

Stage 5: Cleaning up files used during the attack 

The script will remove files from the disk, searching for log files, the encryption binary used during the attack, cron tab files and other attack scripts. 

It also deletes a vmtools.py (/bin/rm -f /store/packages/vmtools.py) which has similarity to an attack in December 2022 caught by Juniper Networks. (link).   

Lastly the script will start SSH. 

The ransomware encryptor contains a few arguments which help facilitate the process.  Each file is processed based on the input arguments passed to the binary, as well as information on how the encryption process should be performed.   

Libssl.so is used to facilitate the CPRNG and a key to encrypt the file using the ‘Sosemanuk’ algorithm. 

   
Once the sample starts encrypting, the ‘Sosemanuk‘ stream cipher is used to perform the encryption.  The binary takes in two parameters to speed up the encryption process, which is the number of megabytes to skip while encrypting, and the size of each encryption block (as the stream cipher iterates through the file).  Both values are controlled by the ESXi Script. 

Recommendations 

Recommendation #1: Patch or Upgrade your ESXi Server 

We assess with moderate confidence that the threat actors are leveraging CVE-2021-21974 in this campaign. To mitigate potential impact as a result of successful exploitation, at a minimum we recommend applying the relevant security patches to vulnerable devices.   

Out of an abundance of caution, we strongly recommend upgrading to the latest version of ESXi server available. Although, we have moderate confidence in our assessment, it is plausible that the threat actors are leveraging a different vulnerability in this campaign. 

Recommendation #2: Disable SLP Service if you are not Able to Patch Immediately 

Admins can disable the Service Location Protocol (SLP) service on ESXi servers that are vulnerable and cannot be patched immediately. However, this is a temporary mitigation and administrators should update to a patched version of ESXi as soon as possible. 

How to Disable/Enable the SLP Service on VMware ESXi – https://kb.vmware.com/s/article/76372  

Recommendation #3: Do not Expose ESXi Servers Directly to the Internet 

We strongly recommend not exposing your ESXi servers directly to the Internet. If connectivity outside of your organization is business critical and required, ensure proper access controls are in place and the server can only be accessed by company assets through a VPN.  

Recommendation #4: If affected by ESXiArgs Ransomware, Explore Using CISA’s ESXiArgs Recovery Script 

The Cyber Security Infrastructure and Security Agency (CISA) has released an open-source script designed to help system administrators regain access to virtual machines that were impacted by an ESXiArgs ransomware attack. 

If your organization had ESXi servers and associated VMs impacted by this campaign, we recommend reviewing this script and determining if it can assist in recovery efforts: https://github.com/cisagov/ESXiArgs-Recover 

Note: Ensure you have proper backups of your ESXi files before using the script to attempt recovery as a precautionary measure. 

References 

• VMware Advisory  
• VMware Knowledge Base  
• CVE-2021-21974  
• OVH Initial Reporting  
• BleepingComputer Technical Details 
• Juniper Networks Research on Python Backdoor in ESXi Servers 

Authors

James Liolios | Sr. Threat Intelligence Researcher
James Liolios is a Senior Threat Intelligence Researcher at Arctic Wolf, where he keeps a watchful eye on the latest threats and threat actors to understand the potential impact to Arctic Wolf customers. He has a background of 9 years’ experience in many areas of cybersecurity, holds a bachelor’s degree in Information Security, and is also CISSP certified.

Steven Campbell | Sr. Threat Intelligence Researcher
Steven Campbell is a Senior Threat Intelligence Researcher at Arctic Wolf Labs and has more than eight years of experience in intelligence analysis and security research. He has a strong background in infrastructure analysis and adversary tradecraft.

Christopher Prest | Lead Security Researcher
Christopher is a lead security researcher and a 17 year veteran in Software and Application security development, coupled with 2 years of cutting edge detection engineering and security research. A seasoned expert, Christopher focuses on Malware analysis and reverse engineering to shape the future of cybersecurity.