chushpan
Professional
- Messages
- 937
- Reaction score
- 734
- Points
- 93
The target of a ransomware attack may not just be a computer or a server running on the network, but an enterprise-class virtual machine, which usually runs many important services. Today, we will analyze the operating principle of a ransomware oriented towards VMware ESXi and talk about how to secure your virtual infrastructure.
Compromising the hypervisor or the infrastructure associated with it can put the entire ecosystem of servers, databases, and business applications at risk. It is not surprising that hacker groups are increasingly focusing their attacks on VMware ESXi, creating specialized ransomware programs aimed at virtual machine files such as *.vmdk, *.vmx, *.vmsn, *.vswp, *.vmem, and others. Today, we will consider a specific case in which a binary ELF file named encrypt and the accompanying Bash script encrypt.sh were discovered. I will describe in detail the stages of the attack: from penetrating the network and gaining access to ESXi to running files, encrypting virtual disks and eliminating traces, which leaves the victim with a choice - pay the ransom or lose data.
An attacker with a special exploit could send a packet to the Horizon server that included a call to JNDI with a malicious class. The Log4j library dynamically loaded it and executed it. Once this class entered the execution environment, it opened up unlimited possibilities for the attacker - from installing additional malware tools to injecting scripts and escalating to the local administrator level. This is how, according to the collected data, in some cases it was possible to penetrate the corporate network and compromise the Horizon server.
After exploiting the vulnerability CVE-2021-44228, the attack does not stop at one machine, because usually the attackers are interested in larger targets. Therefore, they analyze the network environment, find vulnerable nodes and, most importantly, attack the SAM storage in an attempt to extract the NTLM hash of the local administrator. If the same local admin password is used on many servers in a company (or at least on several key machines), this gives the attackers the opportunity to move across the network (lateral movement) using pass-the-hash.
When a node is detected where a user session from the Domain Admins group is running, the lsass.exe dump or a similar tool allows you to get the NTLM hash of the domain admin, after which the attackers can perform any actions on behalf of the domain administrator, including access to ESXi if authentication is configured through domain accounts.
If the Domain Admin account without strict isolation also has the right to connect to ESXi, then the attackers will certainly take advantage of this, because, having mastered domain privileges, they can easily download the desired malware to /tmp or another directory on the hypervisor (using SCP or another method). In our case, the attackers download the encrypt and encrypt.sh files - two components that work together.
In the code you can find the following constants:
They are used for Base64 in the process of decoding the built-in key string, "sewn" directly into the binary. The original length decoded_length is written here, the read string is used to generate a new key by the generate_key function. The generate_key function takes six arguments:
The steps to execute this part of the malicious application.
The next step is to initialize the partition list and check the file system. This part of the code, as the function name suggests, is responsible for creating the init_partition partition list and adding a new partition if there are none or if the check_file_system function returns an invalid value. The program then checks whether the input structure is a valid MBR or GPT. This function ensures that the array is dynamically expanded (if the array is full, its capacity is doubled) and manages the creation of new partitions if necessary, preventing a gap between the last partition and the newly created one. The malware then begins encrypting each part of the block or file partition. This function iteratively processes the partition array, calling one of two encryption functions:
Let's take a closer look at how each of these functions works. The function processes a file system section in 100 MB blocks, then calls the block encryption function and offsets the same amount of data. The encrypt_file_block function provides encryption of a part of the file, which is processed in fixed-size blocks (up to 10 MB). First, a temporary buffer memory is allocated, which will be used to read and process the data. Then the function starts a loop in which data from the file is read into the buffer, encrypted using the Sosemanuk algorithm, and then written back to the file in the same place. When encrypt_file_block is called, the file size is read, the number of required passes is calculated, and everything inside the loop is standard. It is clear that, having made sure that their program works, the attackers added a script to clean up traces.
The final step is to clean up resources and write the primary public key. The write_public_key function checks if the file path is valid. If no path is provided, the program fails. The function then encrypts the data based on the provided list of partitions and encryption key and saves the encrypted result to a file with a temporary extension. A new name for the file is then formed by appending the same extension to the original path. The length of the new name is checked to ensure that it does not exceed the allowed limit. If this condition is met, the temporary file is renamed to the final one. If all operations are successful, the function returns a positive result. If an error occurs at any stage, a value indicating failure is returned. Thus, *.vmdk is encrypted “on the spot”, while the data structure itself is corrupted at a low level - virtual machines will not be able to read the necessary blocks and start.
If the script has already been loaded into memory, it terminates its work; if not, the system parameters are set:
Next, it changes the limits (ulimit -p, -n), which removes restrictions on the number of processes and descriptors. This is necessary to launch as many encryption processes in parallel as possible.
Next, it searches for ESXi configuration files that contain links to .vmdk and .vswp, and replaces them with links to 1.vmdk, 1.vswp, and so on using sed. This action breaks the configuration so that the administrator cannot easily start virtual machines and "head-on" restore their functionality. The script also finds and kills VMX processes. From the attacker's point of view, this is necessary so that the released virtual disks are guaranteed to lie on the disk in a consistent form, because if there is an active recording, encryption may encounter conflicts. In addition, stopping the virtual machine ensures that it will be more difficult for the victim to quickly export virtual disks in an intact state. Once the preparatory phase is complete, the bash script runs the actual encrypt binary on all files found: find "/vmfs/volumes/" -type f -name *.vmdk, *.vmx, *.vmsn, *.vswp, *.vmem, *.vmss, *.nvram For each file, it calls nohup /tmp/encrypt "filename" >/dev/null 2>&1&, which means the process is launched in the background, redirecting the output, and allows the script to move on without waiting for the encryption process to complete. Many such encrypt processes can be launched in parallel, which will encrypt several gigabytes of data as quickly as possible. In the process, the script copies the motd to the How To Restore Your Files.txt file, which it places next to each file being encrypted — a typical behavior of ransomware, leaving instructions for the victim. Also, encrypt.sh can change index.html so that when accessing the ESXi interface, the victim is shown a ransom demand message. The last step is deleting logs (find / -name *.log -exec rm -rf {} ) , editing cron (deleting lines or replacing crontabs/root) to hide traces of penetration and to exclude a quick rollback of the configuration through built-in mechanisms.
Combined implementations also include SHA-256, which hashes the intermediate key and then passes it to sosemanuk_schedule to generate round subkeys. Trojan authors love Sosemanuk for its high speed, which is critical when encrypting large files, such as *.vmdk, reaching tens of gigabytes. The question arises: how to minimize the risk of such an attack?
The most important measures can be considered the following. Firstly, regularly update VMware Horizon and related Java components, which allows you to close the Log4Shell vulnerability. Secondly, categorically prohibit the use of a single local administrator password on many servers: if the attacker could not use the NTLM hash of the local admin, he would not be able to expand his presence in the network and reach ESXi. Thirdly, it is necessary to avoid scenarios where Domain Admin has SSH access to the hypervisor.
The best practice remains management segmentation: ESXi is separated from domain accounts, access to SSH is allowed only through unique local users with password rotation. It is also necessary to regularly monitor the integrity of crontab and rotate the ESXi backup image (auto-backup.sh in ESXi usually saves the configuration, but an attacker can also damage it).
Analyzing the behavior of the bash script, you can see that it also provides for the replacement of index.html inside /usr/lib/vmware. In practice, this is done by attackers so that when entering the ESXi web interface, the victim sees not the standard screens, but a message like "All your data is encrypted. Pay X BTC or lose everything." In such scenarios, the Trojan really disables the system, because ESXi cannot run virtual machines without configuration, and *.vmdk files become useless. Some versions of the script also change /etc/motd and /etc/note to threatening messages. To make sure everything is done, the attackers use the kill -9 command for hostd and vmx, and then replace hostd-probe.sh, rhttpproxy/endpoints.conf and other files. This is a very aggressive approach, which results in complete paralysis of the infrastructure.
Another sign of a well-thought-out attack is the use of nohup and background processes. Encrypting large files can take time, so the malware starts several processes, each encrypting its target, performing I/O operations in parallel. With a good storage area network (SAN) and high IOPS, the process itself can be quite fast. An administrator who notices an abnormal load can try to stop the script, but it will be too late: the ransomware processes are still running. In addition, the bash script periodically waits for encrypt to complete, counting /bin/ps | /bin/grep encrypt | /bin/wc -l, so that it can then perform a final cleanup and restore some files (for example, hostd-probe.bak).
The authors of the Trojan also took care to delete log files with the *.log extension, which could shed light on the events that occurred in the system. In practice, many companies consolidate ESXi logs into centralized sources, but failing to do so may make the investigation more difficult. When attempting to perform an incident response, it often turns out that the logs at the /var/log/ level are simply empty or have already been cleared. In addition, cron tasks that could perform backups are destroyed. After completing the operation, the attackers restore /sbin/hostd-probe from .bak to return ESXi to a working state, but with encrypted VMDKs.
Thus, the architecture of an attack from the outside looks like this: a hacker penetrates the company's network through a vulnerable Horizon (Log4Shell), obtains local admin rights, then uses pass-the-hash to reach ESXi, uploads two files there (encrypt and encrypt.sh), sets chmod +x rights for them, runs a script that turns off the virtual machines, breaks the config, and launches mass encryption. Then he clears the logs, replaces the web interface, inserts messages for the victim, and leaves. The company is left without virtual machines and without logs, but with instructions on how to pay the ransom in each directory. Based on known examples of encoders, we can conclude that such a scheme has already been encountered many times, and the use of modern crypto primitives Curve25519 + Sosemanuk reliably blocks the ability to decrypt files without a key. Administrators and security services can only hope for offline backups that were not affected by the encryptor.
If the attack has already occurred, and the virtual disks are encrypted, then the best solution is to roll back from offline backups. And if they are absent, most likely, you will have to negotiate with the attackers. However, as practice shows, such negotiations do not always end with decryption of files, because hackers can easily disappear after receiving the money. It is important to note that some groups used RC4, AES before, but now hybrid schemes (elliptic curves and fast stream cryptography) are increasingly common. This indicates a "mature" level of ransomware developers who do not want to leave a chance for "homemade" cryptanalysis.
In conclusion, I would like to emphasize that this encoder, accompanied by the encrypt.sh script, is a sophisticated tool: the binary provides reliable and fast encryption, and the bash script controls the entire process from disabling virtual machines and breaking configs to deleting logs and replacing the web interface. Numerous commands inside the script show that the authors have a good understanding of the ESXi environment, know which processes are responsible for the VM, which files are critical and in what order they should be edited.
The most effective set of protective measures comes down to installing fresh patches on VMware Horizon (closing Log4Shell), not allowing identical NTLM hashes of the local administrator, strictly segmenting ESXi, disabling unused services, regularly transferring logs to a centralized SIEM or Syslog server, and making full offline backups, which should be stored out of the reach of intruders. If an unfamiliar ELF file or script appears in /tmp or another directory, an urgent check should be carried out, because if encrypt.sh is triggered, the consequences can be catastrophic.
It is advisable to monitor crontabs just in case, checking if extraneous lines have appeared there. It is important to enable multi-factor authentication (MFA), especially for systems using Horizon, to increase the level of protection against unauthorized access. It is also recommended to regularly check the system settings for compliance with the Hardening Guide from VMware. This will allow you to monitor and adjust the configuration in accordance with security recommendations.
All ESXi components must be digitally signed by VMware, and changing the Acceptance Level for unsigned modules is not recommended and is prohibited in certified environments such as PCI DSS. If maximum security is required, Lockdown Mode can be enabled and DCUI.Access can be set to empty. This completely disables access via SSH, CLI, and DCUI, in addition to the standard Secure Boot and Host Profiles. However, this approach complicates diagnostics and recovery in case of failures, so it is only used in environments with very high security requirements. In addition, SSH and CLI access should be minimized, used only when absolutely necessary and disabled after work is completed. We can only hope that today's analysis of this malware will help administrators and information security specialists recognize the threat in time, take action, and organize competent protection of their virtual infrastructure.
Source
Compromising the hypervisor or the infrastructure associated with it can put the entire ecosystem of servers, databases, and business applications at risk. It is not surprising that hacker groups are increasingly focusing their attacks on VMware ESXi, creating specialized ransomware programs aimed at virtual machine files such as *.vmdk, *.vmx, *.vmsn, *.vswp, *.vmem, and others. Today, we will consider a specific case in which a binary ELF file named encrypt and the accompanying Bash script encrypt.sh were discovered. I will describe in detail the stages of the attack: from penetrating the network and gaining access to ESXi to running files, encrypting virtual disks and eliminating traces, which leaves the victim with a choice - pay the ransom or lose data.
Vulnerability and general attack pattern
To understand the full depth of this incident, we need to look at the sequence of actions by the attackers from the exploitation of the CVE-2021-44228 vulnerability on VMware Horizon to the actual launch of encryption on ESXi. The vulnerability, dubbed Log4Shell, became widely known in the winter of 2021–2022 and allowed attackers to execute arbitrary code in the context of a server using vulnerable versions of the Log4j logging library. VMware Horizon, being a complex Java-based product that had included vulnerable components in the past, sometimes remained unpatched, which opened the possibility of conducting an RCE (remote code execution) attack.An attacker with a special exploit could send a packet to the Horizon server that included a call to JNDI with a malicious class. The Log4j library dynamically loaded it and executed it. Once this class entered the execution environment, it opened up unlimited possibilities for the attacker - from installing additional malware tools to injecting scripts and escalating to the local administrator level. This is how, according to the collected data, in some cases it was possible to penetrate the corporate network and compromise the Horizon server.
After exploiting the vulnerability CVE-2021-44228, the attack does not stop at one machine, because usually the attackers are interested in larger targets. Therefore, they analyze the network environment, find vulnerable nodes and, most importantly, attack the SAM storage in an attempt to extract the NTLM hash of the local administrator. If the same local admin password is used on many servers in a company (or at least on several key machines), this gives the attackers the opportunity to move across the network (lateral movement) using pass-the-hash.
When a node is detected where a user session from the Domain Admins group is running, the lsass.exe dump or a similar tool allows you to get the NTLM hash of the domain admin, after which the attackers can perform any actions on behalf of the domain administrator, including access to ESXi if authentication is configured through domain accounts.
If the Domain Admin account without strict isolation also has the right to connect to ESXi, then the attackers will certainly take advantage of this, because, having mastered domain privileges, they can easily download the desired malware to /tmp or another directory on the hypervisor (using SCP or another method). In our case, the attackers download the encrypt and encrypt.sh files - two components that work together.
Malicious File Analysis
The analysis showed that the encrypt ELF binary is a ransomware module written for the 64-bit Linux platform. ESXi uses a Linux image internally, so running an ELF file directly is possible there, especially if the execInstalledOnly = 0 parameter is set (or the necessary shared libraries are compiled). The logic for running the encrypt file is to handle an error when there is no link to the file to encrypt. If the link is present, the encryption process is started. When starting, the binary waits for an argument from the user - the path to the file to be encrypted. At the same time, if you believe the disassembler, the code implements the Curve25519 crypto primitives (for exchanging or generating keys) and Sosemanuk (for fast encryption). Let's analyze the entire sequence of actions of this software. Here is an approximate step-by-step algorithm for executing the function.
- Opening a file. The file is opened for reading and writing in binary mode. If opening the file fails (fopen64 returned NULL), the function returns 1.
- Allocate memory for the key and initialize the database with values.
- Decoding Base64 string and generating key.
In the code you can find the following constants:
Code:
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/They are used for Base64 in the process of decoding the built-in key string, "sewn" directly into the binary. The original length decoded_length is written here, the read string is used to generate a new key by the generate_key function. The generate_key function takes six arguments:
- _int64 privateKey1 — the first private key for Curve25519;
- _int64 privateKey2 — the second private key for Curve25519;
- _BYTE *sosemanukStateBuffer - pointer to Sosemanuk state buffer (stream cipher);
- _BYTE *curve25519PrivateArray - pointer to a 32-byte array for working with Curve25519;
- _int64 sharedSecret1 — buffer for the result of the first call to the curve25519_donna function;
- _int64 sharedSecret2 — buffer for the result of the second call to the curve25519_donna function.
The steps to execute this part of the malicious application.
- Memory Cleanup: This step clears arrays for future use to ensure that there is no residual data.
- Modifying bits (in the first and last bytes of the array). This is a standard procedure for correctly setting up a private key for the Curve25519 algorithm.
- Generating a shared secret using Diffie-Hellman algorithm using Curve2579. The curve25519_donna function is used to perform Diffie-Hellman operations using the Curve25519 algorithm. The sharedSecret1 and sharedSecret2 values are generated using the private key curve25519PrivateArray and two different public keys privateKey1 and privateKey2.
- After the calculations, the private key curve25519PrivateArray is cleared using the secure_memset function to prevent sensitive information from leaking.
- SHA-256 hash is created from sharedSecret2. sha256_init() and sha256_hash(), the hash is prepared and calculated.
- secure_memset(); clears the memory used to calculate SHA-256 to remove intermediate data.
- sosemanuk_schedule() prepares internal states for the Sosemanuk cipher based on the key (SHA-256 result).
- sosemanuk_init() completes the cipher initialization by passing the prepared context.
- After using a key from SHA-256, it is cleared using secure_memset.
The next step is to initialize the partition list and check the file system. This part of the code, as the function name suggests, is responsible for creating the init_partition partition list and adding a new partition if there are none or if the check_file_system function returns an invalid value. The program then checks whether the input structure is a valid MBR or GPT. This function ensures that the array is dynamically expanded (if the array is full, its capacity is doubled) and manages the creation of new partitions if necessary, preventing a gap between the last partition and the newly created one. The malware then begins encrypting each part of the block or file partition. This function iteratively processes the partition array, calling one of two encryption functions:
- encrypt_other_partition - used for partitions that are not the first or that have specific types;
- encrypt_file_block - called for the first partition with no data or for partitions of type 9 (a non-standard or legacy partition type).
Let's take a closer look at how each of these functions works. The function processes a file system section in 100 MB blocks, then calls the block encryption function and offsets the same amount of data. The encrypt_file_block function provides encryption of a part of the file, which is processed in fixed-size blocks (up to 10 MB). First, a temporary buffer memory is allocated, which will be used to read and process the data. Then the function starts a loop in which data from the file is read into the buffer, encrypted using the Sosemanuk algorithm, and then written back to the file in the same place. When encrypt_file_block is called, the file size is read, the number of required passes is calculated, and everything inside the loop is standard. It is clear that, having made sure that their program works, the attackers added a script to clean up traces.
info
Sosemanuk is a stream cipher based on SNOW 2.0 and ideas from the Serpent block cipher. It provides high throughput with a relatively low CPU load, which is very beneficial for processing large files.The final step is to clean up resources and write the primary public key. The write_public_key function checks if the file path is valid. If no path is provided, the program fails. The function then encrypts the data based on the provided list of partitions and encryption key and saves the encrypted result to a file with a temporary extension. A new name for the file is then formed by appending the same extension to the original path. The length of the new name is checked to ensure that it does not exceed the allowed limit. If this condition is met, the temporary file is renamed to the final one. If all operations are successful, the function returns a positive result. If an error occurs at any stage, a value indicating failure is returned. Thus, *.vmdk is encrypted “on the spot”, while the data structure itself is corrupted at a low level - virtual machines will not be able to read the necessary blocks and start.
encrypt.sh script
The second component, encrypt.sh, is extremely important because this script performs a lot of preparatory and final steps. First of all, it checks whether the same script has already been launched before. To do this, it uses a check like ps -c | grep <script_name> | grep -v $$, so as not to conflict with its own PID.If the script has already been loaded into memory, it terminates its work; if not, the system parameters are set:
Code:
esxcli system settings advanced set -o /User/execInstalledOnly -i 0Next, it changes the limits (ulimit -p, -n), which removes restrictions on the number of processes and descriptors. This is necessary to launch as many encryption processes in parallel as possible.
Next, it searches for ESXi configuration files that contain links to .vmdk and .vswp, and replaces them with links to 1.vmdk, 1.vswp, and so on using sed. This action breaks the configuration so that the administrator cannot easily start virtual machines and "head-on" restore their functionality. The script also finds and kills VMX processes. From the attacker's point of view, this is necessary so that the released virtual disks are guaranteed to lie on the disk in a consistent form, because if there is an active recording, encryption may encounter conflicts. In addition, stopping the virtual machine ensures that it will be more difficult for the victim to quickly export virtual disks in an intact state. Once the preparatory phase is complete, the bash script runs the actual encrypt binary on all files found: find "/vmfs/volumes/" -type f -name *.vmdk, *.vmx, *.vmsn, *.vswp, *.vmem, *.vmss, *.nvram For each file, it calls nohup /tmp/encrypt "filename" >/dev/null 2>&1&, which means the process is launched in the background, redirecting the output, and allows the script to move on without waiting for the encryption process to complete. Many such encrypt processes can be launched in parallel, which will encrypt several gigabytes of data as quickly as possible. In the process, the script copies the motd to the How To Restore Your Files.txt file, which it places next to each file being encrypted — a typical behavior of ransomware, leaving instructions for the victim. Also, encrypt.sh can change index.html so that when accessing the ESXi interface, the victim is shown a ransom demand message. The last step is deleting logs (find / -name *.log -exec rm -rf {} ) , editing cron (deleting lines or replacing crontabs/root) to hide traces of penetration and to exclude a quick rollback of the configuration through built-in mechanisms.
General attack analysis
To conduct a more in-depth analysis, it is important to look at the cryptographic details. As mentioned, the Curve25519 cryptographic elliptic curve is typically used to compute the shared secret using the Diffie-Hellman scheme, often multiplied by a private scalar that is previously "masked" (resetting the least significant bits, setting one of the most significant). In encoder trojans, this method is often used to generate an ephemerical key, which can then be either stored on the criminals' side or packed into a special file. If the attackers have the "public part", they can decrypt the files using the "private" component stored on their side.Combined implementations also include SHA-256, which hashes the intermediate key and then passes it to sosemanuk_schedule to generate round subkeys. Trojan authors love Sosemanuk for its high speed, which is critical when encrypting large files, such as *.vmdk, reaching tens of gigabytes. The question arises: how to minimize the risk of such an attack?
The most important measures can be considered the following. Firstly, regularly update VMware Horizon and related Java components, which allows you to close the Log4Shell vulnerability. Secondly, categorically prohibit the use of a single local administrator password on many servers: if the attacker could not use the NTLM hash of the local admin, he would not be able to expand his presence in the network and reach ESXi. Thirdly, it is necessary to avoid scenarios where Domain Admin has SSH access to the hypervisor.
The best practice remains management segmentation: ESXi is separated from domain accounts, access to SSH is allowed only through unique local users with password rotation. It is also necessary to regularly monitor the integrity of crontab and rotate the ESXi backup image (auto-backup.sh in ESXi usually saves the configuration, but an attacker can also damage it).
Analyzing the behavior of the bash script, you can see that it also provides for the replacement of index.html inside /usr/lib/vmware. In practice, this is done by attackers so that when entering the ESXi web interface, the victim sees not the standard screens, but a message like "All your data is encrypted. Pay X BTC or lose everything." In such scenarios, the Trojan really disables the system, because ESXi cannot run virtual machines without configuration, and *.vmdk files become useless. Some versions of the script also change /etc/motd and /etc/note to threatening messages. To make sure everything is done, the attackers use the kill -9 command for hostd and vmx, and then replace hostd-probe.sh, rhttpproxy/endpoints.conf and other files. This is a very aggressive approach, which results in complete paralysis of the infrastructure.
Another sign of a well-thought-out attack is the use of nohup and background processes. Encrypting large files can take time, so the malware starts several processes, each encrypting its target, performing I/O operations in parallel. With a good storage area network (SAN) and high IOPS, the process itself can be quite fast. An administrator who notices an abnormal load can try to stop the script, but it will be too late: the ransomware processes are still running. In addition, the bash script periodically waits for encrypt to complete, counting /bin/ps | /bin/grep encrypt | /bin/wc -l, so that it can then perform a final cleanup and restore some files (for example, hostd-probe.bak).
The authors of the Trojan also took care to delete log files with the *.log extension, which could shed light on the events that occurred in the system. In practice, many companies consolidate ESXi logs into centralized sources, but failing to do so may make the investigation more difficult. When attempting to perform an incident response, it often turns out that the logs at the /var/log/ level are simply empty or have already been cleared. In addition, cron tasks that could perform backups are destroyed. After completing the operation, the attackers restore /sbin/hostd-probe from .bak to return ESXi to a working state, but with encrypted VMDKs.
Thus, the architecture of an attack from the outside looks like this: a hacker penetrates the company's network through a vulnerable Horizon (Log4Shell), obtains local admin rights, then uses pass-the-hash to reach ESXi, uploads two files there (encrypt and encrypt.sh), sets chmod +x rights for them, runs a script that turns off the virtual machines, breaks the config, and launches mass encryption. Then he clears the logs, replaces the web interface, inserts messages for the victim, and leaves. The company is left without virtual machines and without logs, but with instructions on how to pay the ransom in each directory. Based on known examples of encoders, we can conclude that such a scheme has already been encountered many times, and the use of modern crypto primitives Curve25519 + Sosemanuk reliably blocks the ability to decrypt files without a key. Administrators and security services can only hope for offline backups that were not affected by the encryptor.
How to prevent?
In terms of preventing such attacks, it is important not only to “patch Horizon” or “not use the same passwords”, but also to design the entire infrastructure correctly. It is also worth conducting antivirus monitoring, although it does not always help when running ELF files in a special ESXi environment. But at least an analysis of the /tmp system directories can detect executable files that suddenly appeared there. With regular export of logs (syslog) to external storage, you will at least be able to understand when the kill -9 command was executed, when certain lines appeared in cron. This significantly simplifies the investigation of the incident.If the attack has already occurred, and the virtual disks are encrypted, then the best solution is to roll back from offline backups. And if they are absent, most likely, you will have to negotiate with the attackers. However, as practice shows, such negotiations do not always end with decryption of files, because hackers can easily disappear after receiving the money. It is important to note that some groups used RC4, AES before, but now hybrid schemes (elliptic curves and fast stream cryptography) are increasingly common. This indicates a "mature" level of ransomware developers who do not want to leave a chance for "homemade" cryptanalysis.
In conclusion, I would like to emphasize that this encoder, accompanied by the encrypt.sh script, is a sophisticated tool: the binary provides reliable and fast encryption, and the bash script controls the entire process from disabling virtual machines and breaking configs to deleting logs and replacing the web interface. Numerous commands inside the script show that the authors have a good understanding of the ESXi environment, know which processes are responsible for the VM, which files are critical and in what order they should be edited.
The most effective set of protective measures comes down to installing fresh patches on VMware Horizon (closing Log4Shell), not allowing identical NTLM hashes of the local administrator, strictly segmenting ESXi, disabling unused services, regularly transferring logs to a centralized SIEM or Syslog server, and making full offline backups, which should be stored out of the reach of intruders. If an unfamiliar ELF file or script appears in /tmp or another directory, an urgent check should be carried out, because if encrypt.sh is triggered, the consequences can be catastrophic.
It is advisable to monitor crontabs just in case, checking if extraneous lines have appeared there. It is important to enable multi-factor authentication (MFA), especially for systems using Horizon, to increase the level of protection against unauthorized access. It is also recommended to regularly check the system settings for compliance with the Hardening Guide from VMware. This will allow you to monitor and adjust the configuration in accordance with security recommendations.
All ESXi components must be digitally signed by VMware, and changing the Acceptance Level for unsigned modules is not recommended and is prohibited in certified environments such as PCI DSS. If maximum security is required, Lockdown Mode can be enabled and DCUI.Access can be set to empty. This completely disables access via SSH, CLI, and DCUI, in addition to the standard Secure Boot and Host Profiles. However, this approach complicates diagnostics and recovery in case of failures, so it is only used in environments with very high security requirements. In addition, SSH and CLI access should be minimized, used only when absolutely necessary and disabled after work is completed. We can only hope that today's analysis of this malware will help administrators and information security specialists recognize the threat in time, take action, and organize competent protection of their virtual infrastructure.
Source
