Critical Infrastructure Security , Cybercrime , Cybercrime as-a-service

Modified ESXiArgs Ransomware Blocks VMware Host Recovery

Updates by Attacker Block Decryption Workaround and Tracking, Researchers Warn
Modified ESXiArgs Ransomware Blocks VMware Host Recovery
Ransom note dropped in first wave of ESXiArgs attacks (Image: Enes Sonmez and Ahmet Aykac)

Attackers targeting unpatched VMware ESXi hypervisors to forcibly encrypt virtual machines have reportedly modified their ransomware to make it more difficult for victims to use free recovery tools to decrypt files.

See Also: Gartner Guide for Digital Forensics and Incident Response

The attack campaign has already used ransomware, dubbed ESXiArgs by VMware, to forcibly encrypt more than 2,800 hosts and an unknown number of virtual machines running across those hosts.

Security experts have detailed a number of defenses they recommend all ESXi users put in place, including immediately isolating servers that haven't been patched against the OpenSLP heap overflow vulnerability - CVE-2021-21974 - being exploited and blocking IP addresses from which attackers' scans have been originating (see: Ransomware: ESXiArgs Campaign Snares at Least 2,803 Victims).

But with a new wave of attacks first seen Wednesday, attackers wielding ESXiArgs appear to have modified the ransomware to complicate easy recovery by victims. The change was first reported by Bleeping Computer, which is offering dedicated support for victims via its forums.

Based on an assessment shared by ransomware hunter Michael Gillespie - @demonslay335, founder of the free ID Ransomware identification service - Bleeping Computer reports that rather than the ransomware encrypting very small parts of large files, as it did before - thus facilitating their recovery - "all files over 128 MB will now have 50% of their data encrypted, making them likely unrecoverable."

Attackers also removed cryptocurrency wallet addresses from ransom notes, it reports. The wallet addresses are where ransomware victims who opt to pay a ransom are instructed to send their bitcoins in return for the promise of a decryption key. Now, victims are instructed to contact attackers via Tox, which is a peer-to-peer, end-to-end encrypted instant messaging protocol, to receive a cryptocurrency wallet address to be used for their payment.

Using the unique cryptocurrency wallet address formerly contained in every different ransom note, researchers were able to count that more than 2,800 VMware ESXi hosts had been forcibly encrypted. By removing these addresses, attackers will complicate efforts by researchers, responders and law enforcement to track the severity of the campaign.

Many More Systems Potentially at Risk

Due to the "new encryption routine that doesn't suffer from the same vulnerability as the last one," IT teams should "expect this to get messy," says Daniel Card, a cyber specialist at London-based Xservus Limited, in a LinkedIn post.

In terms of severity to date, the number of virtual machines, or VMs, that attackers have encrypted so far remains unclear. "Typically an ESXi host would hold 5 to 20 VMs," he says. "Even at 2,000 hosts with 5 VMs on each, that's a lot of VMs." Also, many more than 2,803 hosts may have already been infected.

Using Shodan scans, Card has counted about 70,000 internet-exposed ESXi hosts, out of which about 60,000 match a list of versions "suspected" of being vulnerable to the exploit, although in theory they would also have to have SLP enabled.

Attackers will be doing these same scans, using them to catalog ESXi hosts running apparently vulnerable versions and then directly scanning ports to see if they have SLP enabled on TCP port 427, Card reports. It's possible, he says, that having UDP enabled on that port might also facilitate exploits.

Whether OpenSLP - for service location protocol - must be enabled before attackers are able to successfully use the exploit remains an open question. Multiple victims of the attack campaign appear to have been hit despite SLP not being enabled in their ESXi deployment. "OpenSLP does not appear to be the method of attack, given that multiple compromised hosts did not have SLP running," attack surface management software developer Censys reports.

Despite the changes made to the new wave of ESXiArgs ransomware being used, security experts recommend victims still attempt to use previously detailed recovery techniques, just in case they work.

The recovery techniques are based on the first version of the ransomware oftentimes encrypting only small parts of virtual disks. "The virus encrypts small files" - such as .vmdk and .vmx files - "but not server-flat.vmdk file," according to security researchers Enes Sonmez and Ahmet Aykac, who work with Turkish retailer Yöre Group.

"In ESXi structure, the actual data is kept in flat.vmdk," the researchers added, detailing how this flat file could sometimes - but not always - be used to restore virtual disks with no decryptor required. Based on their research, the U.S. Cybersecurity and Infrastructure Security Agency subsequently released a tool to automate the process.

Card says attackers' initial encryption tactics suggest they're not ransomware criminal masterminds. "From the data I have seen, this is almost certainly a low-skilled cybercrime threat actor or threat actor group," he says. "They made a bit of a cock-up with this; the impact could have been far worse, I think."

But as is typical with ransomware, whenever researchers identify and publicize a vulnerability or shortcoming, attackers oftentimes quickly update their malicious code to try to maximize their profits. As the ESXiArgs campaign continues, so too do attackers' ongoing refinements.


About the Author

Mathew J. Schwartz

Mathew J. Schwartz

Executive Editor, DataBreachToday & Europe, ISMG

Schwartz is an award-winning journalist with two decades of experience in magazines, newspapers and electronic media. He has covered the information security and privacy sector throughout his career. Before joining Information Security Media Group in 2014, where he now serves as the executive editor, DataBreachToday and for European news coverage, Schwartz was the information security beat reporter for InformationWeek and a frequent contributor to DarkReading, among other publications. He lives in Scotland.




Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing bankinfosecurity.com, you agree to our use of cookies.