ESX hardening guides have been the foundation of hypervisor security programs for a long time. Disable unnecessary services. Lock down management access. Enforce strong authentication. Patch early and often. These practices are table stakes, and in many environments they are done well. Even so, organizations that follow them are still getting hit.
The hypervisor itself has not changed much in the past few years. Attackers have. Many threat actors are not breaking into ESX through exotic zero-days. They are logging in after gaining a foothold in the network somewhere else. Mandiant’s 2025 reporting on UNC3944 shows a consistent pattern of social engineering and credential theft used to access vCenter and ESX directly, often without exploiting a single vulnerability. That shift exposes a gap that hardening was never designed to solve.
You can have a perfectly configured system and still lose it the moment someone authenticates with the right credentials.
The scale of the shift is real. Huntress reports that hypervisor ransomware grew from three percent of malicious encryption cases in the first half of 2025 to twenty-five percent in the second half. The Register summarized that as roughly a 700 percent increase, and named Akira as the primary group driving it.
The Frameworks Defenders Are Working From
Most ESX security programs are not built from scratch. They are built against published frameworks. These four frameworks and capabilities are popular today:
- VMware’s vcf-security-and-compliance-guidelines repository on GitHub. The source-of-truth hardening guidance maintained by Broadcom staff and used to seed the other frameworks. It covers the configuration baseline for vSphere, NSX, and the broader VCF stack.
- DISA STIG for VMware vSphere. The federal baseline. The v2r1 ESX STIG carries roughly 54 controls focused on configuration: SNMP versions, firewall defaults, secure boot, password aging, SSH port forwarding, certificate validation, and so on. Derived from NIST 800-53.
- CIS Benchmarks for VMware ESX. The community consensus baseline. Hardware firmware integrity, secure boot, image profile acceptance level, NTP, lifecycle patching, and dozens of other configuration items, organized into Level 1 and Level 2 profiles.
- VMware Advanced Cyber Compliance (ACC). VCF 9.x add-on, generally available since November 2025. Built on Salt. Defines desired-state policies for ESX hosts, continuously monitors for drift, and remediates. Maps to PCI DSS and VCF security baselines, with audit trails surfaced in VCF Operations.
If you stack them, what you have is the most mature configuration-compliance picture the hypervisor has ever had. ACC in particular changes compliance from a once-a-year audit exercise into something that runs continuously. That is real progress and worth taking seriously.
It is also worth being honest about what these frameworks measure.
What They All Measure, and What They Do Not
Every one of these frameworks is a configuration baseline. They answer one question: is the host set up the way it is supposed to be? The controls are state checks. Is SSH disabled? Is Secure Boot enforced? Is execInstalledOnly true? Is the firewall default deny? Are SNMP v1 and v2c off? Is the image profile acceptance level set correctly? Are unused services stopped?
These are the right questions to ask, and asking them continuously, the way ACC does, is better than asking them once a year. None of them answer a different question that turns out to matter more in a modern intrusion: once a legitimate identity is inside the system, what is that identity allowed to do?
The frameworks do not have a concept of intent. A correctly configured ESX host with Secure Boot enforced, default-deny firewall, disabled SSH, current patches, and a fully compliant ACC desired-state policy will happily let a root user run openssl against a VMDK. None of those controls were designed to stop it. They were designed to make sure the host is not misconfigured in a way that lets an unauthenticated attacker get in. Once the attacker is authenticated, the frameworks have nothing left to say.
The Modern ESX Attack Looks Like Administration
Mandiant’s reporting on UNC3944 is the clearest public example. The group does not rely on exploits. They social-engineer help desks, pivot through Active Directory or other control surfaces, and walk into vSphere using legitimate credentials. The environment passes every hardening standard. The attacker is already inside.
Once they are in, they do not need malware. Huntress has documented attackers using native utilities like openssl to encrypt VM volumes directly from the ESX shell, bypassing every assumption a defender might make about antivirus or EDR signatures. The technique works because openssl is supposed to be there. Hardening cannot disable it without breaking operations.
Network controls have the same problem. Firewalls and segmentation reduce exposure, but once an attacker has valid credentials they are managing infrastructure, not snooping around it. From the network’s perspective, the traffic is expected and allowed.
Logging is usually where defenders try to close the gap. It does not close. Logs show what happened; they do not stop it from happening. In hypervisor attacks, the window between access and impact is short. Once the attacker reaches the ESX host they begin disabling protections, modifying configurations, and encrypting almost immediately. The log-and-alert model is impractical in real environments where monitoring coverage or staffing is limited. By the time an alert is acted on, the attacker has usually reached their objective.
There is also an architectural issue underneath all of this. ESX does not support traditional endpoint security tooling. You cannot install a standard EDR agent on the hypervisor. That means many of the behavioral controls that exist on a Windows or Linux endpoint simply do not exist at this layer.
Where Advanced Cyber Compliance Fits, and Where It Stops
ACC is worth singling out because it is the newest and the most powerful of the four. It is also the framework most likely to be confused with what we are describing. ACC enforces. It does not just observe. If a configuration drifts, it remediates. That is genuinely useful and it raises the floor on hypervisor security.
It enforces against configuration state. If an administrator disables Secure Boot, ACC will catch the drift and put it back. If an attacker with root credentials runs openssl against a VMDK, ACC has no policy that applies. The encryption is not a configuration change. It is an action taken by an authenticated identity using a tool that the system is supposed to allow.
This is the line. Continuous configuration compliance is one discipline. Continuous behavioral enforcement is another. The frameworks above cover the first one well. None of them cover the second.
And When the Attacker Does Use an Exploit
Even patching, the most basic compliance discipline, runs into a wall on the hypervisor. CISA added CVE-2025-22224, CVE-2025-22225, and CVE-2025-22226 to its Known Exploited Vulnerabilities catalog the same day Broadcom disclosed them, because all three were already being exploited in the wild as zero-days. CVE-2025-22225 has since been flagged as used in active ransomware campaigns. In 2025 there was a roughly two-month gap between the Pwn2Own disclosure of CVE-2025-41236 and a shipping patch.
During those windows, a fully compliant host is still vulnerable. Configuration baselines do not protect against vulnerabilities that have no patch yet. Behavioral enforcement, because it does not depend on knowing about a specific CVE, applies during those windows too.
What ZeroLock Adds
ZeroLock is built around the second discipline. Instead of asking whether the host is configured correctly, it asks whether each action on the host should be allowed to complete. That evaluation happens continuously, inside already-authenticated sessions, including sessions running as root.
A fully authenticated user logged in as root on a ZeroLock-protected ESX host will still not be permitted to run a ransomware workflow, encrypt VM disk files with openssl, kill VM processes in bulk, or take other protected actions. The user’s credentials are not the deciding factor. The behavior is.
ZeroLock does not try to eliminate tools like openssl, esxcli, or vim-cmd. Those tools are needed for legitimate administration. It constrains how they can be used. Administrative functionality remains available for operators. Workflows that resemble destructive or anomalous sequences are blocked before they complete. This also compensates for the lack of traditional endpoint protection on the hypervisor. The policy is enforced directly at the hypervisor layer instead of relying on protections inside guest VMs.
In a traditionally hardened environment, the actions described above are logged, alerted on, and handled by an analyst if there is time. In a ZeroLock-enforced environment, the same actions are evaluated and blocked in real time. Logging keeps its value for investigation and audit. It is no longer the first line of defense.
How to Think About the Layers
None of this is an argument against the frameworks. They do what they were built to do. The point is that they were built to do one thing, and the modern ESX intrusion lives outside of it.
A useful way to think about the stack:
- VMware’s GitHub guidance, DISA STIG, and CIS Benchmarks define the configuration baseline. They tell you what a hardened host looks like.
- Advanced Cyber Compliance keeps the host on that baseline continuously and remediates drift.
- ZeroLock enforces behavior on the baselined host, stopping authenticated identities from completing destructive actions even when every configuration check is green.
These layers do not compete. They compose. A program that runs all three is not over-engineered. It is the realistic answer to attackers who have decided that credentials, not exploits, are the easiest way into the hypervisor.
The Bottom Line
Hardening reduces the attack surface. Continuous compliance keeps it reduced. Neither one stops a credentialed attacker from running openssl against your VMDKs. That is a different problem, and it needs a different control.
If you want to see what behavioral enforcement at the hypervisor looks like in practice, including against the exact native-tooling techniques documented in recent UNC3944 and Huntress reports, reach out to the team at Vali Cyber. [email protected].