Breaking the Virtual Barrier: From Web-Shell to Ransomware

Executive Summary

Recent VMware vulnerabilities (CVE-2025-22224, CVE-2025-22225, and CVE-2025-22226) have reintroduced a critical risk of virtual machine (VM) escapes. These flaws allow attackers to break out of a compromised VM and take control over the underlying hypervisor. In corporate environments, this could lead to a full ESXi and vCenter compromise, enabling adversaries to bypass security controls, move laterally across the network, and deploy ransomware at scale.

While VM escape vulnerabilities are not new(CVE-2024-22252, CVE-2024-22253, CVE-2024-22254, CVE-2024-22255, CVE-2023-28746, etc), they have rarely been observed in the wild–until now. The active exploitation of these new VMware vulnerabilities shatters the false sense of security that previously surrounded this attack vector.

This article explores a simulated attack scenario in which an adversary exploits VM escape vulnerabilities in an exposed VMware environment, ultimately taking control of the virtualization layer and deploying ransomware with minimal forensic footprint. We will also examine defender visibility, architectural security controls, and mitigation strategies to strengthen resilience against such attacks.

From Web Shell to vCenter Ransomware

In this scenario, an attacker compromises a corporate web server, escalates privileges and leverages VMware vulnerabilities to bypass network restrictions, gain vCenter access, and deploy ransomware.
While this scenario uses a web server as the initial point of compromise, any exposed VM can serve as an entry point. This includes mail servers, virtual desktop infrastructure (VDI) environments, remote assistance solutions, Linux-based security appliances such as switches, and firewalls (FW). The only requirement is that the attacker gains administrative access to a virtualized system within the environment.

Scenario Context – The Victim Environment

The victim in this scenario is a parcel delivery company providing parcel tracking services to customers. Their infrastructure is on-premises, built primarily on Windows and VMware virtualization, running a single large cluster for cost efficiency and high availability.

From a security standpoint, they:

• Apply monthly patches to all workstations and, in maintenance windows, to servers.
• Deploy EDR (Endpoint Detection and Response) solutions on all endpoints.
• Have a firewall at the perimeter.
• Utilize a SIEM for 24/7 monitoring of security events.

Their parcel tracking software is internally developed and integrated with their ERP system. To enforce segmentation, externally vulnerable servers are placed in a DMZ, with restricted connectivity to the internal network. The web server, which powers parcel tracking, resides in this DMZ, behind a FW and a Web Application Firewall (WAF) protection module.

Step 1: Initial Compromise – Web Shell on an Internet-Facing Web Server

The attacker begins by scanning the parcel company’s website for vulnerabilities. They identify an unprotected input field that allows file uploads and exploit it to deploy a web shell onto the system.

Alternatively, the attacker could:

• Find an exposed SSH/RDP service with leaked credentials.
• Exploit a known vulnerability in the web application.

Upon breaching the system, the attacker gains a web shell with administrator privileges on the web server, which is running as a VM inside the corporate DMZ (i.e., the parcel tracking service).
A common security misconfiguration on web servers is running the web service with root or administrator privileges simply to “make it work”, creating a major security risk. This oversight provides attackers with high privileges immediately upon exploitation, making lateral movement and escalation significantly easier.

Step 2: Escaping the Virtual Machine – Exploiting CVE-2025-22224

Now inside the web server VM, the attacker stealthily conducts reconnaissance on the environment utilizing living of the land techniques and discovers that he does not have direct network access to the internal environment. This limits the attacker’s ability to move laterally using conventional methods. The machine, on the other hand, is running on ESXi, which is still vulnerable to CVE-2025-22224.

To bypass these restrictions, the attacker exploits CVE-2025-22224 (VMCI Heap Overflow), allowing them to execute code directly on the ESXi host. By escaping the virtualized environment, the attacker circumvents traditional network security controls, pivoting directly from the compromised VM to the underlying ESXi hypervisor.

Furthermore, beyond the initial web shell, the attacker’s actions within the VM are not inherently malicious in nature. Since the attacker is primarily querying system information and interacting with the virtualization layer, an EDR solution may not detect or block these activities, allowing the attack to proceed undetected

Step 3: Moving Laterally and Extracting Credentials – Using ESXi Access

Now running code on the ESXi host, the attacker exploits CVE-2025-22225 to escalate privileges and gain kernel level access on the hypervisor. With full control over the ESXi host, they can now access and manipulate other VM’s running on the same host.

