ESXiArgs—Ransomware Attack on VMware
By: Craig Kennedy
Earlier this month, thousands of VMware ESXi servers were attacked around the globe by a ransomware gang. What made this attack noteworthy was that it exploited a vulnerability in ESXi that was patched by VMware two years ago.
What Are the Details?
The attack, referred to as ESXiArgs, began on February 2nd and targeted thousands of unpatched ESXi servers. The attacker exploited a vulnerability in the Service Location Protocol (SLP) service that provided the attacker with the ability to execute arbitrary code remotely. Once breached, the attacker deployed ransomware code that encrypted portions of the VMs running under the hypervisor.
The attackers unleashed their assault simultaneously, affecting thousands of servers on the initial day of the attack. A second wave was unleashed ten days later on February 12th. The attackers seemed to focus their attention primarily at servers in EMEA (70%), followed by AMER (23%), and then APAC (7%).
How Could This Have Been Prevented?
The victims of this attack did several things wrong that made themselves vulnerable. First, they didn’t keep their VMware ESXi hypervisors patched and up to date, and second, they had the port for accessing the SLP service (port 427) open with unrestricted access from the internet.
Why Weren’t These Servers Patched?
While there are no valid reasons for not patching these servers, there often can be impediments to patching hypervisors like VMware ESXi. One of the primary reasons given for postponing (or in this case outright avoiding) the patching of hypervisors is that all the virtual machines (VM) running on the physical server needing patching have to either be shut down or migrated to another physical server.
Given the scale of today’s physical server configurations, literally hundreds of VM’s can be running on a single server. This can create a huge impediment for IT teams to patch the underlying hypervisor if not managed properly.
Overprovisioning Leads to More Than Just Performance Issues
VMware supports live migration (moving running VMs from one server to another), however there needs to be sufficient free resources (CPU & memory) within the VM pool in order to migrate them. Unfortunately, many IT teams, in an attempt to get the most value out of their hardware, will overprovision a VM pool and not reserve enough free resources to completely evacuate a server in order to patch the hypervisor.
Always Follow the Rule of N+1
When provisioning hardware for a VM pool, at a minimum have the equivalent of one server free and available. This not only provides the ability to easily free up a server to patch without impacting running applications, but it also provides resource redundancy for automated failover in case of a hardware failure on any given server.
Old Vulnerabilities Will Resurface—It’s Just a Matter of Time
Just because a vulnerability is old, and you haven’t fallen victim to an attacker yet doesn’t mean you can ignore it. Take the time to review all systems in use within your enterprise to ensure you are at the latest patch levels. If not, patch them as soon as possible.
If there are impediments to keeping your resources from getting patched in a timely manner, provide the resources necessary to remove these impediments. It will be far less expensive to proactively fix the problem than attempting to pick up the pieces following a successful ransomware attack.
Bottom Line
IT teams must be vigilant in keeping all their infrastructure patched and up to date, not just application software and operating systems, but hypervisors as well. Limit access to all ports, being as restrictive as possible, and create a safety net by keeping current backups of all your virtual machines in a safe and separate location. That safety net will be of little use if it becomes encrypted in a ransomware attack.
For more coverage on cybersecurity, catch analyst Craig Kennedy’s LIVE webinar for FREE.
Thursday, March 30, 2023 at 10 AM PT / 1 PM ET!
This blog is a part of the Digital Operations blog series by Aragon Research’s Sr. Director of Research, Craig Kennedy.
Missed an installment? Catch up here!
Have a Comment on this?