Hardening VMware ESXi and vCenter against ransomware: a 2026 technical guide, plus Proxmox, Hyper-V and Nutanix

ESXi hardening against ransomware is the set of identity, host, network, logging and backup controls that stops an attacker from encrypting every virtual machine at once from the hypervisor. A single encryption run on a datastore takes down, within minutes, every virtual machine that depends on it: domain controllers, ERP, email and, far too often, the backup infrastructure. That is why ransomware groups have been shipping VMware ESXi variants since 2022, and why a vCenter takeover has become one of the worst scenarios a company can face.

This ESXi and vCenter hardening guide brings together the controls that cut that risk most in vSphere 8 and 9, ordered by phase and with the commands to apply and verify them. It also covers the logs that reveal the attack in time and what changes for organisations that have moved to Proxmox, Hyper-V or Nutanix. It draws on the guides Mandiant published in 2026, Broadcom's security configuration guidance, the DISA STIG (Security Technical Implementation Guide) for ESXi 8 and CISA advisories, checked against what we see in incident response.

Why does ransomware go after the hypervisor?

Ransomware goes after the hypervisor because a single encryption run stops hundreds of servers at once, and because ESXi does not support EDR agents, so the attacker works there with little visibility. Data from the past two years confirms the shift:

• In July 2024, Microsoft reported that its incident response engagements involving ESXi had more than doubled in three years.
• Huntress saw the hypervisor share of malicious encryption rise from 3% in the first half of 2025 to 25% so far in the second, driven mainly by Akira.
• Mandiant's M-Trends 2026 describes ransomware that now encrypts hypervisor datastores instead of individual machines, and that goes first for identity, virtualisation management and backups.

The list of groups with an ESXi encryptor is long: LockBit since January 2022, Black Basta, Royal and BlackSuit, Akira, Qilin, RansomHub, Play and, since 2025, The Gentlemen. In February 2023 the ESXiArgs campaign compromised more than 3,800 servers worldwide, according to the joint CISA and FBI advisory. Akira went a step further in June 2025, when it encrypted virtual machine disks on Nutanix AHV for the first time, according to CISA's updated advisory of November 2025.

The urgency in 2026 sits in vCenter. Broadcom issued advisory VMSA-2026-0006 on 29 July, which we covered in the three critical vCenter and ESXi flaws, and German firm QUIRSO traced malicious activity back to 1 August. According to The Hacker News, around 361 IP addresses in 47 countries were affected, and the attack ended with a Babuk-derived encryptor that, in QUIRSO's view, may also have served to destroy ESXi logs.

What does the attack chain against vSphere look like?

The attack chain against vSphere almost always goes through identity before it reaches the hypervisor, and Mandiant warns that in the hands of UNC3944 (Scattered Spider) it can be completed within hours. Its July 2025 analysis and CISA's Akira advisories describe a recurring sequence, with its mapping to MITRE ATT&CK v20:

1. Initial access with a valid account (T1078), obtained through a call to the service desk, an unpatched VPN or an exposed vCenter flaw.
2. Control of Active Directory and abuse of its relationship with vSphere, for example through the "ESX Admins" group behind CVE-2024-37085, which granted full administration of domain-joined hosts.
3. Access to vCenter Server Appliance and, from there, enabling SSH on the ESXi hosts (T1021.004) and disabling protections such as lockdown mode (T1685).
4. Credential theft without touching the guest operating system: the domain controller VM is powered off or cloned and NTDS.dit is extracted from its disk (T1003.003).
5. Deletion of snapshots, backup jobs and repositories (T1490), sometimes after adding accounts to the Veeam administrators group.
6. Mass power-off of virtual machines (T1529) and encryption of the VMDK files with esxcli and scripts (T1059.012 and T1486).

There is also a variant without encryption that calls for the same hardening. The UNC5221 group used the BRICKSTORM backdoor in vCenter with an average dwell time of 393 days, according to Google Threat Intelligence. In October 2026 CrowdStrike linked Warp Panda to zero-day exploitation of CVE-2026-41709, a low-severity flaw that let an administrator act without leaving a trace in ESXi logs, as SecurityWeek reported.

Disclaimer: the commands and settings in this guide are for guidance only and do not replace an assessment of each environment. They must be tested in pre-production, with a backup and a rollback plan, before production use, and some changes, such as TPM configuration encryption, cannot be reverted. Applying them remains each organisation's responsibility. Regulatory references are for information only and do not constitute legal advice.

Which ESXi hardening controls cut the most ransomware risk?