The attacker could stop here, as it is highly common for all ESXi hosts to be connected to all datastores. This means they could skip lateral movement entirely and proceed directly to Step 5 (ransomware deployment), encrypting VM’s across multiple hosts without the need for additional lateral movement.
However, let’s assume our attacker wants to ensure maximum impact and expand their access to avoid missing potential targets. They continue their attack, aiming for vCenter access and further privilege escalation.
To further advance the attack, the attacker exploits CVE-2025-22226 (HGFS Out-of-Bounds Read) to dump memory from other VMs on the host. This allows them to extract sensitive data directly from the hypervisor’s memory, potentially including:

• LSASS credentials from Windows VMs, which can be used for lateral movement.
• Other unencrypted secrets stored in memory, depending on the workloads running on the host.

By leveraging these vulnerabilities, the attacker avoids traditional network-based lateral movement techniques, making detection significantly more difficult. Instead of triggering network-based security tools, they operate entirely within the virtualization layer, extracting credentials and sensitive data without direct interaction with the VMs themselves. LSASS dumping is a known technique with detection baked in most EDR solutions; however, those detections only work when the attacker is inside the machine and will not prevent memory dump at the host level.

Step 4: Gaining Access to vCenter via SSH

At this stage, the attacker leverages the stolen credentials (extracted from LSASS or other sources such as saved password history, shared root credentials across ESXi hosts, or certificates used for passwordless authentication) to log into vCenter or additional ESXi hosts via SSH. By accessing vCenter directly from the ESXi subnet, they reduce the risk of detection, as this communication typically does not pass through external security controls.
If SSH access is restricted, the attacker may attempt to exploit known vulnerabilities in vCenter (if it is unpatched). Additionally, inter-subnet communication is often not closely monitored, and even when vCenter is segmented from ESXi hosts, firewall policies are frequently configured to allow unrestricted communication between them (“allow any” rules). This provides the attacker with a clear path to escalate their access within the virtualization environment with minimal risk of detection.

Step 5: Ransomware Deployment

With access to vCenter or direct control over ESXi hosts, the attacker executes the final stage of the attack: data exfiltration and ransomware deployment.

Their actions typically include:

• Exfiltrating sensitive information for extortion purposes before encryption.
• Encrypting VM disk files (VMDKs), rendering VM’s inoperable.
• Deleting backups stored in vSphere Datastores, if used, to prevent recovery.

By targeting the virtualization layer, the attacker maximizes impact while minimizing the likelihood of detection. Unlike traditional endpoint ransomware, which encrypts files on individual machines, this approach disrupts entire workloads at once, paralyzing business operations.

Defender’s Perspective: What Would Security Teams See?

Now that we understand the attack flow, let’s analyze what the security team would be able to detect – and whether they could react in time.

Step 1: Initial Compromise (SSH/RDP or Web Shell)

The attacker had two possible entry points in our scenario:

1. SSH/RDP Access – If the attacker gained access through stolen or leaked credentials, the EDR would not block anything, as this behavior is not inherently malicious. The monitoring team might log the event, but aside from the external origin that might raise suspicion for example if the source is from unapproved VPN or TOR, no clear malicious activity would be detected. In most cases, this would be classified as “white noise”, generating no alerts.
2. Web Shell Deployment – If the attacker deploys a known malicious web shell, both EDR and WAF solutions might detect and flag it. Moreover, if the monitoring team is collecting command execution logs, unusual activity within the w3wp.exe process (the web service) – such as executing whoami or other Living off the Land commands could serve as an early indicator and trigger an alert. However, a sophisticated attacker may use in-memory web shells, such as Ghost Web Shell (Weaver Ant), to evade detection. Additionally, creating a custom or obfuscated web shell-especially with AI-assisted tools-is trivially easy and can bypass signature-based detection. Unless the payload exhibits suspicious behavior, EDR solutions are unlikely to trigger an alert. Similarly, most WAF deployments relying on a deny-listing approach may block generic threats but could still allow custom or modified payloads that do not match predefined attack signatures.

A sophisticated attacker aiming to stay stealthy would also avoid using noisy tools or conducting aggressive post-exploitation actions until they had established a secondary, more persistent foothold inside the corporate environment.

Step 2: VM Escape – Exploiting VMware Vulnerabilities

At this stage, the attacker exploits VMware vulnerabilities to escape the compromised VM and execute code on the ESXi host.

