New ESXiArgs ransomware version prevents VMware ESXi recovery
New ESXiArgs ransomware version prevents VMware ESXi recovery
By Lawrence Abrams
February 8, 2023 10:45 PM 1
VMware ESXi server encrypted
New ESXiArgs ransomware attacks are now encrypting more extensive amounts of data, making it much harder, 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 were still breached 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 that is found, the script checks the file size, and if the file is smaller than 128 MB, encrypts the whole file in 1MB increments.
However, for files larger than 128 MB, it would compute a 'size_step,' which would cause the encryptor to alternate between encrypting 1 MB of data and not encrypting chunks (the size_step in megabytes) of data.
The encrypt.sh script uses the following formula (slightly modified for readability) to determine what size_step should be used:
size_step=((($size_in_kb/1024/100)-1))
This means for a 4.5 GB file, it would generate a size_step of '45,' causing the encryptor to alternate between encrypting 1 MB of the file and skipping 45 MB of the file. So, as you can see, quite a bit of data remains unencrypted by the time it's finished encrypting a file.
For even larger files, like a 450GB file, the amount of skipped data rises dramatically, with the size_step becoming '4607,' now alternating between encrypting 1MB and skipping 4.49 GB of data.
Due to these large chunks of unencrypted data, researchers devised a method to recover 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, a second ESXiArgs ransomware wave started today and includes a modified encryption routine that encrypts far more data in large files.
BleepingComputer first learned of the second wave after an admin posted in the ESXiArgs support topic stating 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 encryptor had not changed, but the encrypt.sh script's 'size_step' routine had been taken out and simply set to 1 in the new version.
This change is illustrated below in a comparison between the original encrypt.sh size_step computation (left) in the first wave of attacks, with the new shell script (right) in the second wave.
Original script on left, new script on right setting size_step to 1
Original script on left, new script on right setting size_step to 1
Source: BleepingComputer
Ransomware expert Michael Gillespie told BleepingComputer that this change causes the encryptor to alternate between encrypting 1 MB of data and skipping 1 MB of data.
All files over 128 MB will now have 50% of their data encrypted, making them likely unrecoverable.
This change also prevents the previous recovery tools from successfully recovering machines, as the flat files will have too much data encrypted to be usable.
This second wave of attack also made a minor change to the ransom note by no longer including bitcoin addresses in the ransom note, as shown below.
The new ESXiArgs ransom note
The new ESXiArgs ransom note
Source: BleepingComputer
The removal of the bitcoin addresses was likely due to them being collected by security researchers to track ransom payments.
However, even more concerning, the admin who shared the new samples said they had SLP disabled on their server but were still 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 attempting to recover encrypted ESXi servers using CISA's recovery 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 on the ESXiArgs ransomware, we have a dedicated support topic in our forums.
By Lawrence Abrams
February 8, 2023 10:45 PM 1
VMware ESXi server encrypted
New ESXiArgs ransomware attacks are now encrypting more extensive amounts of data, making it much harder, 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 were still breached 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 that is found, the script checks the file size, and if the file is smaller than 128 MB, encrypts the whole file in 1MB increments.
However, for files larger than 128 MB, it would compute a 'size_step,' which would cause the encryptor to alternate between encrypting 1 MB of data and not encrypting chunks (the size_step in megabytes) of data.
The encrypt.sh script uses the following formula (slightly modified for readability) to determine what size_step should be used:
size_step=((($size_in_kb/1024/100)-1))
This means for a 4.5 GB file, it would generate a size_step of '45,' causing the encryptor to alternate between encrypting 1 MB of the file and skipping 45 MB of the file. So, as you can see, quite a bit of data remains unencrypted by the time it's finished encrypting a file.
For even larger files, like a 450GB file, the amount of skipped data rises dramatically, with the size_step becoming '4607,' now alternating between encrypting 1MB and skipping 4.49 GB of data.
Due to these large chunks of unencrypted data, researchers devised a method to recover 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, a second ESXiArgs ransomware wave started today and includes a modified encryption routine that encrypts far more data in large files.
BleepingComputer first learned of the second wave after an admin posted in the ESXiArgs support topic stating 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 encryptor had not changed, but the encrypt.sh script's 'size_step' routine had been taken out and simply set to 1 in the new version.
This change is illustrated below in a comparison between the original encrypt.sh size_step computation (left) in the first wave of attacks, with the new shell script (right) in the second wave.
Original script on left, new script on right setting size_step to 1
Original script on left, new script on right setting size_step to 1
Source: BleepingComputer
Ransomware expert Michael Gillespie told BleepingComputer that this change causes the encryptor to alternate between encrypting 1 MB of data and skipping 1 MB of data.
All files over 128 MB will now have 50% of their data encrypted, making them likely unrecoverable.
This change also prevents the previous recovery tools from successfully recovering machines, as the flat files will have too much data encrypted to be usable.
This second wave of attack also made a minor change to the ransom note by no longer including bitcoin addresses in the ransom note, as shown below.
The new ESXiArgs ransom note
The new ESXiArgs ransom note
Source: BleepingComputer
The removal of the bitcoin addresses was likely due to them being collected by security researchers to track ransom payments.
However, even more concerning, the admin who shared the new samples said they had SLP disabled on their server but were still 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 attempting to recover encrypted ESXi servers using CISA's recovery 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 on the ESXiArgs ransomware, we have a dedicated support topic in our forums.
