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)

If you are running a VMware environment with multiple vCenters in Enhanced Linked Mode, then chances are, you have inevitably taken snapshots of vCenters and caused a replication issue due to the vmdir DBs being out of sync. In previous posts, I have talked about how this replication works, and how to not break this replication.

In this post, I will explain the quickest way to repair and recover from a broken replication state and bring all the vCenters back in sync.

VMware GSS has multiple internal scripts and KBs to repair the vmdir DB replication in place. However, there is a publicly accessible utility that also lets us repair the replication. Its called cross-domain repoint.

https://blogs.vmware.com/vsphere/2019/10/repointing-vcenter-server-to-another-sso-domain.html

Given the close integration of the SDDC Manager with all the components comprising a VCF Environment, making changes to components can be a bit of a challenge. In this article, lets talk about one of the more simpler changes - Renaming components.

As a rule, making changes to any object or component that is a part of a VCF Environment should only be done through the SDDC Manager. Making changes directly on the component itself is UNSUPPORTED - as SDDC Manager will not have visibility over this change, thereby causing a discrepancy in the inventory information.

While the changes should only be made through the SDDC Manager, there is no mechanism or workflow in place that restricts one from making the changes directly via the component itself. However, as mentioned above, the change still is unsupported. If any changes are made which cause a deviation from the inventory information that the SDDC Manager holds, this can (and will) cause issues with any number of Day-2 operations and workflows (such as adding hosts and WLDs, updates/upgrades, expanding clusters)

In terms of actually renaming components in a VCF Environment, as of VCF 4.5, here are the following components that support renaming:

A recent post from VMware talked about a new malware for ESXi, based on information published by Mandiant - which is a cyber-security firm (a subsidiary of Google). You can read the VMware KB here.

The full posts from Mandiant can be found here:
https://www.mandiant.com/resources/blog/esxi-hypervisors-malware-persistence
https://www.mandiant.com/resources/blog/esxi-hypervisors-detection-hardening

In this post, I am going to discuss the key aspects of this issue.

What are Mandiant's findings?

Mandiant found malware on ESXi hosts that was basically installed using unsigned VIBs. The unsigned VIBs contain backdoors which then compromise the ESXi host. At that point, anything on the host can be considered as compromised - commands can be sent for execution on Guest VMs, files can be transferred between ESXi and the Guest VMs etc.