Clearance Incident Response. Free through May 1, 2027, so you have time to patch.Estimate your Blast Radius in 60 secondsEstimate

aviatrix logoAviatrix
Under Active Attack

Executive Summary

In early 2025, Kaspersky's Global Emergency Response Team investigated a ten-day ransomware campaign attributed to BlackNevas, a Trigona-derivative group first observed in November 2024. The attackers compromised a vCenter Server Appliance via stolen enterprise credentials, deployed MeshAgent and a Ligolo-ng reverse tunnel for persistence, then weaponized VMware Host Profiles to silently re-enable SSH across all ESXi hosts. No hypervisor vulnerabilities were exploited. The adversaries destroyed backup infrastructure before detonating a Babuk-derived ESXi encryptor that wiped four ESXi hosts, all hosted virtual machines, and both vCenter appliances, rendering the entire virtualized estate unrecoverable within hours.

This incident illustrates a maturing ransomware playbook in which attackers bypass endpoint controls entirely by targeting the virtualization management plane. With the Babuk ESXi source code publicly available since 2021 and at least ten derivative families now in circulation, hypervisor-layer ransomware is accessible to low-sophistication actors, making every organization running VMware vSphere a viable target regardless of guest-level security posture.

Why This Matters Now

Ransomware groups are systematically shifting focus to the hypervisor layer because a single vCenter compromise can encrypt or destroy hundreds of virtual machines in minutes while remaining invisible to guest EDR agents. With Babuk ESXi source code freely available, barrier to entry is near zero, CISA has flagged multiple related CVEs as actively exploited, and Kaspersky data shows ransomware still accounted for nearly 40% of IR engagements entering 2026, making hypervisor-plane defenses an immediate board-level priority.

Attack Path Analysis

Related CVEs

MITRE ATT&CK® Techniques

Potential Compliance Exposure

Sector Implications

Sources

Frequently Asked Questions

The attackers used stolen enterprise credentials to authenticate to vCenter as root via SSH, then abused VMware Host Profiles—a legitimate compliance mechanism—to remotely enable SSH on all ESXi hosts, requiring no vulnerability exploitation whatsoever.

Cloud Native Security Fabric Mitigations and ControlsCNSF

Based on the attack progression modeled above, these are the defensive controls that would constrain each stage.

Aviatrix Zero Trust CNSF is directly relevant to this incident because the attacker's entire progression depended on unrestricted reachability across infrastructure tiers — from external VPS endpoints into vCenter, and from vCenter outward to ESXi hosts and attacker-controlled C2 infrastructure. Identity-aware segmentation and controlled egress enforcement would likely have reduced the attacker's reachable blast radius at multiple stages before ransomware detonation.

Initial Compromise

Control: Cloud Native Security Fabric (CNSF)

Mitigation: Network-layer policy enforced by CNSF would likely have constrained direct SSH reachability from untrusted external sources to vCenter management interfaces, reducing the attacker's ability to establish an initial foothold using stolen credentials alone.

Privilege Escalation

Control: Zero Trust Segmentation

Mitigation: Zero Trust Segmentation enforcing least-privilege, identity-scoped policy between management-plane components would likely have constrained which accounts and sessions could modify Host Profiles or push configuration changes to ESXi hosts, reducing the scope of privilege expansion achievable from a single compromised credential.

Lateral Movement

Control: East-West Traffic Security

Mitigation: East-West Traffic Security monitoring workload-to-workload flows within the management plane would likely have flagged or constrained the SSH pivot from vCenter to ESXi hosts, reducing the attacker's ability to move freely across hypervisor boundaries under the cover of trusted management traffic.

Command & Control

Control: Multicloud Visibility & Control

Mitigation: Multicloud Visibility and Control providing traffic observability and behavioral baselining on outbound management-plane connections would likely have surfaced anomalous outbound sessions from the vCenter appliance, reducing the attacker's ability to maintain covert C2 channels without detection.

Exfiltration

Control: Egress Security & Policy Enforcement

Mitigation: Egress Security and Policy Enforcement with FQDN filtering and outbound traffic controls would likely have constrained the covert egress paths available to the attacker, reducing the viability of using the Ligolo-ng tunnel or MeshAgent channel as exfiltration conduits even if credential data or VM artifacts were targeted.

