The new ESXiArgs ransomware attacks now encrypt larger amounts of data, making it significantly more difficult, if not impossible, to recover encrypted VMware ESXi virtual machines.

Last Friday, a huge and encrypted widespread automated ransomware attack over 3,000 VMware ESXi servers exposed to the internet using new ransomware ESXiArgs.

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

When encrypting a device, an ‘encrypt.sh’ script looks for virtual machine files matching 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, encrypts the entire file in 1MB increments.

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

The encrypt.sh script uses the following formula (modified slightly for readability) to determine which size_step should be used:

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

This means that for a 4.5GB file, it would generate a size_step of ’45’, which would cause the encryptor to alternate between encrypting 1MB of the file and skipping 45MB of the file. So, as you can see, a lot of the data remains unencrypted by the time a file’s encryption is complete.

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

Because of these large chunks of unencrypted data, researchers designed a method to recover virtual machines using large and mostly unencrypted flat files, where virtual machine disk data is stored.

A script created by CISA then automated this recovery process.

Changed encryption process

Unfortunately, a second wave of ESXiArgs ransomware started today that includes a modified encryption routine that encrypts significantly more data in large files.

BleepingComputer was first notified of the second wave after an administrator posted in the ESXiArgs support topic stating that their server was encrypted and could not be recovered using methods that had previously worked.

After sharing the examples with BleepingComputer, we noticed that the encryptor had not changed, but the ‘size_step’ routine from the encrypt.sh script had been removed and just set to 1 in the new version.

This change is illustrated below in a comparison between the initial computation of encrypt.sh size_step (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 alternates the encryptor between encrypting 1MB of data and skipping 1MB of data.

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

This change also prevents previous recovery tools from successfully recovering machines because flat files will contain too much encrypted data to be usable.

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

Deleting bitcoin addresses was probably due to their collection by security researchers to track ransom payments.

However, even more worryingly, the admin who shared the new samples said he had disabled SLP on his server, only to be breached again. They also checked the vmtool.py backdoor seen in previous attacks, and it was not found.

With SLP disabled, it becomes even more confusing how this server was hacked.

BleepingComputer always recommends attempting to recover encrypted ESXi servers using The CISA recovery script.

However, it probably won’t work anymore if you got infected during the second wave of attacks using the new encryption routine.

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