The ESXi hardening controls that cut the most ransomware risk break the chain at identity, the host and the management network, and keep recovery out of the attacker's reach. The table summarises the recommended sequence; the sections that follow explain how to apply each control and what it can break.

Before changing the configuration, the state of every host needs to be known. This PowerCLI report shows in a single table which hosts still have SSH or the shell running, lack lockdown mode, add the "ESX Admins" group automatically or send no logs:

# Exposure inventory for every host managed by vCenter (PowerCLI).
Get-VMHost | Select Name,
@{N="Lockdown";E={$_.ExtensionData.Config.LockdownMode}},
@{N="SSH";E={($_ | Get-VMHostService | ? Label -eq "SSH").Running}},
@{N="ESXiShell";E={($_ | Get-VMHostService | ? Label -eq "ESXi Shell").Running}},
@{N="AutoAddESXAdmins";E={($_ | Get-AdvancedSetting -Name Config.HostAgent.plugins.hostsvc.esxAdminsGroupAutoAdd).Value}},
@{N="ESXAdminsGroup";E={($_ | Get-AdvancedSetting -Name Config.HostAgent.plugins.hostsvc.esxAdminsGroup).Value}},
@{N="Syslog";E={($_ | Get-AdvancedSetting -Name Syslog.global.logHost).Value}}

The esxcli commands in this guide can run through vCenter with Get-EsxCli -V2 in PowerCLI, without opening SSH on the hosts. Each change should also go into the vLCM image, vSphere Configuration Profiles or the host profile, because the next remediation could revert it.

Who should be able to administer vSphere?

Only a small group of named accounts, separate from everyday ones, authenticated with MFA and connecting from dedicated administration workstations. The most effective change is to break the dependency between the production Active Directory and the hosts. Mandiant recommends not joining ESXi to the domain and managing all host access through vCenter roles.

The DISA STIG asks for directory integration for individual accountability, but its rule V-258737 does not apply when the host has no local accounts other than root and service accounts. Without the domain join, accountability comes from named vCenter accounts, whose events record each change. Whoever controls the domain should not, by design, gain control of the hypervisor. Where the domain join stays, Broadcom's values for CVE-2024-37085 must be applied; the flaw is fixed in ESXi 8.0 U3, with no patch planned for the 7.0 branch:

# CVE-2024-37085: values Broadcom publishes as secure defaults (KB 369707).
Get-VMHost | Get-AdvancedSetting -Name Config.HostAgent.plugins.hostsvc.esxAdminsGroupAutoAdd | Set-AdvancedSetting -Value $false -Confirm:$false
Get-VMHost | Get-AdvancedSetting -Name Config.HostAgent.plugins.vimsvc.authValidateInterval | Set-AdvancedSetting -Value 90 -Confirm:$false
Get-VMHost | Get-AdvancedSetting -Name Config.HostAgent.plugins.hostsvc.esxAdminsGroup | Set-AdvancedSetting -Value "" -Confirm:$false
# Permissions already granted survive these values: they are listed and the group entry removed.
esxcli system permission list
esxcli system permission unset -i "DOMAIN\ESX Admins" -g

In vCenter, federation with an identity provider makes it possible to require MFA at sign-in, which an LDAP source does not offer. vSphere supports AD FS from version 7.0, Okta from 8.0 U1, Microsoft Entra ID from 8.0 U2 and PingFederate from 8.0 U3, according to Broadcom's documentation. In VCF 9, federation is configured once through VCF Identity Broker, which covers vCenter, NSX and VCF Operations; the SDDC Manager interface keeps its local account. The administrator@vsphere.local account remains as emergency access, with its password held in a vault and an alert on every use.

The emergency procedure is tested every quarter, including access to the local console through the server's management card (iDRAC, iLO or XCC), which also belongs on the isolated management network. vCenter roles should also withhold the VirtualMachine.GuestOperations privileges from anyone who does not need them, because they run commands inside VMs through VMware Tools; UNC3886 abused them through CVE-2023-20867, according to Mandiant. It is the same principle as the Active Directory tiering model: vCenter, ESXi and backups belong to Tier 0.

What should be locked down on each ESXi host?

Each host should accept no access that bypasses vCenter and run no code that does not arrive in a signed package. Normal lockdown mode forces the host to be managed through vCenter; Broadcom's configuration guide recommends it and considers strict mode unnecessary for most deployments. The exception user list should stay empty unless there is a documented need, and the DCUI.Access setting, which controls who may use the host's local console (DCUI) under lockdown, should be limited to the intended account.

