ESXi ransomware: how attackers reach the hypervisor, and the ESXi and vCenter hardening that matters

How ESXi ransomware works and how to harden ESXi and vCenter

ESXi ransomware encrypts virtual machines from the hypervisor rather than inside each guest. In the cases CISA, the FBI and Mandiant describe below, operators came in with privileged credentials and needed no hypervisor exploit: they signed in to vCenter, took root on the hosts, started SSH, powered off the VMs and encrypted their files on the datastores, stopping every VM on the affected hosts together.

The hardening that matters cuts that path at each step: administrator rights that the production directory cannot hand out, lockdown mode with SSH and the ESXi Shell stopped, execInstalledOnly enforced with Secure Boot and a TPM, an isolated management network, patches from Broadcom’s security advisories, remote logs, and backups whose credentials are kept outside the directory. The settings below come from Broadcom’s vSphere 8.0 security configuration guide, last updated 16 September 2026. Broadcom’s 9.0 documentation of 24 August 2026 describes the same lockdown modes and execInstalledOnly enforcement for ESX 9.

The attack path in CISA, FBI and Mandiant reports

CISA, the FBI and HHS wrote in October 2022 that Daixin Team actors used privileged accounts to reach vCenter and “reset account passwords” for the ESXi servers, then “used SSH to connect to accessible ESXi servers and deploy ransomware”. The encryptor worked on files under /vmfs/volumes/, where ESXi exposes every datastore it mounts, shared datastores included. On 29 July 2025, CISA, the FBI and five partner agencies updated their Scattered Spider advisory: the actors search for vCenter infrastructure and backups and “have been observed encrypting VMware ESXi servers”. According to trusted third parties, they may have used DragonForce ransomware in more recent incidents.

Mandiant’s account of 23 July 2025 describes a mid-2025 campaign by UNC3944, whose activity overlaps with public reporting on Scattered Spider. Posing first as an employee and then as a privileged administrator, the operators had the help desk reset both directory passwords. They signed in to vCenter, opened the vCenter appliance’s console, rebooted it into a root shell through GRUB and changed its root password to enable SSH access. They also copied the directory database from a domain controller’s detached virtual disk. From vCenter they then enabled SSH on the ESXi hosts and reset their root passwords. Over SSH they copied the encryptor to a writable directory such as /tmp, powered off every VM with vim-cmd and encrypted the VM files.

ESXi and vCenter hardening controls and what each one stops

Broadcom TechDocs, vSphere 8.0 security configuration guide (16 September 2026; hardware controls 17 July 2026); VMSA-2024-0013; KB 369707; Mandiant, 23 July 2025 (backup row).

Our Cyber Resilience assessment covers infrastructure, access and backups and ends with a risk map and a prioritised action plan. Write to us with your ESXi and vCenter versions and the controls above that are still missing.

Directory-joined hosts, ESX Admins and CVE-2024-37085

When an ESXi host joins the domain, Broadcom’s vSphere 8 documentation states, the directory group ESX Admins “is assigned full administrative access to the host if it exists”, so membership of that group is decided by whoever administers the directory. In VMSA-2024-0013 of 25 June 2024, Broadcom published CVE-2024-37085: with sufficient permissions in the directory, an attacker could gain full access to a joined host by re-creating the configured group, ESX Admins by default, after it had been deleted. CISA added the vulnerability to its catalogue of known exploited vulnerabilities on 30 July 2024. Broadcom fixed it in ESXi 8.0 Update 3 and VCF 5.2 and planned no patch for ESXi 7.0 or VCF 4.x.

On older builds, KB 369707 changes three advanced settings, ideally before the host joins the domain, and they apply within a minute without a reboot. Config.HostAgent.plugins.hostsvc.esxAdminsGroupAutoAdd goes from true to false and Config.HostAgent.plugins.vimsvc.authValidateInterval from 1440 to 90. Config.HostAgent.plugins.hostsvc.esxAdminsGroup goes from “ESX Admins” to an empty value. From 8.0 Update 3 the auto-add setting is false by default, a change Broadcom’s KB 390063 attributes to “security concerns”.

