Hypervisor and Virtualisation Security Guide: Protecting the Virtualisation Layer

Whoever controls the hypervisor controls every virtual machine on it, yet the virtualisation layer is usually the least monitored and least hardened tier in the data centre. Ransomware operators now encrypt datastores directly from the host, espionage groups plant implants in hypervisors and appliances where endpoint agents cannot run, and guest-to-host escape flaws have been exploited in the wild. This guide covers the virtualisation layer in a vendor-neutral way: how hypervisors isolate workloads, where they fail, how to secure the management plane, VM images, snapshots and virtual networks, and how to detect abuse. It is written for infrastructure, platform and security engineers running VMware vSphere, Microsoft Hyper-V, KVM-based platforms or private clouds. Product-specific settings for vSphere are in the companion VMware ESXi Hardening Guide.

Key takeaways

• Treat the virtualisation layer as Tier 0. Hypervisor hosts, their management servers and the identities that administer them deserve the same protection as domain controllers, because they can power off, copy or encrypt every workload, including the domain controllers themselves.
• Isolation is the product, and it can fail. NIST SP 800-125A Rev. 1 frames the hypervisor's job as process isolation, device mediation and lifecycle management; the 2025 VMware escape chain (CVE-2025-22224, CVE-2025-22225, CVE-2025-22226) shows a guest administrator can break that boundary when hosts are not patched.
• Separate infrastructure identity from the corporate directory. Attacks such as the ESXi "ESX Admins" flaw (CVE-2024-37085) and help desk social engineering turn a directory compromise into hypervisor control in hours.
• Management interfaces belong on an isolated network. Dedicated management NICs or VLANs, reachable only from privileged access workstations, remove the exposure that let mass ransomware campaigns hit internet-facing hosts.
• Log at the host, ship off the host. Endpoint agents rarely run on bare-metal hypervisors, so remote syslog, audit records and management-server events are often the only evidence; keep them long enough to cover dwell times measured in months.

How the virtualisation layer works and why it is a target

NIST SP 800-125A Rev. 1 defines five baseline hypervisor functions. Each is a security boundary, and each maps to a different class of attack:

• Type 1 versus Type 2: a Type 1 (bare-metal) hypervisor such as ESXi, Hyper-V or KVM in a server distribution runs directly on hardware; a Type 2 hypervisor runs on a full host operating system, which adds the host OS to the attack surface. NIST SP 800-125A scopes its recommendations to server virtualisation, not desktops.
• Why attackers go there: one action at the host affects hundreds of workloads. Microsoft reported that its incident response engagements involving ESXi targeting and impact more than doubled in three years, and named ESXi encryptors sold or used by Akira, Black Basta, Babuk, LockBit and Kuiper operators.
• Two threat profiles: financially motivated groups want speed (power off VMs, encrypt datastores, delete backups). Espionage groups want persistence: Broadcom's BRICKSTORM resource describes PRC state-sponsored actors (tracked by Mandiant as UNC5221 and UNC6201) placing a backdoor and a hypervisor implant in vSphere environments, with average dwell time of over a year.

Attack paths against hypervisors

The table maps the common paths to MITRE ATT&CK v20 techniques and the control that breaks each one.

Escape flaws matter because they collapse tenant isolation. Broadcom's VMSA-2025-0004 (4 March 2025) describes CVE-2025-22224, a VMCI time-of-check time-of-use flaw rated CVSS 9.3 that lets a local administrator in a VM execute code as the VM's VMX process on the host; CVE-2025-22225, an arbitrary kernel write that escapes the VMX sandbox; and CVE-2025-22226, an HGFS memory leak. Broadcom reported exploitation in the wild, listed no workarounds, and CISA added all three to the Known Exploited Vulnerabilities catalogue on 4 March 2025.

Securing the management plane

Most hypervisor compromises start with management access, not exotic exploits. NIST SP 800-125A Rev. 1 recommends central administration of all hypervisors through an enterprise virtualisation management system (HY-SR-19), granular object-level VM permissions (HY-SR-18) and a dedicated management NIC, or failing that a dedicated VLAN behind firewall controls (HY-SR-20).

• Network isolation: put host management interfaces, management servers (vCenter, System Center Virtual Machine Manager, KVM managers), hardware management controllers (iDRAC, iLO, IPMI) and storage management on dedicated segments reachable only from jump hosts or privileged access workstations. Never publish them to the internet. See the Network Segmentation Guide.
• Manage through the management server, not the host: direct host logins bypass role-based access control and central audit. Use host lockdown features (vSphere lockdown mode) and keep local break-glass credentials in a vault.
• Least privilege on VM objects: custom roles for operators, backup, monitoring and automation; no shared administrator account; deny rules for sensitive VMs such as domain controllers and PKI servers.
• Minimal host OS: for Hyper-V, Microsoft recommends the minimum Windows Server installation needed, the Windows Server security baseline, no workstation use or unrelated software on the host, and remote management; where local management is required, Credential Guard.
• Restrict who administers the host: Microsoft advises adding host managers to the Hyper-V Administrators group and not granting VM administrators any permissions on the host OS.
• Treat integrations as administrators: backup software, monitoring, orchestration and capacity tools hold credentials that can change the environment. Broadcom's ransomware resilience paper warns that any system with rights to change the virtual environment is an administration method and must be protected accordingly.

