Skip to Content

Cheerscrypt Ransomware

In this VMware ransomware breakdown we are going to take a closer look at Cheerscrypt.  A very special thank you to our friends at TrendMicro for their great breakdown on Cheerscrypt.  Now, let’s take a closer look at what makes this one a little different from the rest.  

Cheerscrypt Linux Based Ransomware Targets VMware ESXi

Cheerscrypt is an interesting one because it is a Linux based ransomware, without a Windows counterpart, while many other threat actors run with both Linux and Windows versions.
It also follows the ever popular double extortion method of encrypting files as well as exfiltrating data. 
Here’s where things start to get really, really interesting.  TrendMicro noted that Cheerscrypt is based on the Babuk ransnomware which was leaked in 2021.  Babuk ransomware was multiplatform ransomware had versions that targeted Windows, ESXi, and NAS.

How Cheerscrypt Encrypts Virtual Machines

It is important to remember fundamentally how a virtual machine is stored on an ESXi server.  Remember, a virtual machine is nothing but a collection of files living on a storage volume.
Cheerscrypt first shuts down the virtual machines, then encrypts them.  This is because the files that ransomware targets are locked while a VM is running, which means they cannot be encrypted as long as the VM is powered on.  As a bonus, the VMware ESXi host then has extra power to encrypt these files, since now CPU cycles are not being used by virtual machines.
From there, each ransomware strain usually has a slight twist on what type of encryption they use and what processes they follow.  For example, Cheerscrypt renames the files before encrypting them and adding the .Cheers extension.  While the source code looks very very similar, Babuk encrypted the files before renaming them.
diagram of how VMware ransomware works

How ESXi Hosts Get Compromised

To execute the encryption commands, an attacker must have access to the ESXi shell, which is accessible via SSH.  It is IMPERATIVE that SSH IS DISABLED for ESXi hosts. The reason that the ESXi shell feels so much like Linux, and the reason why these Linux ransomware strains work is due to the inclusion of BusyBox in ESXi for management purposes. VMware is NOT Linux.
While you’re at it, go ahead and disable the ESXi shell too.
There are many ways for an attacker to gain this access.  By disabling ssh, one of the most common methods of attack can be disabled.  There are published threat actor playbooks that talk about all of the way to compromise an ESXi system, which I will not be going into detail on.
I will say that it is essential to check out VMware’s ransomware resources, especially the hardening guide for suggestions on how to defend ESXi from ransomware attacks.
Remmeber, threat actors will actively try to compromise your VMware environment, because they know that it is a quick way to cause a lot of damage, and hopefully get you to pay the ransom. After VMware is compromised, I firmly believe that it should be nuked from orbit, and organizations should start over. It is not about recovering the VMware environment itself from a ransomware attack, it is about rebuilding VMware quickly after ransomware.
The virtual machines themselves? Those can be easily recovere from backup, providing they have been protected properly in the first place.
Want to learn more about VMware ransomware variants? Check out some of my other resources:
If you don’t have an incident response plan specifically for your VMware environment, or you aren’t sure about the security configuration, NOW is the time to act. Remember, it isn’t if you are attacked, it is when. A little work now can go a long way later during a ransomware attack.