Ransomware gangs have always been focusing on Windows systems, running on the PCs of average users. However, in recent years the focus started shifting from opportunistic attacks to targeted attacks against corporations because that’s where the big money is. This caused an evolution in almost all ransomware code bases, which started supporting Linux and the VMware ESXi platform in addition to Windows.
In the previous blog post, we described ransomware families that explicitly target the ESXi environment. In this blog post, we will summarize the common tactics and techniques that developers implement in ransomware targeting ESXi.
Common Tactics and Techniques
In most cases, ransomware that once targeted Windows systems only gets ported to Linux. As a result, most of the ransomware families targeting VMware ESXi support both Windows and Linux. Only two strains of ransomware, Cheerscrypt and fcker.py did not ever support Windows.
The code of the ransomware families, targeting ESXi is mostly written in C. Sometimes, to speed up the development process, the authors choose to use in their C code classes of the standard C++ library, such as std::vector, std::string, and so on. One example of such ransomware is AvosLocker. In Figure 1 one may find the code of the main function of AvosLocker’s ESXi encryptor, revealing the procedure-oriented approach with occasional usage of C++ classes (marked red). Note how class constructs are only used to access standard libraries rather than being used as a design pattern.
Figure 1: AvosLocker’s ESXi encryptor (0cd7b6ea8857ce827180342a1c955e79c3336a6cf2000244e5cfd4279c5fc1b6).
The most recent developments in the ransomware world have shown that the demand for cross-platform malware pushes gangs to use cross-platform programming languages such as Rust and Go. The BlackCat ransomware, which is believed to be the first widely known ransomware written in Rust, sparked the birth of other families, such as Hive and Luna, also written in Rust, which are other examples of this evolving trend.
Most of the ESXi encryptors require at least one parameter – the path to the target directory, that will be encrypted (for example, “-p” parameter in Figure 2). In contrast, REvil, BlackBasta, and GwisinLocker start the encryption process immediately, even if executed without parameters. Encrypting the files right after execution is the default behavior of Windows ransomware. The reason why there is such a difference of behavior on different platforms is that the attackers are often deploying their encryptors onto the ESXi systems manually, rather than relying on well-established automatic infection mechanisms (which are popular on Windows), such as spreading over email or infecting the machines while moving laterally.
Figure 2: BlackCat’s ESXi encryptor’s parameters (3a08e3bfec2db5dbece359ac9662e65361a8625a0122e68b56cd5ef3aedf8ce1).
Sometimes the ransomware source code leaks, like in the case of Babuk in late 2021. The full source code of this ransomware was published by the author on one of the hacker forums. As one would expect, this simplified the task of rebuilding the existing source code of Babuk and creating customized ESXi encryptors. According to Trend Micro, the ESXi encryptor of the Cheerscrypt ransomware, which was captured in May 2022, was surprisingly similar to the ESXi encryptor of Babuk. The fact that the Conti locker source code was leaked in April 2022 suggests that soon we might see a derivative of that ransomware attacking ESXi environments.
The ESXi encryptors, as the name stands, are mostly interested in encrypting the files that contain the metadata of virtual machines. More specifically, they are looking for files with ESXi-specific extensions, such as .log, .vmdk, .vmem, .vswp, .vmsn, etc. Less often they might implement a denylist with extensions that are not meant to be encrypted. In the figure below, you may see the code of the isVmFile function of RedAlert’s ESXi encryptor, which explicitly checks if the file has one of the extensions.
Figure 3: isVmFile function of the RedAlert‘s ESXi encryptor is looking for files with ESXi-specific extensions only (039e1765de1cdec65ad5e49266ab794f8e5642adb0bdeb78d8c0b77e8b34ae09).
Before the encryption starts, the ESXi encryptor of almost any ransomware family tries to shut down running virtual machines with either the esxcli command or vim-cmd vmsvc/power.off. Some families, such as GwisinLocker, Lockbit, and Conti, first retrieve the list of running virtual machines with this command:
esxcli vm process list
And then they execute the kill command for every running VM:
esxcli vm process kill –type=hard –world-id=<ID>
However, in most cases, the shutdown operation is achieved by executing the two commands, combined altogether. For example, this exact command line was found in AvosLocker’s and RedAlert’s ESXi encryptors:
esxcli –formatter=csv –format-param=fields==”WorldID,DisplayName” vm process list | tail -n +2 | awk -F $’,’ ‘{system(“esxcli vm process kill –type=force –world-id=” $1)}’
Usage of vim-cmd vmsvc/power.off instead of esxcli is rare, and it was found only in Hive and fcker.py. Even less often one can find a combination of esxcli and vim-cmd vmsvc to be used simultaneously, as it is done by BlackCat:
esxcli –formatter=csv –format-param=fields==”WorldID,DisplayName” vm process list | awk -F “\”*,\”*” ‘{system(“esxcli vm process kill –type=force –world-id=”$1)}’for i in `vim-cmd vmsvc/getallvms| awk ‘{print$1}’`;do vim-cmd vmsvc/snapshot
While shutting down VMs before encryption is a good practice, not every ESXi encryptor performs this step. For example, Babuk, Luna, and BlackBasta do not have the ability to shut down the VMs prior to encryption. Some other families, such as RedAlert, must be given an explicit parameter to do so, which may be forgotten by the attackers. In any case, encrypting the VM files when the VMs are still running may lead to file corruption or to the inability to restore the encrypted VMs.
Every ransomware appends a new extension to the name of the encrypted file. The extension, in most cases, indicates the attacking ransomware family. For example, Luna ransomware adds the “.Luna” extension, Cheerscrypt adds the “.Cheers” extension, Lockbit adds “.lockbit.” In some cases, the ransomware attaches random characters to the encrypted file name. For example, BlackCat’s extensions may look like this: “.dkrpx75” , “.kh1ftzx”, or “.wpzlbji.” In other cases, as shown in Figure 4, random characters or digits are appended to a hardcoded extension, which is what RedAlert does in its ESXi encryptor.
Figure 4: RedAlert’s ESXi encryptor adds the .crypt[number] extension to the encrypted files (039e1765de1cdec65ad5e49266ab794f8e5642adb0bdeb78d8c0b77e8b34ae09).
Most ransomware (not only those that target ESXi) drops a text file with a ransom note into the directory with encrypted files. The ransom note is often stored in the ransomware’s binary in plain text, which makes it a candidate for a Yara rule (see Figure 5).
Figure 5: Ransom note of the Conti’s ESXi encryptor is stored in plain text (95776f31cbcac08eb3f3e9235d07513a6d7a6bf9f1b7f3d400b2cf0afdb088a7).
Ransomware families that target Windows normally use crypto functions exported by advapi32.dll or bcrypt.dll. In the Linux world, instead, they do not usually rely on crypto libraries that are available on the system; ransomware that is written in C or C++ prefers to link the crypto libraries statically during the build process. Common libraries are Crypto++, Mbed TLS (see Defray777’s code in Figure 6), libntru, and libcrypto. Malware written in cross-platform languages, such as Rust or Go, often relies on the built-in implementations of crypto algorithms, but in some cases uses third-party libraries.
Figure 6: Defray777‘s ESXi encryptor, which uses the AES implementation of the Mbed TLS library (91ad089f5259845141dfb10145271553aa711a2b).
Similar to “traditional” ransomware, ESXi-targeting ransomware families use a combination of symmetric and asymmetric encryption algorithms.
Nowadays, the most used symmetric algorithms are AES (because of hardware support on some CPUs) and Chacha20 (because of its speed). Some ransomware families (e.g., BlackCat) are even keeping both: if AES-NI is enabled, then the ransomware uses AES, otherwise it switches to Chacha20. Other algorithms we observed are RC4 and Sosemanuk. The first step for every ransomware would be to generate a key for one of the symmetric encryption algorithms described in this paragraph. It uses this key for bulk encryption. To complete the process, the second step usually involves generating a private-public key pair based on RSA (in the vast majority of cases), NTRU, or ECC Curve25519.
At the end of the encryption process, the generated symmetric key is then encrypted with the generated public key; the generated private key is also encrypted with the embedded public key. Then, both encrypted keys are stored either within the encrypted file or in a separate file. In this way, after paying the ransom and providing the encrypted generated private key to the attacker, the generated private key necessary to decrypt the encrypted symmetric key (which was used for encrypting the file in the first place) can be retrieved.
Conclusions
We reviewed the common tactics and techniques the ESXi encryptors implement. A combination of behavioral patterns, embedded strings, specific crypto libraries and other artifacts can be used to detect ransomware samples at scale. To summarize the techniques that are often found in ransomware targeting the VMware ESXi platform, we created a quick cheat list for security researchers, SOC analysts, and system administrators.
- The ESXi encryptors are written mostly in C, shifting towards cross-platform languages such as Rust or Go;
- They are statically linked with Crypto++, Mbed TLS, libntru, or libcrypto;
- They must be executed manually with parameters;
- The encryptors are targeting mostly .log, .vmdk, .vmem, .vswp, and .vmsn files;
- Before encryption, virtual machines are shut down with either esxcli or vim-cmd vmsvc/power.off;
- A new extension, that can identify the ransomware family, is always added to the name of the encrypted file;
- The ransom note, that is a plain text file, is always dropped on disk;
- RC4, AES, Sosemanuk, Salsa20 or Chacha20 are used for bulk encryption; RSA, NTRU, or ECC Curve25519 are used to hide the encryption key.
Details about every ransomware family attacking VMware ESXi can be found below:
| Babuk/Babyk/Babak | |
| Implementation Language | C |
| Target extensions | .log, .vmdk, .vmem, .vswp, .vmsn |
| Resulting extensions | .babyk |
| Crypto algorithms | Sosemanuk; Curve25519 |
| Crypto libraries | sosemanuk.cpp, curve25519-donna, sha256.c |
| Terminates VMs | No |
| Selling model | |
| Hashes | dc90560d7198bf824b65ba2cfbe403d84d38113f41a1aa2f37f8d827fd9e0ceb |
| Notes | https://blog.cyble.com/2021/07/05/deep-dive-into-builder-of-notorious-babuk-ransomware/
Leaked source code: https://github.com/Hildaboo/BabukRansomwareSourceCode |
| AvosLocker | |
| Implementation Language | C with standard C++ libraries |
| Target extensions | .log, .vmdk, .vmem, .vswp, .vmsn if the directory is /vmfs/volumes; all files otherwise |
| Resulting extensions | .avoslinux, .avos2 |
| Crypto algorithms | Chacha20, Salsa20, AES; RSA |
| Crypto libraries | Crypto++ |
| Terminates VMs | Yes, esxcli |
| Selling model | RaaS |
| Hashes | 0cd7b6ea8857ce827180342a1c955e79c3336a6cf2000244e5cfd4279c5fc1b6 |
| Notes | https://blog.cyble.com/2022/01/17/avoslocker-ransomware-linux-version-targets-vmware-esxi-servers/ |
| ALPHV/BlackCat | |
| Implementation Language | Rust |
| Target extensions | All files with exceptions |
| Resulting extensions | May vary, e.g., .dkrpx75 , .kh1ftzx, .wpzlbji, .nnvjxgy |
| Crypto algorithms | Chacha20, AES; RSA |
| Crypto libraries | Built-in Rust libraries |
| Terminates VMs | Yes, esxcli |
| Selling model | RaaS |
| Hashes | 3a08e3bfec2db5dbece359ac9662e65361a8625a0122e68b56cd5ef3aedf8ce1 |
| Notes | |
| Hive | |
| Implementation Language | Go (old samples), Rust (new samples) |
| Target extensions | All files with exceptions |
| Resulting extensions | .hive or random characters |
| Crypto algorithms | RSA |
| Crypto libraries | Built-in libraries |
| Terminates VMs | Yes, vim-cmd vmsvc/power.off |
| Selling model | RaaS |
| Hashes | 6a0449a0b92dc1b17da219492487de824e86a25284f21e6e3af056fe3f4c4ec0
2e52494e776be6433c89d5853f02b536f7da56e94bbe86ae4cc782f85bed2c4b |
| Notes | https://blog.group-ib.com/hive |
| fcker.py | |
| Implementation Language | Python |
| Target extensions | All files |
| Resulting extensions | Configurable |
| Crypto algorithms | AES; RSA |
| Crypto libraries | openssl (external tool) |
| Terminates VMs | Yes, vim-cmd vmsvc/power.off |
| Selling model | |
| Hashes | |
| Notes | https://news.sophos.com/en-us/2021/10/05/python-ransomware-script-targets-esxi-server-for-encryption/ |
| Luna | |
| Implementation Language | Rust |
| Target extensions | All files with exceptions |
| Resulting extensions | .Luna |
| Crypto algorithms | AES; X25519 |
| Crypto libraries | |
| Terminates VMs | No |
| Selling model | RaaS |
| Hashes | 1cbbf108f44c8f4babde546d26425ca5340dccf878d306b90eb0fbec2f83ab51 |
| Notes | https://www.elastic.co/security-labs/luna-ransomware-attack-pattern |
| REvil/Sodinokibi | |
| Implementation Language | С |
| Target extensions | All files with exceptions |
| Resulting extensions | May vary, e.g., .23wc2s3 |
| Crypto algorithms | |
| Crypto libraries | |
| Terminates VMs | Yes, esxcli |
| Selling model | RaaS |
| Hashes | ea1872b2835128e3cb49a0bc27e4727ca33c4e6eba1e80422db19b505f965bc4 |
| Notes | https://securityaffairs.co/wordpress/119497/cyber-crime/revil-ransomware-linux.html |
| HelloKitty/ViceSociety | |
| Implementation Language | C |
| Target extensions | .vmdk, .vmsd, .vmsn |
| Resulting extensions | HelloKitty: .crypt
ViceSociety: .v-society |
| Crypto algorithms | AES + RSA or AES + NTRU |
| Crypto libraries | |
| Terminates VMs | Yes, esxcli |
| Selling model | |
| Hashes | 8f3db63f70fad912a3d5994e80ad9a6d1db6c38d119b38bc04890dfba4c4a2b2 |
| Notes | https://threatpost.com/linux-variant-of-hellokitty-ransomware-targets-vmware-esxi-servers/167883/ |
| Black Basta | |
| Implementation Language | C++ |
| Target extensions | All files with exceptions |
| Resulting extensions | .basta |
| Crypto algorithms | ChaCha20; RSA |
| Crypto libraries | Mini-GMP |
| Terminates VMs | No |
| Selling model | RaaS |
| Hashes | 0d6c3de5aebbbe85939d7588150edf7b7bdc712fceb6a83d79e65b6f79bfc2ef |
| Notes | |
| DarkSide/BlackMatter | |
| Implementation Language | C++ |
| Target extensions | .log, .vmdk, .vmem, .vswp, .vmsn |
| Resulting extensions | .darkside |
| Crypto algorithms | ChaCha20; RSA |
| Crypto libraries | Crypto++ |
| Terminates VMs | Yes |
| Selling model | RaaS |
| Hashes | 984ce69083f2865ce90b48569291982e786980aeef83345953276adfcbbeece8 |
| Notes | https://www.trendmicro.com/en_us/research/21/e/darkside-linux-vms-targeted.html |
| Defray777/RansomEXX | |
| Implementation Language | C |
| Target extensions | All files with exceptions |
| Resulting extensions | Name of the targeted company, e.g., .31gs1-[random hex number] |
| Crypto algorithms | AES; RSA |
| Crypto libraries | Mbed TLS |
| Terminates VMs | |
| Selling model | |
| Hashes | cb408d45762a628872fa782109e8fcfc3a5bf456074b007de21e9331bb3c5849 |
| Notes | |
| GwisinLocker | |
| Implementation Language | C |
| Target extensions | |
| Resulting extensions | .mcrgnx or name of the targeted company |
| Crypto algorithms | AES |
| Crypto libraries | |
| Terminates VMs | Yes, esxcli |
| Selling model | |
| Hashes | 7594bf1d87d35b489545e283ef1785bb2e04637cc1ff1aca9b666dde70528e2b |
| Notes | https://blog.reversinglabs.com/blog/gwisinlocker-ransomware-targets-south-korean-industrial-and-pharmaceutical-companies |
| Cheerscrypt | |
| Implementation Language | С |
| Target extensions | .log, .vmdk, .vmem, .vswp, .vmsn |
| Resulting extensions | .Cheers |
| Crypto algorithms | Sosemanuk; ECDH |
| Crypto libraries | |
| Terminates VMs | Yes, esxcli |
| Selling model | |
| Hashes | |
| Notes | https://www.trendmicro.com/en_us/research/22/e/new-linux-based-ransomware-cheerscrypt-targets-exsi-devices.html |
| RedAlert/N13V | |
| Implementation Language | C |
| Target extensions | .log, .vmdk, .vmem, .vswp, .vmsn |
| Resulting extensions | .crypt[number] |
| Crypto algorithms | NTRUEncrypt |
| Crypto libraries | libntru |
| Terminates VMs | Yes, esxcli |
| Selling model | |
| Hashes | 039e1765de1cdec65ad5e49266ab794f8e5642adb0bdeb78d8c0b77e8b34ae09 |
| Notes | https://socradar.io/redalert-ransomware-targets-windows-and-linux-mware-esxi-servers/ |
| Lockbit | |
| Implementation Language | C |
| Target extensions | Databases, archives, documents, VMs, etc |
| Resulting extensions | .lockbit |
| Crypto algorithms | AES; ECC (Curve25519) |
| Crypto libraries | |
| Terminates VMs | Yes, esxcli |
| Selling model | RaaS |
| Hashes | f3a1576837ed56bcf79ff486aadf36e78d624853e9409ec1823a6f46fd0143ea |
| Notes | https://www.trendmicro.com/en_us/research/22/a/analysis-and-Impact-of-lockbit-ransomwares-first-linux-and-vmware-esxi-variant.html |
| Conti | |
| Implementation Language | С with standard C++ libraries |
| Target extensions | Databases, VMs, etc |
| Resulting extensions | .exten, .conti |
| Crypto algorithms | ChaCha8/ChaCha20; RSA |
| Crypto libraries | libcrypto |
| Terminates VMs | Yes, esxcli |
| Selling model | RaaS |
| Hashes | 95776f31cbcac08eb3f3e9235d07513a6d7a6bf9f1b7f3d400b2cf0afdb088a7 |
| Notes | Leaked source code: https://github.com/maxamin/conti_locker |
