FEBRUARY 16, 2023

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.

Figure 1: Known exploited vulnerabilities “age”

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.

Figure 2: Reasons why enterprises are often attacked using old vulnerabilities

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.

Figure 3: Exposed vCenter with potential CVE-2021-21985 (7.0.0, 6.5.0, 6.7.0)

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

Figure 4: vCenter CVEs from CVEdetails.com

ESXiArgs Initial Vector

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

Figure 5: Affected countries by ESXiArgs according to Censys.com

As the initial vector the attackers exploited 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:

Figure 8: Ransom note of the above payment

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.

Figure 10: Affected ESXi server unpatched according to Shodan.io

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.

Figure 11: Recover script published by CISA

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.
Figure 12: LockBit leak site

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:

Figure 15: Flowchart in case of infection by CERT-HR

IOCs

73c66de7964b86b9fe32563b7d3195b87896a644c2bcdcaea74b81cb5da2a06b	encrypt.sh
773d147a031d8ef06ee8ec20b614a4fd9733668efeb2b05aa03e36baaf082878	vmtools.py
10c3b6b03a9bf105d264a8e7f30dcab0a6c59a414529b0af0a6bd9f1d2984459	encrypt.sh
5a9448964178a7ad3e8ac509c06762e418280c864c1d3c2c4230422df2c66722	encrypt.sh
11b1b2375d9d840912cfd1f0d0d04d93ed0cddb0ae4ddb550a5b62cd044d6b66	encrypt
7f39818a30879b314ffcff70d2e196fabec60ad94551547cf0e19f6bc3055a97	CVE-2021-21974.py
773d147a031d8ef06ee8ec20b614a4fd9733668efeb2b05aa03e36baaf082878	local.sh
ee1f73140605bc1475792e4b26102caa2b2ef838590f9f73a1e4a39feda72634	Encrypt00.sh
e1d2d6cba7dcc0d87884e9cfdf1a5141dd7649cb8958133fb9bd0659b377ed6e	Encrypt00.sh
c13a5bfb4bddfb1b7ce2fa3e6ae4745566490b50b58e3ff1e57c1d1c2f696760	Encrypt1.sh
11b1b2375d9d840912cfd1f0d0d04d93ed0cddb0ae4ddb550a5b62cd044d6b66	Encrypt
7adde6d89b1e6e5eeaf3aa2e802dcb1c81dae0b3b44550a53d48d75e94a744bf	Hello (Encrypt.sh)

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