π CloudSEK has raised $19M Series B1 Round β Powering the Future of Predictive Cybersecurity
Read More
In the latest threat actor attack against VMware ESXi servers, a custom ESXiArgs ransomware script is used to exploit the old RCE vulnerability (CVE-2021-21974). Here is a technical analysis of the files used in the ransomware attack.
Proactively monitor and defend your organization against threats from the dark web with CloudSEK XVigil.
Schedule a Demoβ
On 03 February 2023, there was a surge in attacks targeting VMware ESXi servers. Threat actors were leveraging an old vulnerability (CVE-2021-21974) in order to gain RCE (Remote Code Execution) and launch ransomware attacks.Β
β
The OpenSLP version used in ESXi versions 7.0 before ESXi70U1c-17325551, 6.7 before ESXi670-202102401-SG, and 6.5 before ESXi650-202102101-SG are vulnerable to a heap-overflow attack, which allowed attackers to perform Remote Code Execution.
β
On 03 February 2023, a member on the Bleeping Computer forum thread, with access to a targeted server, shared a script and an executable, found on their ESXi servers. These files were reportedly used to encrypt the contents of their ESXi servers.
β
β
β
β
β
β
β
The script is written in Bash. It is responsible for preparing the system, and calling the Ransomware payload in order to encrypt files. Once done, it performs a cleanup on the system.
β
The script starts by setting its working directory as /tmp/. Files that it uses for the attack are stored here. After this, it uses the command esxcli vm process list | grep "Config File" | awk '{print $3}' to find the configuration files associated with virtual machines on the server.Β
β
It then replaces the filenames of the disk image and swap file in all config files with 1.vmdk and 1.vswp. This is done to make it difficult for victims to recover and reconfigure the virtual machines, since identifying the disk images and swap files will be nearly impossible.
β
β
β
After this, the script kills the running VM processes using the kill command. The script is now ready to start encryption of all files on the server.
β
β
The script starts its encryption operations by making the encrypt binary executable for all users and groups, using the command chmod +x. Then, it iterates over the filesystem contents, looking for all files with the extensions .vmdk, .vmx, .vmxf, .vmsd, .vmsn, .vswp, .vmss, .nvram, and .vmem. All these file extensions are used by virtual machines, for example, disk images, configuration files, swap files, etc.
β
β
The script then calculates the sizes of the files that have the target extensions, and gives the target filename extensions and sizes as arguments to the encrypt binary, along with a .pem key file.Β
β
Upon investigating the usage of the binary, it is found that the .pem file is an RSA public key which is used in the encryption process.
β
β
This commences the encryption process. Note that there is a .args file created for every file that is encrypted, containing metadata about the file. This could be needed for the decryption process.
β
β
Once the files are encrypted, the script first replaces the Message of The Day (.motd) file with the ransom note. It then deletes all log files in order to cover its tracks. It makes sure that the encryption process is over before it proceeds to do so.
β
β
It then deletes the file /sbin/hostd-probe, which is a file used by the hostd daemon to manage virtual machines. In the event that a backup of this file exists, it modifies the timestamp of the file, to hide any changes made to the file.
β
β
Depending on the VMware build, the script executes different operations. If the VMware build version is not 7.0 it executes the following steps to hide any cron jobs run by the root user:
β
For VMware build version 7.0:
β
β
Lastly, the script conducts its clean-up operations. The clean-up operations are as follows:
β
β
After the clean-up operations, the script starts the SSH service, possibly in the event that the threat actor wants to return to the server.
β
The ransomware payload used by the script is a GCC compiled ELF 64-bit binary, which goes by the name encrypt. The arguments that the binary takes are shown below:
β
β
β
β
There are two layers of encryption applied:
β
β
β
OSINT analysis revealed that 3200+ organizations were infected, even though it is tough to ascertain the number of vulnerable servers. However, Shodan and Censys can be used to check for infected organizations.
β
A sample query to check on shodan:Β
html:"We hacked your company successfully" title:"How to Restore Your Files"
β
A similar query can be run on Censys to get infected organizations as well:
β
The group demands the ransom amount via the following BTC addresses:
β
However, there are no transactions on the addresses yet.
β
The ransom note displayed to the victims contains the ransom amount in Bitcoin, and a TOX ID, which the victims are told to reach in order to decrypt their files. Reportedly, the amount of Bitcoin and the TOX ID differ from victim to victim.
β
β
β
β
Researchers at CloudSEKβs Threat Intelligence team have written YARA detection rules for both the files used in this attack. Refer to Appendix.
β
β
YARA Rule for detecting the script
β
YARA Rule for detecting the binary
β
CloudSEK's threat research team has uncovered a ransomware attack disrupting India's banking system, targeting banks and payment providers. Initiated through a misconfigured Jenkins server at Brontoo Technology Solutions, the attack is linked to the RansomEXX group.
Explore the escalating wave of cyber threats on platforms like Google Groups and Usenet, uncovering the pivotal role of cybersecurity in safeguarding online discussion forums.
Threat actors have been abusing advertisement services to serve malware to users and redirect traffic to websites purchasing services from them.
Take action now
CloudSEK Platform is a no-code platform that powers our products with predictive threat analytic capabilities.
Digital Risk Protection platform which gives Initial Attack Vector Protection for employees and customers.
Software and Supply chain Monitoring providing Initial Attack Vector Protection for Software Supply Chain risks.
Creates a blueprint of an organization's external attack surface including the core infrastructure and the software components.
Instant Security Score for any Android Mobile App on your phone. Search for any app to get an instant risk score.
8
min read
In the latest threat actor attack against VMware ESXi servers, a custom ESXiArgs ransomware script is used to exploit the old RCE vulnerability (CVE-2021-21974). Here is a technical analysis of the files used in the ransomware attack.
β
On 03 February 2023, there was a surge in attacks targeting VMware ESXi servers. Threat actors were leveraging an old vulnerability (CVE-2021-21974) in order to gain RCE (Remote Code Execution) and launch ransomware attacks.Β
β
The OpenSLP version used in ESXi versions 7.0 before ESXi70U1c-17325551, 6.7 before ESXi670-202102401-SG, and 6.5 before ESXi650-202102101-SG are vulnerable to a heap-overflow attack, which allowed attackers to perform Remote Code Execution.
β
On 03 February 2023, a member on the Bleeping Computer forum thread, with access to a targeted server, shared a script and an executable, found on their ESXi servers. These files were reportedly used to encrypt the contents of their ESXi servers.
β
β
β
β
β
β
β
The script is written in Bash. It is responsible for preparing the system, and calling the Ransomware payload in order to encrypt files. Once done, it performs a cleanup on the system.
β
The script starts by setting its working directory as /tmp/. Files that it uses for the attack are stored here. After this, it uses the command esxcli vm process list | grep "Config File" | awk '{print $3}' to find the configuration files associated with virtual machines on the server.Β
β
It then replaces the filenames of the disk image and swap file in all config files with 1.vmdk and 1.vswp. This is done to make it difficult for victims to recover and reconfigure the virtual machines, since identifying the disk images and swap files will be nearly impossible.
β
β
β
After this, the script kills the running VM processes using the kill command. The script is now ready to start encryption of all files on the server.
β
β
The script starts its encryption operations by making the encrypt binary executable for all users and groups, using the command chmod +x. Then, it iterates over the filesystem contents, looking for all files with the extensions .vmdk, .vmx, .vmxf, .vmsd, .vmsn, .vswp, .vmss, .nvram, and .vmem. All these file extensions are used by virtual machines, for example, disk images, configuration files, swap files, etc.
β
β
The script then calculates the sizes of the files that have the target extensions, and gives the target filename extensions and sizes as arguments to the encrypt binary, along with a .pem key file.Β
β
Upon investigating the usage of the binary, it is found that the .pem file is an RSA public key which is used in the encryption process.
β
β
This commences the encryption process. Note that there is a .args file created for every file that is encrypted, containing metadata about the file. This could be needed for the decryption process.
β
β
Once the files are encrypted, the script first replaces the Message of The Day (.motd) file with the ransom note. It then deletes all log files in order to cover its tracks. It makes sure that the encryption process is over before it proceeds to do so.
β
β
It then deletes the file /sbin/hostd-probe, which is a file used by the hostd daemon to manage virtual machines. In the event that a backup of this file exists, it modifies the timestamp of the file, to hide any changes made to the file.
β
β
Depending on the VMware build, the script executes different operations. If the VMware build version is not 7.0 it executes the following steps to hide any cron jobs run by the root user:
β
For VMware build version 7.0:
β
β
Lastly, the script conducts its clean-up operations. The clean-up operations are as follows:
β
β
After the clean-up operations, the script starts the SSH service, possibly in the event that the threat actor wants to return to the server.
β
The ransomware payload used by the script is a GCC compiled ELF 64-bit binary, which goes by the name encrypt. The arguments that the binary takes are shown below:
β
β
β
β
There are two layers of encryption applied:
β
β
β
OSINT analysis revealed that 3200+ organizations were infected, even though it is tough to ascertain the number of vulnerable servers. However, Shodan and Censys can be used to check for infected organizations.
β
A sample query to check on shodan:Β
html:"We hacked your company successfully" title:"How to Restore Your Files"
β
A similar query can be run on Censys to get infected organizations as well:
β
The group demands the ransom amount via the following BTC addresses:
β
However, there are no transactions on the addresses yet.
β
The ransom note displayed to the victims contains the ransom amount in Bitcoin, and a TOX ID, which the victims are told to reach in order to decrypt their files. Reportedly, the amount of Bitcoin and the TOX ID differ from victim to victim.
β
β
β
β
Researchers at CloudSEKβs Threat Intelligence team have written YARA detection rules for both the files used in this attack. Refer to Appendix.
β
β
YARA Rule for detecting the script
β
YARA Rule for detecting the binary
β