Impact (Mitigations)

Had prior CNSF controls constrained lateral movement between vCenter and ESXi hosts and limited the attacker's ability to reach backup infrastructure, the detonation would likely have faced a narrower target scope — reducing the number of reachable ESXi hosts and potentially preserving at least a portion of backup recovery capability that the attacker would not have been able to reach and destroy.

Impact at a Glance

Affected Business Functions

  • Virtualization Infrastructure and Hypervisor Management
  • Backup and Disaster Recovery Operations
  • Virtual Machine Hosted Application and Database Services
  • IT Operations and Infrastructure Administration
Operational Disruption

Estimated downtime: 21 days

Financial Impact

Estimated loss: N/A

Data Exposure

The incident resulted in the total destruction of four ESXi hypervisor hosts and all virtual machines hosted on them, both vCenter Server Appliances, and all connected backup infrastructure over a ten-day dwell period. Virtual machine disk files (VMDKs) were partially overwritten, rendering guest operating systems unbootable. Backup repositories and recovery infrastructure were encrypted and disabled prior to the ESXi detonation phase, eliminating conventional recovery paths. Data categories at risk include all workloads co-hosted on the virtualized estate such as domain controllers, application servers, databases, and backup catalog data. Credentials extracted from backup infrastructure also exposed identity material spanning the broader enterprise environment. No specific record counts or regulated data categories such as PII or PHI are confirmed in the source reporting, but the total destruction of a virtualization estate hosting enterprise-critical workloads implies potential exposure or permanent loss of proprietary business data, operational databases, and configuration state across the entire virtual environment.

Recommended Actions

  • •

    Enforce Zero Trust Segmentation on the virtualization management plane: Apply identity-based microsegmentation to strictly control which accounts, source hosts, and network segments can reach vCenter and ESXi management interfaces. Treat vCenter as a Tier 0 asset with dedicated administrative identities isolated from ordinary enterprise credentials, eliminating the credential reuse path that enabled initial compromise and lateral movement in this incident.

  • •

    Deploy East-West Traffic Security with behavioral baselining for management-to-hypervisor flows: Establish and continuously monitor baselines for vCenter-to-ESXi connection patterns, ports, and protocols. Alert on SSH sessions from vCenter to ESXi hosts outside approved change windows, particularly when preceded by Host Profile remediation changes to TSM or TSM-SSH state, as this sequence represents a high-confidence pre-impact signal.

  • •

    Implement Egress Security and Policy Enforcement with FQDN filtering on management-plane outbound traffic: The Ligolo-ng C2 tunnel to api.cloudvflare[.]com:443 and MeshAgent beaconing to external infrastructure represent unauthorized outbound flows that FQDN-based egress filtering and outbound policy enforcement would have detected and blocked, disrupting C2 persistence before the destructive phase.

  • •

    Activate Multicloud Visibility and Control for centralized management-plane telemetry and anomaly detection: Collect and correlate ESXi auth.log, shell.log, vpxa.log, vobd.log, and vCenter Events/Tasks in a centralized platform outside the virtualization trust domain. Build detection logic for the Host Profile abuse sequence — remediation enabling TSM-SSH followed within minutes by a new SSH session from vCenter — as this combination provides a critical and high-fidelity detection opportunity that individual alerts on SSH alone would miss.

  • •

    Apply Inline IPS signature coverage and Cloud Firewall egress controls for pre-detonation payload detection: The ESXi encryptor was staged via SFTP, validated with a self-test, and detonated hours later — creating a detectable pre-impact window. Inline IPS controls inspecting management-segment traffic for known ransomware payload signatures, combined with Cloud Firewall enforcement blocking unauthorized executable staging and outbound connections to unknown destinations, would have provided layered opportunities to detect and interrupt the attack before destructive execution began.

Secure the Paths Between Cloud Workloads

A cloud-native security fabric that enforces Zero Trust across workload communication—reducing attack paths, compliance risk, and operational complexity.

Stop Advanced ThreatsFree Containment AssessmentUnder Active Attack?
Cta pattren Image