The target of an encryption Trojan attack may not just be a computer or a server running on the network, but an enterprise-level virtual machine, which usually runs many important services. Today, we will analyze the operating principle of an encryption Trojan targeting VMware ESXi and talk about how to secure your virtual infrastructure.
Compromising a hypervisor or its associated infrastructure can put an entire ecosystem of servers, databases, and business applications at risk. It’s no surprise that hacker groups are increasingly focusing their attacks on VMware ESXi, creating specialized ransomware that targets virtual machine files such as , , , , and others. Today, we’ll look at a specific case in which a binary ELF file named and an accompanying Bash script were discovered . I’ll detail the attack stages: from penetrating the network and gaining access to ESXi to executing files, encrypting virtual disks, and eliminating traces, leaving the victim with a choice between paying the ransom or losing their data.*.vmdk*.vmx*.vmsn*.vswp*.vmemencryptencrypt.sh
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 moment of exploiting the vulnerability CVE-2021-44228 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 that uses the vulnerable versions of the Log4j logging library. VMware Horizon, being a complex Java-based product that has included vulnerable components in the past, was sometimes left unpatched, which opened the door to 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. As soon as this class got into 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. According to the collected data, this is how 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 administrator password is used on many servers in the 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, a dump or similar tool allows you to obtain the NTLM hash of the domain admin, after which attackers can perform any actions on behalf of the domain administrator, including accessing ESXi if authentication is configured through domain accounts.lsass.exe
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 or another directory on the hypervisor (using SCP or another method). In our case, the attackers download files and — two components that act in conjunction./tmpencryptencrypt.sh
Malicious File Analysis
The analysis showed that the ELF binary encryptis 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 parameter is set (or the necessary shared libraries are compiled).execInstalledOnly = 0
File launch logic encrypt - error handling when there is no link to the file to encrypt. If the link is present, the encryption process is launched.
When starting, the binary expects an argument from the user - the path to the file that will be encrypted. At the same time, if you believe the disassembler, the code implements the crypto primitives Curve25519 (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.
Decoding Base64 string and generating key.
Allocate memory for the key and initialize the database with values.
Opening a file. The file is opened for reading and writing in binary mode. If the file could not be opened ( fopen64returned NULL), the function returns 1.
In the code you can find the following constants:
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
They are used for Base64 in the process of decoding the embedded key string, "sewn" directly into the binary. The original length decoded_lengthis written here, the read string is used to generate a new key by the function generate_key.
The function generate_keytakes six arguments:
_int64 privateKey1— the first private key for Curve25519;_int64 privateKey2— the second private key for Curve25519;_BYTE *sosemanukStateBuffer— pointer to the Sosemanuk (stream cipher) state buffer;_BYTE *curve25519PrivateArray— pointer to a 32-byte array for working with Curve25519;_int64 sharedSecret1— buffer for the result of the first call of 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.
- Generate a shared secret using Diffie-Hellman algorithm using Curve2579. The function
curve25519_donnais used to perform Diffie-Hellman operations using the Curve25519 algorithm. The valuessharedSecret1andsharedSecret2are generated using the private keycurve25519PrivateArrayand two different public keysprivateKey1andprivateKey2. - After the computation, the private key
curve25519PrivateArrayis cleared using the functionsecure_memsetto prevent sensitive information from leaking. - A SHA-256 hash of and is created , the hash is prepared and calculated.
sharedSecret2. sha256_init()sha256_hash() 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 the key from SHA-256, it is cleaned using
secure_memset.
The next step is to initialize the partition list and check the file system.
This part of the code, as you can understand from the name of the functions, is responsible for creating a list of sections init_partition, as well as adding a new section if there are none or an incorrect function value is received check_file_system.
The program then checks whether the input structure is a valid MBR or GPT.
This feature allows the array to grow dynamically (if the array is full, its capacity is doubled) and manages the creation of new partitions as needed, preventing a gap between the last partition and the one just created.
The malware then begins to encrypt each part of the block or file section.
This function iterates through the partition array, calling one of two encryption functions:
encrypt_other_partition- used for sections that are not the first or that have specific types;encrypt_file_block— called for the first partition without data or for partitions of type 9 (non-standard or obsolete partition type).
Let's take a deeper look at how each of these functions works.
The function processes the file system partition in 100 MB blocks, then calls the block encryption function and performs an offset by the same amount of data.
The encrypt_file_block function encrypts a portion of a file, which is processed in fixed-size blocks (up to 10 MB). First, temporary buffer memory is allocated, which will be used to read and process data. Then the function starts a cycle 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 called, encrypt_file_blockthe file size is read, the number of required passes is calculated, and everything is standard inside the cycle. It is clear that, having made sure that their program was working, the attackers added a script to clear traces.
info
Sosemanuk is a stream cipher based on SNOW 2.0 and ideas from the Serpent block cipher. It offers high throughput with a relatively low CPU load, which is very beneficial for processing large files.
The final stage involves clearing resources and recording the primary public key.
The function write_public_keychecks whether the correct file path is passed. If the path is not specified, the program execution terminates with an error. 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, it turns out to be encrypted “on the spot”, while the data structure itself is damaged at a low level - virtual machines will not be able to read the necessary blocks and start.*.vmdk
encrypt.sh script
The second component is — — which is extremely important because this script does a lot of preparatory and final steps. First of all, it checks whether the same script has already been run before. It does this by using a check of the type , so as not to conflict with its own PID.encrypt.shps -c | grep <script_name> | grep -v $$
If the script is already loaded into memory, it terminates its work; if not, the system parameters are set:
esxcli system settings advanced set -o /User/execInstalledOnly -i 0
Next, change the limits ( ), which removes restrictions on the number of processes and descriptors. This is necessary to run as many encryption processes in parallel as possible.ulimit -p, -n
Next comes the search for ESXi configuration files containing references to and , and replacing them with references to , 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 be 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..vmdk.vswp1.vmdk1.vswp
When the preparatory phase is complete, the bash script runs the actual binary encryptfor all found files:
find "/vmfs/volumes/" -type f -name *.vmdk, *.vmx, *.vmsn, *.vswp, *.vmem, *.vmss, *.nvram
For each file it calls , which means it starts the process in the background, redirecting the output, and lets the script move on without waiting for the encryption process to finish.nohup /tmp/encrypt "filename" >/dev/null 2>&1&
Many such encrypt processes can be launched in parallel, which will encrypt several gigabytes of data as quickly as possible. During the process, the script copies motdto a file , which it places next to each encrypted file - typical behavior of extortionists who leave instructions for the victim. It can also change so that when accessing the ESXi interface, the victim is shown a ransom demand message.How To Restore Your Files.txtencrypt.shindex.html
The last step is deleting logs ( ), editing cron (deleting lines or replacing ) to hide traces of penetration and eliminate quick rollback of the configuration through built-in mechanisms.find / -name *.log -exec rm -rf {} ;crontabs/root
General analysis of the attack
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 has been previously “masked” (resetting the least significant bits, setting one of the most significant). In Trojan encoders, 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_schedulegenerate round subkeys. Trojan authors are very fond of Sosemanuk for its high speed, which is critical when encrypting large files, such as , reaching tens of gigabytes. The question arises: how to minimize the risk of such an attack?*.vmdk
The most important measures are the following. First, regularly update VMware Horizon and related Java components, which allows you to close the Log4Shell vulnerability. Second, strictly prohibit the use of a single local administrator password on many servers: if an 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. Third, you need to avoid scenarios where Domain Admin has SSH access to the hypervisor.
The best practice remains management segmentation: ESXi is separated from domain accounts, SSH access 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 ( ESXi usually saves the configuration, but an attacker can also damage it).auto-backup.sh
Analyzing the behavior of the bash script, you can see that it also provides for substitution inside . 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 without configuration cannot run virtual machines, and the files become useless. Some versions of the script also change to threatening messages. To make sure that everything planned is done, attackers use the command for and , and then replace , and other files. This is a very aggressive approach, which results in complete paralysis of the infrastructure.index.html/usr/lib/vmware*.vmdk/etc/motd/etc/notekill -9hostdvmxhostd-probe.shrhttpproxy/endpoints.conf
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, counting , to then perform a final cleanup and restore some files (for example, )./bin/ps | /bin/grep encrypt | /bin/wc -lhostd-probe.bak
The Trojan's authors also took care to delete log files with the extension , which could shed light on the events that occurred in the system. In practice, many companies centralize ESXi logs, but if they do not, the investigation may face difficulties. When attempting to respond to an incident, it often turns out that the logs at the 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 from to return ESXi to a working state, but with encrypted VMDKs.*.log/var/log//sbin/hostd-probe.bak
Thus, the architecture of the attack from the outside looks like this: a hacker penetrates the company's network through a vulnerable Horizon (Log4Shell), gets local admin rights, then uses pass-the-hash to reach ESXi, uploads two files there ( encryptand ), sets their rights , runs a script that turns off virtual machines, breaks the config, and starts 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 for paying the ransom in each directory. Based on known examples of encoders, we can conclude that a similar 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.encrypt.shchmod +x
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 system directories can detect executable files that suddenly appeared there. With regular export of logs (syslog) to external storage, at least it will be possible to understand when the command was executed , when certain lines appeared in cron. This significantly simplifies the investigation of the incident./tmpkill -9
If the attack has already occurred and the virtual disks are encrypted, the best solution is to roll back from offline backups. And if they are absent, you will most likely have to negotiate with the attackers. However, as practice shows, such negotiations do not always end with the decryption of files, because hackers can easily disappear after receiving the money. It is important to note that some groups used RC4, AES, 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 a 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 understand the ESXi environment perfectly, know which processes are responsible for the VM, which files are critical and in what order they should be edited.encrypt.sh
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 that should be stored out of the reach of attackers. If an unfamiliar ELF file or script appears in or in another directory, an urgent check should be carried out, because if it is triggered, the consequences can be catastrophic./tmpencrypt.sh
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 set to an empty value . 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 the event 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.DCUI.Access