• This bypasses network and identity security controls entirely, since the attacker is moving within the virtualization layer, not across the network.
• No security agents are deployed on ESXi hosts, meaning the exploitation would be completely undetected.
• Monitoring teams would have limited visibility into this step, and traditional perimeter or internal defenses would be powerless against this attack vector.

Steps 3-5: Lateral Movement and Impact Phases

At these stages, the attacker operates inside the infrastructure zone, where monitoring is significantly weaker:

• VMware logs are high-volume and not optimized for security monitoring, making it easy for attackers to blend in.
• ESXi hosts often share a single subnet, with no micro-segmentation, meaning traffic between hosts is rarely monitored or restricted.
• Even if detection is possible, false positives and misconfigurations are common, reducing alerting effectiveness.

As a result, security teams may only detect the attack at the final exploitation stage, when VMs are encrypted, data is exfiltrated, or services are disrupted – at which point, it’s already too late.

Summary

Despite having security controls and monitoring in place, the company remains at significant risk of compromise due to gaps in prevention and detection capabilities. This highlights the need for a different approach to security, focusing on defense-in-depth (layered security) and blast radius containment to limit the impact of a breach.

While there is no silver bullet to completely prevent such attacks, in the next section we will explore mitigation strategies designed to hinder attackers, slow their progress, and provide defenders with the time needed to detect and respond before the exploitation succeeds.

How to Secure a Virtualized Environment

When prevention and detection are difficult, a different security approach is required. Instead of relying solely on traditional defenses, organizations should adopt a blast radius strategy, ensuring that when a compromise occurs, the impact is contained and limited.

In this section, we provide two categories of recommendations:

• Tactical: These are immediate actions that enhance security without significant downtime. They focus on visibility, segregation, and rapid configuration improvements to harden the existing environment.
• Strategic: These require long-term planning and architectural changes, particularly in environments where downtime is difficult to schedule. This approach integrates security into the design of the virtualization environment, reducing risk and limiting attack impact (blast radius) by default.

For a deep dive into protecting virtualized environments, refer to our previous article: ESXi Ransomware Attacks: Evolution, Impact, and Defense Strategy

This article provides an in-depth look at ESXi ransomware threats and the mitigation strategies necessary to secure virtualized infrastructure.

Tactical Recommendations

Visibility

Detecting zero-day attacks is difficult but not impossible. The key lies in monitoring critical points for behavioral changes. While this is easier said than done, three fundamental principles must be followed:

1. Ensure complete visibility of the virtualized environment, focusing on ESXi and related components.
2. Reduce noise to focus on meaningful security signals.
3. Establish a tight behavioral baseline to detect deviations from normal activity.

1. Ensuring Critical Infrastructure is Monitored
To build effective visibility, all critical logs from ESXi hosts, vCenter, and storage systems must be collected and analyzed.

• ESXi Host Logs to Collect:
  • /var/log/auth.log – ESXi Shell authentication successes and failures.
  • /var/log/hostd.log – Logs for host management tasks, VM activity, vSphere Client/vCenter interactions, and SDK connections.
  • /var/log/shell.log – Records ESXi Shell activity, including command execution.
  • /var/log/syslog.log – Tracks system processes, scheduled tasks, and DCUI interactions.
  • More information can also be found here: ESXi Ransomware Attacks: Stealthy Persistence through SSH Tunneling.
• vCenter Logs to Collect:
  • vpxd.log – The main vCenter log, containing all vSphere Client/WebServices interactions, internal tasks, and communication with ESXi hosts.
  • stats.log – Logs historical performance data from ESXi hosts.
  • sms.log – Monitors the health of the Storage Monitoring Service (SMS) and its connectivity to vCenter.
• Storage Activity and Access Logs:
  • Monitor access logs, changes, and performance anomalies that could indicate malicious activity. Keep in mind that log formats will vary by storage vendor.

2. Reducing Noise in Virtualized Environments
To improve detection efficiency, it’s crucial to eliminate unnecessary access and streamline operations:

• Limit direct user access to ESXi hosts, managing interactions exclusively through vCenter whenever possible.
• Implement a privileged access management (PAM) solution or jump server to control administrative access.
• Automate routine administrative tasks to reduce reliance on click-ops (manual operations), which introduce security risks and excessive log noise.

3. Creating a Baseline for Detecting Zero-Day and Unknown Attacks
Signature-based detection alone is insufficient for catching zero-day threats. Instead, broad monitoring capabilities should be built by establishing a baseline of normal behavior, allowing anomalies to be flagged.