The fix closes this path, but whoever controls the directory still controls any host or vCenter role that takes its members from directory groups. Broadcom’s vCenter baseline says “The vCenter Server must separate authentication and authorization for administrators” and suggests local SSO groups for authorisation. Mandiant advises against joining ESXi hosts directly to the directory. Separate, named administrator accounts complete the design, as our guide to privileged access management explains.

ESXi lockdown mode, SSH and the ESXi Shell

Lockdown mode turns off direct access to a host, so operations go through vCenter roles and permissions; Broadcom’s ESXi 8 baseline is normal lockdown mode, and lockdown is disabled after installation. In normal lockdown mode, Exception Users with administrator privileges and the accounts in DCUI.Access can still use the DCUI, while strict lockdown mode deactivates the DCUI service. According to Broadcom’s lockdown mode behaviour table, the same accounts can use SSH and the ESXi Shell in both lockdown modes while those services run. DCUI.Access holds root by default, so lockdown mode does not close SSH to root; the baseline keeps the Exception Users list empty.

Broadcom warns of “potential loss of administrative access to hosts” and asks for hosts attached to vCenter, with access and exception lists set, before lockdown mode goes on. Because lockdown mode can be deactivated from the vSphere Client, it does not stop an attacker who holds vCenter administrator rights; it limits direct access to the accounts in Exception Users and DCUI.Access.

SSH and the ESXi Shell are stopped by default with the policy “Start and stop manually”, and Broadcom’s 9.0 documentation tells ESX 9 administrators to keep them “deactivated unless you are performing troubleshooting or support activities”. When SSH is needed, the baseline sets UserVars.ESXiShellTimeOut to 600 seconds, which limits how long the services run, and UserVars.ESXiShellInteractiveTimeOut to 900 seconds for idle sessions.

execInstalledOnly, Secure Boot and VIB acceptance levels

Broadcom says execInstalledOnly “helps protect your hosts against ransomware attacks” by letting the VMkernel execute only binaries packaged and signed as part of a valid VIB. Since ESXi 8.0 this runtime option is on by default, but anyone with root can turn it off with one esxcli command on /User/execInstalledOnly.

Broadcom’s baseline also sets the boot option VMkernel.Boot.execInstalledOnly to True (installation default False), which overrides the runtime option, and turns on Secure Boot enforcement. With TPM 2.0, “the TPM can also enforce the setting for the execInstalledOnly boot option in the sealing policy”, once Secure Boot enforcement is active. KB 373898 sets the boot option with esxcli system settings kernel set and -s execInstalledOnly -v TRUE and, after a reboot, runs esxcli system settings encryption set with --require-secure-boot=TRUE, then with --require-exec-installed-only=TRUE; esxcli system settings encryption get shows the result.

Mandiant wrote that enforced execInstalledOnly “would have directly blocked” the encryptor in the UNC3944 campaign. KB 373898 also says execInstalledOnly does not prevent scripts run through interpreters such as Python, a limitation that exists “up to and including 8.x”. Broadcom warns that Secure Boot with TPM-enforced configuration encryption makes traditional root password recovery unusable, so record the recovery key and check administrator access first.

In Broadcom’s words, the acceptance level “controls what ESXi permits to be installed”. The baseline requires PartnerSupported or higher, also the installation default, at which CommunitySupported packages “are unsigned and are not able to be installed”.

vCenter security hardening, the management network and BMCs

vCenter manages every registered host, and in the cases above its administrator rights reached root on the hosts and on the vCenter appliance. Broadcom’s system design baseline puts virtualisation management interfaces on a dedicated segment without workloads or unrelated systems, reached only by authorised vSphere administrators from authorised workstations. The vCenter baseline limits the appliance firewall to authorised networks, where the default accepts any IP address, and keeps SSH on the appliance deactivated. For BMCs, the hardware baseline asks to deactivate unused functions and access methods and to allow access only from the virtualisation team’s authorised workstations. Our guide to network segmentation and microsegmentation covers the zones and their flows.

