New ESXi ransomware strain spreads, foils decryption tools

Additional update concerns

In addition to rendering the current recovery tools seemingly useless, the Censys' blog post emphasized how the new variant also makes it nearly impossible to trace ransom payments in bitcoin. Tracing bitcoin transactions has led law enforcement to recover ransomware payments, most notably after the attack against the Colonial Pipeline Co. last year.

While Bitcoin addresses in ransom notes of the original ESXiArgs strain differed from victim to victim, the new strain increases that difficulty by removing the addresses from the HTTP body entirely. Instead, victims are asked to contact the attackers through Tox, an instant messaging platform, for payment information.

Between disrupting the decryption tool and obscuring bitcoin addresses, Austin and Ellzey attributed the timing of the strain update to CISA's response, as well as ESXiArgs reports published by the security community.

"They realized that researchers were tracking their payments, and they may have even known before they released the ransomware that the encryption process in the original variant was relatively easy to circumvent," Austin and Ellzey wrote. "In other words: They are watching."

How was initial access achieved?

The Censys blog post also called into question the presumed attack method.

Threat intelligence vendors and authorities, including CISA, believed threat actors were exploiting old ESXi vulnerabilities, specifically CVE-2021-21974, through the Service Location Protocol (SLP). Experts said applying available patches and mitigations for CVE-2021-21974 as well as CVE-2020-3992 could help enterprises defend their hypervisors against the ongoing attacks. Additionally, enterprises have been urged to disable SLP since the attacks started.

But Censys and other security researchers now say that may not be the case.

"As we reported yesterday, OpenSLP does not appear to be the method of attack, given that multiple compromised hosts did not have SLP running," Austin and Ellzey wrote in the blog. "Our suspicion that OpenSLP (CVE-2021-21974) was not the method of attack due to observing several compromised servers not running on the SLP protocol seems to have been correct."

GreyNoise Intelligence has made similar observations. In a blog post Wednesday, Matthew Remacle, senior researcher at GreyNoise Intelligence, said research into the initial attack vector should expand beyond CVE-2021-21974. He referred to the relationship between the ESXiArgs campaign and the heap overflow vulnerability as potentially "blown out of proportion."

While several reports by hosting providers and authorities pointed to the flaw as the likely attack vector, Remacle said GreyNoise is not aware the information has been confirmed by any first-party resources.

"We do not currently know what the initial access vector is, and it is possible it could be any of the vulnerabilities related to ESXi's OpenSLP service," Remacle wrote in the blog.

VMware published a blog post Monday about the ESXiArgs attacks, which urged customers to upgrade to the most recent versions of ESXi. However, the blog post did not cite any specific vulnerabilities, including CVE-2021-21974 or CVE-2020-3992, as the initial attack vector. VMware did say there was no evidence that a zero-day vulnerability had been used in the attacks.