No Surprise! ESXiArgs Ransomware Attacks Exploit 2-Year-Old Vulnerability

Targeting VMware ESXi is not new; previous ransomware attacks such as Babuk, AvosLocker, BlackCat, Hive, and others have targeted it as well. The uniqueness of ESXiArgs is that it’s only targeting ESXi and it’s exploiting a two-year-old vulnerability resulting in remote code execution (RCE).

Such attacks are often performed as a blitz attack in an effort to infect several victims at once. Otherwise, other potential victims would patch or remediate the initial attack vector before it can widely spread. In just two weeks, this attack has affected a few thousand victims.

Surprise Attack

While everyone was following the hype around ChatGPT and debating a better alternative from Google and Microsoft, ESXiArgs took advantage of the distraction and launched a large-scale ransomware attack.

Are we surprised? Nope. This is not the first time, and definitely not last, that threat actors exploited old unpatched vulnerabilities to perform a large-scale attack. A few others?

CV-2013-0431 – A vulnerability in JRE exploited by Reveton Ransomware. The CVE is from 2013. It was exploited in 2019-2022.
CVE-2013-1493 – A flaw in Oracle Java exploited by Exxroute Ransomware.
CVE-2019-7481 – A vulnerability in SonicWall used by HelloKitty Ransomware.

The list is long, so we summarized it using the Known Exploited Vulnerabilities Catalog by CISA by the year the CVE was published and when it was exploited in the wild.

The above chart shouldn’t surprise anyone. Previous research shows that more than 60% of the vulnerabilities found in corporate networks were disclosed on or before 2016. Looking at the graph above, we can see that after the first spike caused by CVE publication is around ~1.5 years; the next period is between two and five years. These are the types of exploits we currently see in the “blitz” attacks by ESXiArgs.

Remember Log4J? It’s still being actively exploited.

Because of the complex networks of large enterprises, it generally takes more time to patch vulnerabilities. This also makes the enterprise a perfect victim for cyber threat groups as the following diagram demonstrates.

There are still a lot of unpatched vulnerabilities. As an example, we looked at a similar vCenter vulnerability with RCE exploit CVE-2021-21985, which according to Shodan has hundreds of potentially exposed vulnerable servers.

If you are using ESXi, the following critical CVEs should be patched to protect your organization.

ESXiArgs Initial Vector

The ESXiArgs campaign affected a lot of entities, mainly in France, according to Censys:

As the initial vector the attackers exploited was CVE-2021-21974, several POCs can be found in GitHub.

The CVE itself is two years old and is part of this security advisory. It exploits OpenSLP in ESXi with a heap-overflow vulnerability that may result in remote code execution. A few days after disclosure approximately 6,700 potentially vulnerable and exposed to the internet vCenter servers were found via Shodan service.

It’s important to note that this CVE, like many others, is relevant only if your ESXi instance is exposed to the internet (which is not best practice) or the attacker is already inside your network.

In-depth analysis of the CVE-2021-21974 can be found here.

Campaign Impact

Analyzing the impacted machines with the same ransom note shows a similar demand: 2.01 to 2.09 BTC (~ $45k).

Out of all extracted wallets (~2,800) we have found only four (4) that received payments. As an example, a victim from London paid $44,742.

Following is the message hosted on the infected server:

The payment was completed on 02.03.2023, and as of today, the server is still exposed to the internet, and at the moment of writing, appears to be unpatched.

We will not get into each payment, but there appear to only be a few out of more than 2000 victims.

This small number we believe can be attributed to the best practice of ESXi backups that help companies avoid payment. Additionally, CISA published a tool to restore encrypted virtual machines.

It is worth mentioning that shortly after the above announcement, ESXiArgs released a newer version of the ESXi ransomware changing the encryption process that makes the above script from CISA useless.

Responsibility of the campaign

It is not yet clear who is behind the attack, but there are a few clues pointing to different threat actors.

LockBit – They performed similar attacks, and they announced a new ESXi Ransomware variant in January 2023. On the other hand, none of the victims is reflected in their leak site. It could be some affiliates of LockBit acting on their own.

And yes – “Royal Mail Group” leak was published – but that’s another story.
Babuk – Security researcher Michael Gillespie believes that it appears to be a new strain based on leaked source code from the Babuk ransomware. In the middle of 2022, there was a similar case: CheersCrypt ransomware targeting ESXi that was based on the leaked Babuk source code.
Nevada – French cloud computing provider OVHCloud backtracked on its initial findings suggesting a link to the Nevada ransomware variant.
A new threat actor using a combination of previous ESXi ransomware.

Attacker Plan

Recommendation

Patch your ESXi servers or implement the workaround suggested by VMware.
Do not expose ESXi servers to the internet or whitelist specific IP addresses.
Implement best–practice vulnerability management – but do not rely only on that. A world-class Endpoint Protection Platform (EPP) is still required.
In case of infection, follow the suggested flowchart by CERT-HR:

MITRE ATT&CK:

Tactic	Technique	Description	Observable
Execution	T1059.004 Command and Scripting Interpreter: Unix Shell	Encrypt.sh execution	encrypt.sh
Discovery	T1083 File and Directory Discovery	Searching for all VM files	encrypt.sh
Discovery	T1057 Process Discovery	Killing all processes that may cause deny of access to VM files	encrypt.sh
Impact	T1486 Data Encrypted for Impact	Encrypting VMs	encrypt