Wow do I hate ESXi Threat Intel (right now)

UPDATE 2023-02-14: in response to an inquiry, GreyNoise researchers went back in time to see if there were exploit attempts closer to when CVE-2021-21974 was released.

From January 1st 2021 through June 1st 2021, 2 IP's were observed exploiting CVE-2021-21974, each active (as observed by GreyNoise sensors) for a single day.

Active 2021-05-25, 45[.]112[.]240[.]81
Active 2021-05-31, 77[.]243[.]181[.]196
‍

a stick figure holding a cinder block yelling "Move y'all I got it!"

‍

In recent days CVE-2021-21974, a heap-overflow vulnerability in VMWare ESXi’s OpenSLP service has been prominently mentioned in the news in relation to a wave of ransomware effecting numerous organizations. The relationship between CVE-2021-21974 and the ransomware campaign may be blown out of proportion. 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.

The Security Community seems to be focusing on a single vulnerability. GreyNoise believes that CVE-2021-21974 makes sense as an initial access vector, but are not aware of any 1st party sources confirming that to be the case. We encourage defenders to remain vigilant and not accept every vendor at their word (including us).

The objective of the following document is to provide clarity to network defenders surrounding the ransomware campaign as it relates the the following items:

Attribution of exploitation vector to a specific CVE
Metrics of vulnerable hosts
Metrics of compromised hosts
How do you “GreyNoise” an unknown attack vector?

Attribution to a specific CVE

CVE-2021-21974 is a heap-overflow vulnerability in ESXi’s OpenSLP service.

CVE-2020-3992 is a use-after-free vulnerability in ESXi’s OpenSLP service.

CVE-2019-5544 is a heap overwrite vulnerability in ESXi’s OpenSLP service.

Back in October 2022, Juniper Networks wrote a blog regarding the potential usage of CVE-2019-5544 / CVE-2020-3992 as part of an exploitation campaign. Due to log retention on the compromised server they were unable to confidently attribute which specific vulnerability resulted in successful exploitation. Instead they focused their blog on the details of the backdoor that was installed post-exploitation.

On February 3rd, 2023 the cloud hosting provider OVH published a notice regarding an active ransomware campaign effecting many of their ESXi customers, hereafter referred to as “ESXiArgs” due to the ransomware creating files with an extension of .args. As part of their notice they provide the following quote:

According to experts from the ecosystem as well as authorities, the malware is probably using CVE-2021-21974 as compromission vector. Investigation are still ongoing to confirm those assumptions.

On February 6th, 2023 VMWare published a security blog acknowledging the “ESXiArgs” campaign and stated:

VMware has not found evidence that suggests an unknown vulnerability (0-day) is being used to propagate the ransomware used in these recent attacks.

In summary, while there are many 3rd party sources of intelligence directly attributing this ransomware campaign to CVE-2021-21974, the first party sources are not.

Tl;dr:

There are several high-profile OpenSLP vulnerabilities in various versions of ESXi

These vulnerabilities have been exploited in the past to install malicious backdoors

No CVE is being concretely attributed as the initial access vector for the ESXiArgs campaign by first-party sources

Metrics of Vulnerable Hosts

There are many companies that scan the internet with benign intentions for inventory, research, and actionable intelligence. GreyNoise sees these companies on a very regular basis, since we operate “sensors” similar to a honeypot. They scan, and we (GreyNoise) listen.

Without going into too much depth, there is a significant complexity jump between “determining if a port is open on a server” and “determining what protocol is operating on a port”.

For scanners, high interaction protocols such as those used by the ESXi OpenSLP service may be checked on a weekly/monthly basis, whereas more common protocols such as HTTP(s) on common ports like 80/443 may be checked nearly constantly.

Much like the variety of benign internet-wide scanning companies, GreyNoise is not the only organization operating honeypots on the internet. This causes biases in reported metrics of potentially vulnerable servers on the public internet.

Once an incident such as the ESXiArgs campaign has begun, “scanning” organizations will ramp up scanning, and “honeypot” organizations will ramp up honeypots. At this point, the ESXiArgs campaign is already underway and accurate metrics can be drawn upon from other attributes.

Tl;dr:

Metrics regarding vulnerable host counts have biases

Metrics regarding vulnerable host counts are scoped estimates

These metrics are still the most accurate reports available

Metrics of Compromised Hosts

One of the publicly visible aspects of the “ESXiArgs” campaign is that a ransom note is made available on a hosts public IP with a title of How to Restore Your Files.

By performing a query for How to Restore Your Files we can generate a list of the autonomous system organizations and countries affected by this campaign, complete with a generated timestamp since this number will continually fluctuate and is only accurate as a point-in-time metric.

bar chart showing ransomed system counts by aso (OVH is top)

bar chart showing ransomed system counts by country (france is top)

Our data partner, Censys, provided the data/query. To see current results, use the query — services.http.response.body: "How to Restore Your Files" and services.http.response.html_title:"How to Restore Your Files”.

Tl;dr:

OVH is the predominantly effected hosting provider

France (where OVH is primarily located) is the most impacted region

The estimated count of compromised hosts at the time of writing is between 1,500 and 2,000 nodes. Censys noted that the initial high water mark of compromised nodes was over 3,500.

How do you “GreyNoise” an unknown attack vector?

GreyNoise has had a tag available for tracking and blocking CVE-2021-21974 since June 2021:

https://viz.greynoise.io/tag/vmware-esxi-openslp-rce-attempt?days=3

At this moment in time, we’re seeing a the Log4j-style conundrum 😬; the majority of CVE related activity is related to benign cybersecurity companies checking for the presence of the vulnerability.

As described above, there is no confirmed reports of the initial CVE exploit vector, so how can GreyNoise help defenders when the attack vector is unknown?

image showing how greynoise can help orgs by enabling them to focus on real targeted threats

As we explained in our “How to know if I am being targeted” blog, IPs that return no results when searched on GreyNoise are traffic that is targeted at your organization.

If your organization observes a connection from an IP that returns no search results in GreyNoise: You should almost certainly prioritize that investigation, because it’s targeting your organization instead of the entire internet. If you find that the IP not known to GreyNoise was connecting to your organization’s VMWare ESXi on TCP/427, you should definitely prioritize that investigation.

In cases where initial access vectors are unknown, using GreyNoise as a filter for internet background noise can help prioritize the things that matter the most, because absence of a signal is a signal itself.