SSH and the ESXi Shell should be stopped and set not to start, with timeouts (UserVars.ESXiShellTimeOut at 600 seconds and UserVars.ESXiShellInteractiveTimeOut at 900, as the STIG sets). The STIG password and lockout policy (three failed attempts, unlock after 900 seconds and a fifteen-character minimum) closes off brute-force attacks on local accounts.

The most effective control against the encryptor is execInstalledOnly, which blocks binaries not installed through a VIB (vSphere Installation Bundle, the signed ESXi software package). ESXi 8 enables its runtime option by default, although Broadcom warns that an upgrade can leave it disabled (article 401376). The boot option, VMkernel.Boot.execInstalledOnly, is a separate setting that the STIG requires.

With Secure Boot and TPM 2.0 the boot option can be enforced, so a host started with it switched off fails to boot. Enforcement does not stop root from disabling the runtime option without a reboot, so that change needs an immediate alert.

Order matters: Secure Boot in the firmware first, then execInstalledOnly and a reboot, and only then enforcement, according to Broadcom article 373898. Hosts go through maintenance mode one at a time, and vendor utilities copied as loose files stop running, which vmkernel.log records as "Execution of non-installed file prevented".

# ESXi 8 enables only the runtime option by default; the boot option must be set.
# 1. Only executables installed through a VIB (requires a reboot).
esxcli system settings kernel set -s execInstalledOnly -v TRUE
esxcli system settings kernel list -o execinstalledonly
# Runtime value (1 = active).
esxcli system settings advanced list -o /User/execInstalledOnly

Once the value is confirmed and the host has rebooted, enforcement is switched on:

# 2. After the reboot, encrypt the configuration with the TPM and require Secure Boot.
esxcli system settings encryption set --mode=TPM
esxcli system settings encryption set --require-secure-boot=TRUE
esxcli system settings encryption set --require-exec-installed-only=TRUE
esxcli system settings encryption get
# 3. Store the recovery secret outside the host before going further.
esxcli system settings encryption recovery list
# 4. Maintenance mode and reboot; TPM mode cannot be reverted.

The recovery secret returned by the last command must be stored in a secrets manager outside vSphere. Without it, replacing a motherboard or TPM means reinstalling the host.

How is the management network isolated?

The management network is isolated in dedicated VLANs and VRFs (separate routing tables), with no internet egress and reachable only from the administration workstation subnet. Mandiant proposes separate networks for host management, vCenter, vMotion, storage and VM traffic, with vMotion and storage non-routable. Ports 443 and 902 are allowed from the administration subnet, and ports 22 and 5480 are opened only from that subnet when a task requires it. Internal network segmentation applies the same logic to the rest of the organisation.

The ESXi firewall already drops unlisted traffic, so the control is an allowed address list for each service. The vSphereClient list (ports 443 and 902) must include vCenter, the administration subnet and the backup proxies, which use port 902 in NBD mode, plus NSX Manager and SDDC Manager in VCF. The addresses go in before "allow all" is removed. SLP, the service ESXiArgs came through, has been off by default since ESXi 7.0 U2c and 8.0, and since 8.0 U2 its firewall rule is managed by the system:

# Allowed address list per service (example: vSphereClient).
# Every address goes in first: vCenter, admin subnet, backup proxies (and NSX Manager and SDDC Manager in VCF).
esxcli network firewall ruleset allowedip add -r vSphereClient -i 10.10.50.0/24
esxcli network firewall ruleset allowedip add -r vSphereClient -i 10.10.60.10
esxcli network firewall ruleset allowedip list -r vSphereClient
# Only then is "allow all" removed; a list without vCenter disconnects the host.
esxcli network firewall ruleset set -r vSphereClient --allowed-all false

For SLP, the check is that it remains off:

# SLP: keep it off (on 7.0 builds before U2c, see Broadcom article 76372; not applicable on ESX 9.0, which removed CIM and the CIMSLP rule).
esxcli system slp set -e 0
esxcli network firewall ruleset list | grep -i cimslp
# The CIMSLP rule should show as false.

How far should vCenter hardening go?

vCenter hardening should reach the same level as a domain controller's, because whoever controls vCenter Server Appliance governs every host. The basics are disabling SSH from the management console (VAMI, port 5480), limiting the SystemConfiguration.BashShellAdministrators group and applying critical patches within days, not in quarterly windows. The 7.0 branch reached end of general support on 2 October 2025, and advisory VMSA-2026-0006 refers its users to Broadcom support.