• Performance as an Anomaly Indicator:
  • Unexpected spikes or drops in resource usage can signal compromised systems or unauthorized operations.
  • Example: If file server traffic significantly increases every Monday due to project access patterns, an unexpected high load at unusual times may indicate malicious activity.
• Mapping Normal Log Sequences:
  • Many system logs follow predictable sequences, and deviations can indicate attacks.
  • Example: Normally, a user visits a login page, then an authentication log appears within seconds. If an authentication log appears without a corresponding login event, this is suspicious.
  • Once log sequences are mapped, detection rules can be created for deviations from expected behavior.
• Identifying Malicious Behavior Patterns:
  • While attack methods change, ransomware attacks share common attributes.
    • Mass file encryption, deletion, or permission modifications should be flagged as high-risk.
    • Altered or missing logs, particularly when they are not sent to the SIEM or have been deleted, may indicate tampering. If IT teams did not trigger the changes, an attack may be in progress.
• Deploying Canaries (Honeypots) in the Virtualized Environment:
  • Placing decoy files, VMs, or credentials in the environment can help detect unauthorized access attempts. Examples include:
    • Fake VM instances that are never used but monitored for activity.
    • Dummy password files placed in sensitive directories.
    • Hidden decoy files in various locations – if accessed, an alert is triggered.

While visibility is a crucial first step, it must be complemented by alerting mechanisms and regular threat-hunting activities. Periodic threat hunts help identify blind spots, detect anomalies missed by automated systems, and ensure comprehensive coverage of the environment by the monitoring team.

Hardening

Enhancing the security of a virtualized environment reduces the risk of exploitation. While no system is completely attack-proof, the goal is to hinder an attacker’s progress, increasing the chance of detection before significant damage occurs.

Rather than listing every possible hardening step, this section focuses on critical measures specifically relevant to this attack scenario:

1. Patch Critical Vulnerabilities Immediately

• While this exploit was initially a zero-day, it is now publicly known, and leaving the environment unpatched extends exposure unnecessarily.
• Critical patches should be applied as quickly as possible, preferably within 48 hours of disclosure to minimize risk.

2. Disable Unused Services

• SSH should be disabled on all ESXi hosts by default. It should only be enabled temporarily during scheduled maintenance windows when access is required.
• Any other unused services in the environment should be disabled to reduce the attack surface.

3. Enforce Strong and Regularly Rotated Passwords

• Use unique, complex, and long passwords for all ESXi hosts root accounts, and any other users in the hosts.
• Implement regular password rotation:
  • If an automated Privileged Identity Management (PIM) solution is available, rotate passwords daily, and upon each use.
  • If manual management is required, rotate passwords at least every 180 days.

4. Enforce Segmentation and Isolation
Restricting access and isolating workloads can limit an attacker’s ability to pivot within the environment.

• Dedicated ESXi Hosts Based on Functionality & Criticality:
  • If possible, allocate separate ESXi hosts for different security zones, such as:
    • DMZ servers
    • Application-specific workloads
    • Internal corporate systems
    • Critical infrastructure
  • The more segmentation, the better, as it minimizes the risk of cross-contamination.
• Restrict Datastore Access Based on ESXi Segmentation:
  • Create dedicated datastores for each segmented ESXi function (e.g., DMZ-only datastores, internal-only datastores).
  • Only connect each datastore to the ESXi hosts that require access, preventing an attacker from using one compromised ESXi host to infect multiple unrelated VMs.
• Strict Access Controls for ESXi Hosts:
  • ESXi hosts should not be accessed on a day-to-day basis.
  • Firewall policies should restrict access based on an allowlist approach (explicitly permitting only approved connections).
  • Access permissions should follow the same principle, ensuring only necessary personnel can interact with ESXi hosts.

5. Enable Lockdown Mode on ESXi Hosts

• ESXi Lockdown Mode should be enabled to limit direct access to the host and prevent attackers from jumping between ESXi hosts in the environment.

Strategic Recommendations

Strategic security measures must be implemented proactively, rather than as a reaction to emerging threats. These changes require planning, design, and sometimes infrastructure prerequisites before they can be effectively deployed.

In the case of VMware and the recent zero-day exploit, no immediate countermeasure could have prevented the attack once an adversary gained privileged access to a VM. However, through a strategic approach based on blast radius reduction, the company’s exposure could have been significantly limited.