VMSA-2026-0006 of 29 July 2026 fixed two critical vCenter flaws that “a malicious actor with network access to vCenter” could exploit. CISA added one of them, CVE-2026-59310 in the vCenter syslog server, to its catalogue of known exploited vulnerabilities on 18 August 2026. The fixed vCenter versions are 9.1.0.0300, 9.0.2.0100, 8.0 U3k and 8.0 U2f. The same advisory fixed CVE-2026-47876, a critical ESX flaw in the VMXNET3 adapter that lets an administrator inside a VM execute code on the host. For CVE-2025-22224, an earlier guest-to-host flaw fixed by VMSA-2025-0004 of 4 March 2025, Broadcom had information to suggest exploitation in the wild.

Broadcom’s baseline says to “update vCenter Server first”, then ESXi. For 7.0, VMSA-2026-0006 refers customers with an extended support contract to Broadcom Support; the dates for 8.x are in our guide to the vSphere 8 end of general support.

Remote logs and backup credentials outside the directory

Broadcom’s vCenter baseline says centralised logging “prevents tampering”. The ESXi baseline sets Syslog.global.logHost to a site-specific collector, and Syslog.global.auditRecord.storageEnable and Syslog.global.auditRecord.remoteEnable to True, so that audit records, off by default, are kept on the host and sent to the collector; vCenter has its own remote log server setting. Keep the collector outside vCenter and the production directory, and run NTP on every host so time stamps line up.

In the campaign Mandiant describes, the backups were gone before the encryption started. The operators had signed in to the backup server with stolen domain administrator credentials, or added an account they controlled to the Veeam Administrators security group in the directory, and deleted every job, snapshot and repository. Mandiant advises a separate, MFA-protected security domain for the backup server and its repositories, or dedicated credentials not joined to the directory, together with immutable repositories. Our guide to the Veeam hardened repository covers the repository side, and the guide to the first 72 hours of ransomware recovery the order of work after an attack.

ESXi hardening checklist for one host

1. Compare the host and vCenter builds with the latest VMSA response matrices; patch vCenter first.
2. Run esxcli system settings encryption get and confirm Secure Boot and execInstalledOnly enforcement are on.
3. Verify the acceptance level (PartnerSupported or higher) and that no CommunitySupported VIBs are installed.
4. Check that TSM-SSH and TSM are stopped on “Start and stop manually”, with shell timeouts of 600 and 900 seconds.
5. Set normal lockdown mode, keep the Exception Users list empty or document each entry, and leave DCUI.Access at root.
6. On a host joined to the directory, run esxcli system permission list and remove entries that should not hold the Admin role; before 8.0 Update 3, apply KB 369707.
7. Point Syslog.global.logHost at the remote collector, set Syslog.global.auditRecord.storageEnable and Syslog.global.auditRecord.remoteEnable to True, and start NTP with the host.
8. Test that the management interface and the BMC answer only from the management network and the administrators’ workstations.
9. Make sure the host’s VMs are in a backup whose administrator credentials are outside the production directory, and note the last test restore.

Our engineering partner Vixen.UNO makes such changes step by step in agreed maintenance windows, with a rollback plan. Tell us how many hosts and vCenter instances you run and which of these checks fail today.

What we do

Under Cyber Resilience, our engineering partner Vixen.UNO audits your security posture across infrastructure, access and backups, and you receive a risk map and a prioritised action plan. The same service builds network segmentation, multi-factor authentication and privileged access management, and Veeam-based backup with a recovery site in Baltneta’s Tier-3 data centres in Lithuania, checked by regular test restores. Under VMware optimisation, Vixen.UNO updates vSphere, vSAN, NSX and VCF in agreed maintenance windows, with a rollback plan at every stage. Eurokommerz holds the contract; the first call is free of charge, and the price of the technical assessment is fixed before work begins.

FAQ