Since April 2025, patch downloads have required a token tied to the support contract, so that access should be tested before it is needed (the change is described on the VMware blog). For prioritisation, CISA's KEV catalogue is the reference: it includes the three VM escape flaws in advisory VMSA-2025-0004, exploited as zero-days in March 2025, and CISA now links CVE-2025-22225 to ransomware campaigns. The approach is set out in KEV, EPSS and SSVC.

In April 2026, alongside its vSphere and BRICKSTORM guide, Mandiant released an open-source tool that sets a default-deny firewall on the appliance and sends every shell command to syslog. The tool's repository warns that a wrong configuration isolates vCenter immediately and that it may affect the support agreement, so it should only be used after testing in pre-production.

Where should backups live?

Backups should live outside the platform they protect and outside the domain the attacker is trying to control. Mandiant puts it plainly: do not host Active Directory, backups or privileged access management on the virtualisation platform those systems protect. The backup server needs a separate identity domain or local credentials with MFA, and storage must be immutable for the retention period.

Veeam connects to vCenter with a dedicated account limited to the privileges it needs, never administrator@vsphere.local, and its four-eyes authorisation, available since version 12.1, requires a second administrator to approve the deletion of backups or repositories.

VMware snapshots are not backups: they live on the same datastore and disappear with it. Veeam's hardened repository, for example, prevents files from being moved, modified or deleted during the immutability period, according to its documentation. Changes to the Veeam administrators group (Windows event 4728) also need watching, because UNC3944 uses it to delete jobs and repositories before encrypting.

Restores have to be tested with measured times. In Veeam's 2026 report, only 28% of affected organisations recovered all their data. The 3-2-1-1-0 rule sums up the requirements.

Which logs and alerts catch the attack in time?

The logs that catch the attack in time are hostd, vpxa, shell, auth, vobd, vmkernel and esxupdate from each host. vCenter events and the audit log of its single sign-on (SSO) service complete the set. vCenter keeps only 30 days of events by default, so they also need to reach the collector. They should be sent over TLS to an external collector and kept for at least 400 days, the period Mandiant recommends after measuring dwell times of more than a year.

Logs that only live on the host disappear with the encryption, as the VMSA-2026-0006 case showed. ESXi audit records are disabled by default and must be switched on. On hosts that boot from SD or USB, Syslog.global.logDir must point to a persistent datastore other than vSAN, because the ramdisk loses every log on reboot.

# Collector CA in the host store (file uploaded to a datastore) and certificate checking.
esxcli system security certificatestore add --filename=/vmfs/volumes/ds-admin/ca-siem.pem
esxcli system syslog config set --check-ssl-certs=true
esxcli system syslog config set --loghost=ssl://siem.example.local:6514
# The syslog rule covers 514 and 1514; since 8.0 U2b vmsyslogd opens other ports itself.
esxcli network firewall ruleset set -r syslog -e true
# Audit records stored locally (100 MB) and forwarded to the collector.
esxcli system auditrecords local set --size=100
esxcli system auditrecords local enable
esxcli system auditrecords remote enable
esxcli system syslog reload

These signals justify an immediate alert, because they almost never belong to normal operations:

The rules do not have to be written from scratch. Splunk publishes the "ESXi Post Compromise" story with 24 detections, Elastic maintains an equivalent set for its vSphere integration and SigmaHQ includes rules for esxcli. Choosing which logs to send to the SIEM and testing each rule through detection engineering stops the alert from arriving late. A managed SOC watching these sources covers the gap left by a hypervisor without EDR, the same gap discussed in EDR blind spots.

What mistakes are common when hardening ESXi?

The common mistakes are applying controls without testing their operational effect and treating a single control as the whole answer. These are the ones we see most:

• Strict lockdown mode enabled without exception accounts in place: if vCenter goes down, the host may become unreachable and need reinstalling.
• Third-party or VMware tooling that stops working under lockdown mode. In VCF 9, SDDC Manager cannot validate or rotate passwords on hosts in lockdown mode, according to Broadcom article 426417.
• Sole reliance on execInstalledOnly. Broadcom points out that it does not stop scripts run through interpreters such as Python, so it does not replace access control or logging.
• TPM configuration encryption enabled without the recovery secret stored safely.
• A renamed "ESX Admins" group, on the assumption that this removes the previous group's permissions, when the STIG warns that it does not.
• The STIG and Broadcom's guide applied without deciding where they disagree: domain join, the DCUI.Access account, the esxAdminsGroup value and log level.

Every change should go through pre-production, be documented as an exception where it is not applied and be verified afterwards with the PowerCLI report above.