When approaching blast radius reduction, organizations must first define their tolerance for operational impact. While a zero-tolerance security model may sound ideal, implementing it in practice is a complex challenge. The goal in this scenario is to restrict the attacker’s ability to deploy ransomware across the entire virtualized environment. While full prevention may not be feasible, effective segmentation and isolation buy defenders the most valuable resource in any active attack: Time.

To achieve this, security teams must analyze the layers of potential compromise and determine how far an attack can progress through the environment with minimal or no detection. In this case, we focus on an attacker reaching ESXi with kernel-level privileges and what can be done to contain the damage.

Comprehensive Segmentation Approach

• Risk-Based Segmentation
  Segment the entire virtualization environment – including storage, vCenter, and ESXi hosts – into three risk tiers:
  • High-risk: Servers exposed to the internet, externally accessible services, and any system with bi-directional communication with external sources (e.g., web servers, VPN gateways, mail servers).
  • Medium-risk: Internal servers used by employees, with limited internet access, but not directly exposed to external users (e.g., file servers, collaboration tools, internal applications).
  • Low-risk: Servers that do not require any internet access (except for controlled patching) and are accessed only by a small number of authorized users (e.g., backup servers, database servers, business-critical workloads).

• Criticality-Based Segmentation (Within Risk Tiers)
  After classifying servers by risk exposure, further segmentation should be applied based on criticality:
  • High-criticality assets: Systems whose compromise would be catastrophic (e.g., Active Directory, vCenter, Certificate management system, identity management systems). These should not be placed in high-risk tiers but instead isolated within low/medium-risk tiers with strict access controls.
  • Medium-criticality assets: Important systems that could impact operations if compromised (e.g., application servers, ERP systems, finance databases).
  • Low-criticality assets: Systems with minimal business impact if breached, such as static company portals or general-purpose test servers.

Moderate Segmentation Approach

If full segmentation is not practical, a moderate approach can still provide substantial risk reduction:

• Separate the virtualization environment into two distinct vCenter instances:
  • One for externally exposed environments (DMZ).
  • One for internal corporate infrastructure.
• Inside each vCenter instance, further separate ESXi hosts into clusters based on function and risk level.

Potential Risks of the Moderate Approach

• Single Point of Failure:
  • If internal vCenter is compromised, it may provide an attacker access to critical internal servers such as Active Directory.
• Incomplete Segmentation:
  • Even though internal and external servers are separated, an attacker gaining control of one vCenter can still impact all associated ESXi hosts.

Regardless of which approach is chosen, segmentation must apply across all components – ESXi hosts, vCenter instances, and storage (datastores). The more logical separation that exists, the more contained any incident will be.

Network Segmentation & Isolation
Beyond virtualization-layer segmentation, network segmentation is essential to restrict attacker movement.

• Each ESXi hosts cluster should be assigned to a dedicated network segment, following the segmentation design above.
  • Example: ESXi hosts supporting DMZ servers should be isolated in a separate subnet from those handling internal workloads.
• Strict firewall rules should limit inter-segment communication, using a deny-by-default model.
  • Example: Only vCenter should be allowed to communicate with ESXi hosts, and all unnecessary ESXi-to-ESXi communication should be blocked.

By implementing both virtualization and network segmentation, organizations can contain an attack within a specific subset of the environment, making full environment compromise significantly more difficult.

Conclusion: The New Reality of Virtualized Attacks

Hypervisor escape vulnerabilities are no longer theoretical – they are an active and evolving threat. Attackers can and will exploit unpatched VMware environments to gain complete control over virtualized infrastructure.

To defend against this new reality, organizations must rethink their approach to virtualization security.

• Assume that VMs will be compromised – design infrastructure to limit lateral movement and contain threats before they spread.
• Patch immediately – leaving VMware environments unpatched is like leaving your data center doors unlocked for attackers to walk through.
• Monitor for hypervisor abuse – because once an attacker gains control over vCenter, it’s game over for the entire virtualized environment.

The next wave of cyber threats is already here. The best defense is preparation, visibility, and strategic security architecture.

Final Thought

These types of vulnerabilities remind us once again that it is never a question of if but when an attack will occur. Therefore, we must design our environment to prevent a single point of compromise from jeopardizing the entire system. Just as cars have braces designed to shield passengers from impact, our environment should be built with a blast radius design to limit the spread of damage.