New ESXiArgs ransomware version prevents VMware ESXi recovery

New ESXiArgs ransomware attacks now encrypt more extensive amounts of data, making it much more difficult, if not impossible, to recover encrypted VMware ESXi virtual machines.

Last Friday, a massive and widespread automated ransomware attack encrypted over 3,000 Internet-exposed VMware ESXi servers using a new ESXiArgs ransomware.

Preliminary reports indicated that the devices were breached using old VMware SLP vulnerabilities. However, some victims have stated that SLP was disabled on their devices and was still breached and encrypted.

When encrypting a device, an ‘encrypt.sh’ script looks for virtual machine files that match the following extensions:

.vmdk
.vmx
.vmxf
.vmsd
.vmsn
.vswp
.vmss
.nvram
.vmem

For each file found, the script checks the file size and if the file is less than 128MB, it encrypts the entire file in 1MB increments.

However, for files larger than 128 MB, it would calculate a ‘size_step’ which would cause the encryption tool to alternate between encrypting 1 MB of data and not encrypting chunks (size_step in megabytes) of data.

The Encrypt.sh script uses the following formula (slightly modified for readability) to determine which size_step to use:

size_step=((($size_in_kb/1024/100)-1))

This means that for a 4.5GB file, it will generate a size_step of ’45’, causing the encryption tool to alternate between encrypting 1MB of the file and skipping 45MB of the file. So as you can see, a lot of data remains unencrypted after it finishes encrypting a file.

For even larger files, such as a 450 GB file, the amount of skipped data increases dramatically, with size_step becoming ‘4607’, which now alternates between encrypting 1 MB and skipping 4.49 GB of data.

Because of these large chunks of unencrypted data, researchers devised a method to restore virtual machines using the large and primarily unencrypted flat files where the virtual machine’s disk data is stored.

A script created by CISA later automated this recovery process.

Encryption process changed

Unfortunately, another ESXiArgs ransomware wave started today and includes a modified encryption routine that encrypts far more data in large files.

BleepingComputer only learned about the second wave after an administrator posted in the ESXiArgs support topic saying that their server was encrypted and could not be recovered using the methods that had worked previously.

After sharing the samples with BleepingComputer, we noticed that the encryption program had not changed, but the encrypt.sh script’s ‘size_step’ routine had been removed and simply set to 1 in the new version.

This change is illustrated below in a comparison between the original encrypt.sh size_step calculation (left) in the first wave of attacks, with the new shell script (right) in the second wave.

Ransomware expert Michael Gillespie told BleepingComputer that this change causes the encryption tool to alternate between encrypting 1MB of data and skipping 1MB of data.

All files over 128MB will now have 50% of their data encrypted, making them likely unrecoverable.

This change also prevents the previous recovery tools from recovering machines, as the flat files will have too much data encrypted to be useful.

This second wave of attacks also made a minor change to the ransom note by no longer including bitcoin addresses in the ransom note, as shown below.

The removal of the bitcoin addresses was likely due to them being collected by security researchers to track ransom payments.

But even more worryingly, the admin who shared the new samples said they had SLP disabled on their server but still got breached again. They also checked for the vmtool.py backdoor seen in previous attacks and it was not found.

With SLP disabled it becomes even more confusing as to how this server was breached.

BleepingComputer still recommends trying to restore encrypted ESXi servers using CISA’s restore script.

However, it will likely no longer work if you were infected in the second wave of attacks using the new encryption routine.

If you have any questions or need support for ESXiArgs ransomware, we have a dedicated support topic in our forums.