Does anything change in Proxmox, Hyper-V or Nutanix?

The tools change, but the hypervisor management plane is still Tier 0, and attackers already target it outside VMware. After Broadcom's licensing changes, Gartner expects more than a third of the workloads now running on VMware to be on another platform by 2028, according to Techzine. Akira's move to Nutanix AHV shows that a migration without hardening carries the same risk to the new platform.

The same rules from the earlier phases apply on all three platforms: an administration identity separate from the production domain and protected by MFA, an isolated management network, logs kept off the host and backups on another platform with immutable storage.

How does this hardening fit the ENS and NIS2?

ESXi and vCenter hardening serves as direct evidence for ENS measures such as op.acc.6, op.exp.8, mp.com.4 and mp.info.6, and for points (c), (i) and (j) of NIS2 Article 21(2). For Spain's ENS, the CCN publishes guide CCN-STIC 442, "Security Implementation in VMware vSphere 8.x", updated in July 2025, and the controls in this guide map to measures in Royal Decree 311/2022:

• Administration identity and MFA: op.acc.3 and op.acc.4 (segregation of duties and access rights) and op.acc.6 with reinforcements R2 and R8 (second factor).
• Configuration and patching: op.exp.2, op.exp.3 and op.exp.4.
• Off-host logs and alerts: op.exp.8 (activity logging) and op.mon.3 (monitoring).
• Management network separation: mp.com.4 (separation of information flows on the network).
• Immutable, tested backups: mp.info.6 (backups).

Under NIS2, Article 21(2) covers backup management and recovery in point (c), access control in point (i) and multi-factor authentication in point (j). Spain still has no transposition law; what that means for companies is explained in NIS2 without a national law. The systems hardening page details how each control is documented for an audit.

Where should a team start this week?

The order that cuts the most risk in the fewest days starts with patches and ends with architecture:

1. Confirm that vCenter and ESXi run versions fixed for VMSA-2026-0006 and for every VMware vulnerability in the KEV catalogue.
2. Run the PowerCLI report and close SSH, the shell and the "ESX Admins" group on every host.
3. Send ESXi and vCenter logs to an external collector and enable the alerts in the table.
4. Verify that backups and their console sit outside vSphere and the production domain, and test a full restore.
5. Plan execInstalledOnly with Secure Boot enforcement, starting with a test cluster.
6. Design the management network separation and vCenter federation with MFA.

Is the order different if encryption is already under way?

Yes: if there are signs of compromise, containment and evidence preservation come first, and hardening follows. This is the sequence we follow in ESXi incidents:

1. Isolation of the management network and vCenter at the switch or firewall, keeping one path from an incident response workstation, without powering off or rebooting hosts, whose logs may live on a ramdisk.
2. Process list and network connections recorded on each host (esxcli system process list, esxcli network ip connection list) before any encryptor process is stopped, because isolation does not halt a process already running.
3. Running VMs left powered on, because powering off destroys guest memory, although many encryptors kill VM processes first. Where memory matters, a memory snapshot or a suspend writes .vmsn or .vmss and .vmem files, copied off the datastore at once.
4. Copy of /var/run/log from each host before the vm-support bundle, which runs commands on the host and writes to it, plus the vCenter support bundle. Each file is hashed with SHA-256 and entered in a chain-of-custody record.
5. A persistence review before rebuilding: /etc/rc.local.d/local.sh, root's crontab, new local accounts and VIBs that fail "esxcli software vib signature verify".
6. Encrypted datastores kept intact. CISA's ESXiArgs-Recover rebuilt machines from files the malware had not encrypted.
7. Hosts rebuilt from a verified image in an isolated environment, with root, vCenter and backup credentials rotated.

Legal clocks start in parallel: 72 hours to the Spanish data protection authority (AEPD) under the GDPR if personal data is affected, 24 hours for the NIS2 early warning where it applies, and notification to CCN-CERT for ENS systems. An incident response retainer agreed in advance shortens those first hours.

Sources and methodology: this guide draws on publications by Mandiant and Google Threat Intelligence, Broadcom documentation, the DISA STIG for vSphere 8 and CISA advisories. It also uses guide CCN-STIC 442 and reports by Microsoft, Huntress, CrowdStrike and QUIRSO, with the information available on 8 November 2026. Figures are cited with their source and date. References to VMware, Broadcom, Microsoft, Proxmox, Nutanix, Veeam and other vendors are descriptive, imply no flaw in their products beyond published advisories and are not a commercial recommendation.