Where identity fits

The hypervisor tier is full of non-human identities, and many attacks pivot through them:

• Directory-joined hosts: CVE-2024-37085 let anyone able to create an AD group named "ESX Admins" gain full administrator rights on domain-joined ESXi hosts, because membership was matched by name, not security identifier. Microsoft observed Storm-0506, Storm-1175, Octo Tempest and Manatee Tempest using it before Akira and Black Basta deployments. Broadcom recommends isolating infrastructure authentication from the general-purpose directory, or using local SSO groups for authorisation.
• Service accounts: management servers use per-host machine accounts (vCenter's vpxuser, rotated every 30 days by default), backup products hold hypervisor-wide API rights, and monitoring tools often run as read-write administrators. Inventory them, scope them, rotate them and alert on interactive use. See the Service Account Security Guide.
• Help desk and password resets: Google Threat Intelligence Group reported in July 2025 that Scattered Spider called help desks to reset administrator passwords, then took over vCenter, enabled SSH on hosts and encrypted VMs, all within hours. See the Privileged Access Management Guide.

VM lifecycle: images, snapshots, migration and nested virtualisation

Broadcom's BRICKSTORM audit reference describes the "disk swap" pattern: attackers create a staging VM, attach a domain controller's virtual disk to it, extract credentials, then delete the VM. Watching for vm.storage.add, vm.create and vm.delete events against Tier 0 disks is one of the highest-value detections in any virtualised estate.

Host integrity, isolation hardening and confidential workloads

• Measured and secure boot: NIST HY-SR-1 calls for launching the hypervisor on hardware with measured launch and an attestation chain. Use UEFI Secure Boot and TPM 2.0 on every host, and attest host state centrally (vSphere host attestation, Hyper-V Host Guardian Service). See the Firmware and Boot Security Guide.
• Hardware-assisted isolation: use CPU virtualisation extensions and IOMMU DMA remapping, which NIST requires for passthrough and self-virtualising devices (HY-SR-2, HY-SR-6C).
• Allow only signed code on the host: on ESXi, signed installation bundles and the execInstalledOnly option block attacker toolkits; on Hyper-V, Microsoft recommends virtualisation-based security protected code integrity policies.
• Reduce virtual devices: remove unused USB controllers, serial ports, CD drives, shared folders and 3D features. Every emulated device is code reachable from the guest (HY-SR-6A).
• Contain denial of service: per-VM CPU, memory, network and I/O limits and reservations stop a noisy or hostile VM from starving neighbours (HY-SR-3 to HY-SR-5, HY-SR-8). Avoid memory over-commit on hosts running sensitive workloads.
• Protect workloads from the fabric itself: Hyper-V shielded VMs run only on attested guarded hosts, with BitLocker disks sealed to a virtual TPM, and block console, PowerShell Direct and debugger access, so they are protected from malicious fabric administrators and host malware. Microsoft recommends TPM-trusted attestation; admin-trusted attestation is deprecated from Windows Server 2019. For hardware-based protection in cloud and private cloud, see the Confidential Computing Guide.

Virtual networking

NIST SP 800-125B covers four areas of virtual network configuration: segmentation, redundant paths, firewall control of VM traffic, and traffic monitoring. Practical controls:

• Segment by trust, not by convenience: separate management, live migration, storage (iSCSI, NFS) and workload traffic onto different VLANs or physical NICs, and make sure only management interfaces carry management services.
• Reject layer 2 tricks: keep promiscuous mode, MAC address changes and forged transmits rejected on virtual switches unless a documented workload needs them.
• Distributed firewalling: enforce east-west policy at the virtual NIC so a compromised VM cannot scan the estate. See the Firewall Management Guide.
• Monitor from outside the guest: NIST HY-SR-14 and HY-SR-15 recommend monitoring VM state and traffic, ideally through introspection from outside the guest, because an attacker in the guest controls what in-guest tools see.

Choosing an approach

Small organisations with two or three hosts should focus on patch currency, an isolated management VLAN, disabled SSH, remote logging and an offline backup copy. Large estates need declarative configuration management with drift alerts, a dedicated infrastructure identity domain, posture monitoring for the hypervisor layer and detection content written for hypervisor logs.

Implementation roadmap

1. Inventory (weeks 1 to 2): list every host, management server, hardware controller, version and support status; flag anything past end of general support or exposed beyond the management network.
2. Patch exposure (immediately): apply fixes for any hypervisor or management server CVE in the CISA KEV catalogue as an emergency change. Patch the management server before hosts, and use live migration so patching does not need downtime.
3. Isolate management (weeks 2 to 6): move management interfaces to dedicated segments, restrict access to jump hosts or privileged access workstations, and test with a pilot cluster first. Roll back by restoring the previous firewall rule set, which should be exported before each change.
4. Separate identity (weeks 4 to 10): move hypervisor administration to a separate identity source or local groups, enforce MFA on the management server, remove standing administrator rights from directory groups and vault break-glass accounts.
5. Harden hosts (weeks 6 to 12): apply the vendor baseline (Broadcom Security Configuration and Hardening Guide, Windows Server security baseline) first in audit mode using the vendor's assessment scripts, then remediate one cluster at a time. Keep a record of each changed value so it can be reverted.
6. Log and detect (weeks 6 to 12): forward host audit logs and management events to the SIEM over TLS, build the detections below, and test them with a controlled exercise.
7. Protect recovery (ongoing): isolate backup infrastructure identity, keep immutable or offline copies, and rehearse an "everything down" restore, including the management server.

Detection and measurement

Endpoint agents rarely run on bare-metal hypervisors, so detection depends on host logs and management-server events. Forward them off the host, and keep them long enough: Broadcom's BRICKSTORM guidance recommends two or more years of retention because average dwell time exceeded a year.

• Service changes: SSH or shell enabled on a host or management appliance, especially outside a change window.
• Logging and firewall changes: syslog target changed or removed, audit forwarding disabled, host firewall rules opened (T1685, T1686).
• Mass VM operations: many VMs powered off within minutes, snapshot deletion, datastore file renames.
• Tier 0 disk access: a domain controller or vault disk attached to any other VM, or a clone of a Tier 0 VM.
• Privilege changes: new administrator role assignments, creation of directory groups used for hypervisor authorisation, root password changes.

Metrics that show the programme is working:

• Percentage of hosts and management servers on a supported, fully patched build, and median days from vendor advisory to patched for KEV-listed hypervisor CVEs.
• Percentage of hosts with SSH and shell disabled and lockdown enabled, measured by automated audit.
• Percentage of hosts forwarding audit logs to the SIEM, and retention in days.
• Number of standing directory accounts with hypervisor administrator rights (target: trending to zero).
• Time to restore a representative cluster and its management server from isolated backup in the last exercise.

See the Detection Engineering Guide.

Common failure patterns

• Management interfaces reachable from the internet or user networks: Broadcom's ESXiArgs guidance in February 2023 said the primary impact was on unpatched hosts where attackers had direct access to management interfaces.
• Hypervisor admin rights inherited from the corporate directory: one directory compromise, or one convincing help desk call, becomes control of every VM. In the MGM Resorts breach, attackers who began with a help desk call claimed to have encrypted more than 100 ESXi hypervisors; MGM has not confirmed that figure.
• Running hypervisors past end of support: Broadcom's ESXiArgs answers note vSphere 6.x no longer receives updates, so known flaws stay open permanently.
• Backups that share an identity domain with production: attackers with directory rights delete jobs, snapshots and repositories before encrypting.
• No host logs off the box: in-memory or local-only logs disappear on reboot or are wiped by the attacker, leaving no timeline.
• Treating patching as a quarterly change: exploited escape flaws such as VMSA-2025-0004 have no workaround, so the patch window is the exposure window.

Framework mapping

In CIS Controls v8.1 the topic sits mainly under Control 4 (Secure Configuration), Control 7 (Continuous Vulnerability Management), Control 8 (Audit Log Management) and Control 12 (Network Infrastructure Management); in ISO/IEC 27001:2022 Annex A under 8.9 Configuration management, 8.8 Management of technical vulnerabilities, 8.15 Logging and 8.22 Segregation of networks. See the MITRE D3FEND Guide.

Practitioner checklist

• Classify hypervisor hosts, management servers and hardware controllers as Tier 0 assets.
• Patch every KEV-listed hypervisor and management server CVE as an emergency change; retire unsupported versions.
• Move all management interfaces to isolated segments reachable only from privileged access workstations.
• Administer through the management server with role-based access; enable host lockdown and vault local credentials.
• Remove hypervisor administrator rights from general directory groups and enforce MFA on the management server.
• Enable Secure Boot, TPM attestation and signed-code-only execution on hosts.
• Encrypt live migration and Tier 0 VMs; restrict snapshot, clone and disk attach privileges.
• Forward host audit and management logs to the SIEM over TLS and retain them for at least two years.
• Alert on SSH enablement, logging changes, mass power-off and Tier 0 disk attachment.
• Isolate backup identity and keep immutable copies; rehearse a full management-plane restore.

Standards and references

• NIST: SP 800-125A Rev. 1, Security Recommendations for Server-based Hypervisor Platforms
• NIST: SP 800-125B, Secure Virtual Network Configuration for Virtual Machine (VM) Protection
• Microsoft: Plan for Hyper-V security in Windows Server
• Microsoft: Guarded fabric and shielded VMs overview
• Broadcom: Practical Ideas for Ransomware Resilience with VMware vSphere
• Broadcom: VMSA-2025-0004, VMware ESXi, Workstation and Fusion updates
• Microsoft Security: Ransomware operators exploit ESXi hypervisor vulnerability for mass encryption
• MITRE ATT&CK: Hypervisor CLI

Related NHI Mgmt Group resources: VMware ESXi Hardening Guide · Ransomware Prevention Guide · Endpoint Security Guide · Backup Security and Immutable Backup Guide · Container Security Guide