Kaspersky's Global Emergency Response Team investigated a 10-day ransomware campaign by the BlackNevas group that destroyed an organization's virtualization estate using legitimate VMware management interfaces without exploiting virtualization layer vulnerabilities.
Legitimate Interfaces as Attack Vectors
Kaspersky investigators examined an incident where the BlackNevas ransomware group targeted four ESXi hosts, every virtual machine, two vCenter Server Appliances, and connected backup infrastructure over a 10-day period. According to the report, no virtualization layer vulnerabilities were exploited during the campaign, and every action against ESXi was executed through legitimate VMware management interfaces.
The attackers compromised a vCenter appliance via SSH and established two layers of persistence. The first used MeshAgent, while the second used Ligolo-ng as a reverse tunnel implemented as a systemd service. Using vCenter Host Profiles, the adversary changed the TSM-SSH service state to enable SSH on target ESXi hosts.
Payload Delivery and Backup Disruption
According to the investigation, the payload was delivered to ESXi via SFTP using the FlowSsh client library. Attackers executed a self-test run roughly three hours before final detonation, then triggered destructive activity using command parameters matching Trigona and BlackNevas family behavior.
Before the ESXi detonation, the attacker disabled antivirus protection on the backup environment, stopped backup services, and encrypted the recovery infrastructure. Kaspersky notes that an overwrite of the first 2 KB of virtual disk files does not by itself mean that partition metadata is unrecoverable, as practical recovery depends on the exact virtual-disk layout.
What to do
- Treat vCenter as a Tier 0 asset and protect it with dedicated administrative identities and phishing-resistant MFA.
- Separate virtualization identities from ordinary enterprise administration.
- Keep direct ESXi management paths narrow by using Lockdown Mode and restricting management-network access.
- Make the logging path independent of the affected host using centralized remote storage.
- Design backup as a separate security boundary with independent administrative identities and isolated repositories.
Key facts and where they come from
- No virtualization layer vulnerabilities were exploited during the BlackNevas campaign.
no virtualization layer vulnerabilities were exploited: no guest-to-host escapes, no hypervisor memory corruption.
- Attackers established persistence on the vCenter appliance using MeshAgent and Ligolo-ng.
The first used MeshAgent, the endpoint component of the legitimate MeshCentral remote management platform. The second used Ligolo-ng as a reverse tunnel
- The adversary used vCenter Host Profiles to enable SSH on target ESXi hosts.
In this incident, the adversary used Host Profiles to change TSM-SSH service state to enable SSH on target ESXi hosts.
- The attacker disabled backup protections before initiating the ESXi detonation phase.
the attacker disabled antivirus protection on the backup environment days before the main attack
The catch
- Exact binary hashes for the ESXi encryptor, Ligolo-ng binary, agent installer script, and credential-extraction script were not available.
- The exact technique used to stop virtual machines during the incident remains unknown.
Reader poll: Should organizations restrict direct ESXi management access to explicitly approved network segments?
A show of hands from readers, not a scientific poll. Say why in the comments.
