The ESXiArgs ransomware campaign that has run through the past three days has, on the public scanning data, encrypted thousands of internet-exposed VMware ESXi hypervisor hosts globally. The campaign exploits CVE-2021-21974, a heap-overflow vulnerability in the ESXi OpenSLP service that VMware patched in February 2021 — almost two years ago (CERT-FR initial alert, February 3, VMware advisory VMSA-2021-0002). The campaign's success against an exploit chain that has been patched for two years is a substantive comment on the patching-cadence in the broader internet-exposed-ESXi population.
The technical pattern. The OpenSLP service runs by default on ESXi versions and is, on default configuration, accessible from any network the ESXi host is reachable on. Internet-exposed ESXi hosts running unpatched OpenSLP have been potentially vulnerable since 2021; the actual exploitation against the population has, until this campaign, been limited to targeted state-and-criminal-actor activity rather than the mass-campaign pattern. The current campaign's operators appear to have been running mass-internet-scanning against the ESXi population, identifying vulnerable hosts, and deploying the encryption payload at scale. The encryption targets the VM disk files (.vmdk and similar) rather than the ESXi host's own filesystem, which produces operational impact against any running virtual machines on the affected hosts.
The mass-campaign-against-known-vulnerable-population pattern is, in 2023, unusual. The post-Mirai mass-campaign pattern of 2016-2017 against IoT devices was the immediate prior parallel. The intervening years have seen the operator-side pattern shift toward more targeted operations against carefully-selected victims rather than mass-scale opportunistic targeting. The ESXiArgs campaign is, in some respect, a return to the older pattern, possibly because the high-value-per-victim-target population is now more defensively mature than it was several years ago and the marginal economics favour operator-side mass-coverage against the long-tail of less-defended targets.
For the customer-portfolio response. The customer-portfolio ESXi estate is fully patched (the post-Log4Shell SBOM-and-asset-inventory discipline has been operationally applied across the customer estates and the patching cadence is operationally tight). No internet-exposed ESXi hosts in any customer estate. The audit-and-verification cycle this weekend produced no findings. The customer-organisation conversations have been reassuring rather than corrective — the customer-organisation cyber posture has held against this specific pattern.
The wider strategic point about patching cadence in the broader population. The ESXiArgs campaign is the kind of avoidable-in-principle large-scale incident that demonstrates the operational gap between the post-Log4Shell-mature security programmes and the long-tail of less-mature programmes. The customer-portfolio cohort is on the mature side; the wider-economy long-tail is exposed to operational consequences in ways that the customer-portfolio is not. The aggregate-economic cost of the long-tail-exposure is substantial and is the part of the security-economy story that customer-portfolio briefings tend to discuss less than they should — the customer-organisation programmes that have invested adequately are not the population at risk in cases like this, but the broader supply-chain that customer organisations depend on includes substantial less-mature populations whose compromise has knock-on effects.
I will return to this if the campaign produces customer-portfolio-relevant secondary impact.