I created ESXi ransomware its scary easy and why you need proper security

As I am sure you have been reading about a lot lately, ESXi ransomware is gaining momentum and is becoming widespread. It means we, as VI admins, must stay sharp and fully understand the risks of ESXi ransomware and just how easy it is for the bad guys to pull off. I wanted to take it upon myself, even though I am not a developer, to see how easy it is to string some commands together and pull off an encryption process of a virtual machine running in my lab environment.

Video showing how ESXi Ransomware works

It is scary how easy this is

After walking through the steps and seeing this done, my first impression is that it is SCARY easy to create even a malicious shell script that can quickly pull off ESXi ransomware as all the tools needed to do this are natively built into ESXi. What do I mean? Several posts below that show how many of the recent ransomware attacks are successfully shutting down virtual machines and encrypting these, using “in-the-box” command-line tools, such as OpenSSL.

• VMware ESXi Servers Encrypted by Lightning-Fast Python Script | Threatpost
• Conti Group Targets ESXi Hypervisors With its Linux Variant (trellix.com)

So, to understand this better, I wanted to see if it is easy to duplicate the workflow that an attacker could use to encrypt VMs on a target ESXi server. What does this workflow look like?

1. They will infiltrate your network using some means, usually a client’s computer
2. Scanning the network they will find your vSphere infrastructure
3. If you have SSH enabled on your host, it is only a matter of time before they can crack the password
4. Once SSH access is attained, it is game over.
5. They will upload a malicious Python script to your ESXi hosts that effectively shuts down the VMs, and runs OpenSSL to encrypt your virtual machine disk files

What built-in tools in ESXi make this easy for an attacker?

There are a few things that make ESXi, when improperly secured, an easy target for attackers. For one it is Python aware. It can easily run Python scripts. Another is ESXi contains built-in tools native to the operating system that can be used to encrypt your virtual machines, i.e. OpenSSL. Let’s see how.

We are going to pick up the process of ESXi ransomware after they have infiltrated your network and they have SSH access to your host. What’s next?

ESXi Ransomware Step 1

The attacker is going to shut down all the VMs running on the host. How can they easily do this? By using a built-in tool that we have all used from time to time, vim-cmd. Vim-cmd is a command line tool allowing you to perform power operations from the ESXi command line. You can get a listing of all VMs running on any of your ESXi hosts by running the following command:

vim-cmd vmsvc/getallvms

If you just want to get the VM IDs, you can run the following:

(vim-cmd vmsvc/getallvms | sed -e '1d' -e 's/ \[.*$//' | awk '$1 ~ /^[0-9]+$/ {print $1}')

By getting the VM IDs, the attacker has the information needed to pass into vim-cmd to shutdown the virtual machine. For instance, the below will power off a VM with the VM ID 13.

vim-cmd vmsvc/power.off 13

Why do they want to shut down the VMs? Shutting down the VMs gives exclusive access to all the VM files and it provides the effect of the ransomware being felt immediately.

ESXi Ransomware Step 2 – Encrypt Virtual Machine Files

Now that the virtual machine is powered off, I want to show you just how easy it is to encrypt any files in the virtual machine directory.

First, let’s generate a string that will be used for encryption. Using the OpenSSL command line, native to ESXi, you can do the following from the ESXi host. This command will create a random 1024 password string that can be used for encryption.

openssl rand -base64 1024 > key.bin

An attacker could generate this on their workstation and then embed this in the ransomware code or generate something like this on the fly.

Now that we have the key file generated, again we could have done this ahead of time or generated on the fly, we can use the key file to encrypt any file we want in a virtual machine directory, using another OpenSSL command.

Below, I am targeting a Virtual machine in inventory called TestVM1. I will encrypt the VMDK file using the key we just generated. I am creating an encrypted version of the VMDK called TestVM1.vmdkbadday to denote the bad day we are about to have.

openssl enc -aes-256-cbc -md sha256 -salt -in TestVM1.vmdk -out TestVM1.vmdkbadday -pass file:./key.bin

If you note below, you see the “badday” file we created which is the encrypted copy of our VMDK. However, we still see the good copy. If I am an attacker, I can now delete the good copy so that all we are left with is the encrypted copy of our VMDK.

Once the good copy is deleted, if you try to power on your Virtual Machine now, you will receive the message below as the proper VMDK file is no longer found.

However, is the file really encrypted? I renamed the “badday” vmdk to the correct .vmdk extension and tried again. The virtual machine disk is really encrypted as we see below:

Can we decrypt the encrypted virtual disk? Yes, we can. Using the same key file, we can easily use the key file to decrypt the VM disk:

openssl enc -d -aes-256-cbc -md sha256 -salt -in TestVM1.badday -out TestVM1.vmdk -pass file:./key.bin

Once we do this, the virtual machine disk is now decrypted and will be found in the VM directory in inventory. We can now successfully power on the virtual machine.

ESXi Ransomware – Step 3

All we lack now is a ransom note detailing the Bitcoin or other cryptocurrency that is to be paid to receive access back to the virtual machine data. A ransom note that we can easily spin up using a script is created in the virtual machine directory on the datastore.

Easily automated

The steps that I have walked through above can be easily automated. Also, I have in no way made this process eloquent and super slick in a programmatic fashion using Python, etc. If, as a VI admin, I can easily walk through the simple steps needed to pull this off, you can imagine how quickly damage can be done to an unsuspecting and improperly secured vSphere environment with SSH access.

You can imagine an experienced attacker using Python could easily enumerate all the VM IDs, power these off, and then loop through encrypting all the virtual machine files on disk. You can also see that you could easily place the steps shown in the post in a simple Bash script that runs the commands automatically.

Is ESXi insecure because it contains these tools?

No, tools like OpenSSL and others are contained in many other distributions of Linux and other OS’es. Saying these tools shouldn’t be there would be akin to saying we don’t need to be able to have a delete function in an OS as this would allow data to be deteled.

It does underscore security. Like many administrative functions, attackers must be prevented from getting their hands on privileged tools and gaining the ability to run them. Also, VMware does a great job keeping ESXi secure with patches, and VMSA security advisories. It is up to us as VI admins to keep up with the proper patches and security recommendations. Best practices are essential here. Properly designed VMware vSphere environments are much less likely to be compromised than those that aren’t.

Proper security involves layers:

• Network segmentation
• Don’t put your ESXi hosts on your client network
• Keep SSH turned off
• Use lockdown mode for ESXi, etc.

Securing your vSphere environment is crucial

Securing your ESXi servers and vSphere environment, in general, is absolutely critical. Take a look at my other blog post walking through the ways to secure your ESXi host from ransomware here:

• Protect against Black Basta ESXi ransomware – Virtualization Howto

Take a look at the official VMware resource here:

• Ransomware Resource Center | VMware

Wrapping Up

It is becoming a scarier world for enterprise admins securing their business-critical environments. Today, attackers focus on quick and easy targets and targets that can cause the most disruption with the least amount of effort. Compromising enterprise hypervisor environments like ESXi running critical workloads is a prime target of ransomware groups.