ESXiArgs seems to be all the rage right now on the interwebz, with what (in my opinion) started as a reddit post reporting attacks, and quickly spread like wild fire to everyone with a vSphere environment talking about it. What's interesting though, is that the most common vector used to exploit this vulnerability was patched out in late 2021. Sooooo, why has this picked up in early 2023 ?
In this blog post, I am going to briefly discuss what seems to be going on with environments getting hit by ESXiArgs, why this should have never happened in the first place, and finally, prevention and remediation for ESXiArgs.
Lets start with What is ESXiArgs ?
ESXiArgs is the fancy name given to a "new" set of ransomware attacks targeting unpatched and unprotected instances of the ESXi hypervisor. Key points here being "unpatched" ESXi hosts, and scenarios where attackers have direct access to the ESXi management interfaces (for example ESXi management directly exposed to the internet, or a machine that is exposed to the internet that also has direct access to ESXi)
The attack primarily leverages vulnerabilities on the OpenSLP service in the CIM clients on ESXi hosts. The Service Location Protocol (SLP), as per Wikipedia, is a service discovery protocol that allows computers and other devices to find services in a local area network without prior configuration. The Common Information Model, from Wikipedia again, is an open standard that defines how managed elements in an IT environment are represented as a common set of objects. On an ESXi host, CIM is used for hardware monitoring, instead of installing the hardware agents in the Service Console. The different CIM providers monitor the hardware of a host, and provide the status to the CIM broker which lets the host view and present all this hardware monitoring info.
Why is this happening now ?
Well - this one is simpler to answer. Majority of the attacks are targeting versions of ESXi that are unpatched i.e versions containing OpenSLP with the vulnerability. This has been patched in ESXi 6.5, 6.7 and in 7.0 - ESXi 8.0 is unaffected. Turns out - there are a LOT of environments out there running unpatched ESXi hosts. VMware recommendation has always been to run supported versions of VMware software, and update to the latest releases as soon as possible.
In my opinion, its quite baffling that there are so many environments running ESXi that have not been patched in over a year. Uptime is not a high score. With the current security rat-race of malicious parties always finding something (whether new or old) to exploit and hack, and security teams patching/fixing/coding out these vulnerabilities, no one can afford to take security lightly and not apply updates in a reasonable time frame. From the smallest home lab to the biggest organizations - if there is a vulnerability, and if it is exposed - someone will find it and exploit.
VMware has official statements and FAQs about ESXiArgs as well:
Prevention, Remediation and Recovery
The most obvious answer here is - Patch your ESXi Hosts!
The patch for this has been out on all supported ESXi versions for a while now, and running up to date software is the best way to protect your self from not only ESXiArgs, but any and all known vulnerabilities.
If one is running an affected build of ESXi, disabling the SLP service on ESXi can atleast eliminate that one attack vector (not saying that this will 100% protect you from ESXiArgs, but its a start). This KB walks through the workaround of disabling the SLP service on your hosts:
However, there is more to it in terms of prevention. The vSphere environment should be security hardened, and access to the management of any of the core vSphere components should be controlled and restricted. A good starter step is to not expose ESXi management to the internet - that's just asking for trouble.
Lastly, in terms of recovery, CISA (Cybersecurity and Infrastructure Security Agency) has developed a tool to attempt recovery of virtual machines affected by the ESXiArgs ransomware attacks. As per their Github page: This tool works by reconstructing virtual machine metadata from virtual disks that were not encrypted by the malware ... This script does not seek to delete the encrypted config files, but instead seeks to create new config files that enable access to the VMs.