Kaspersky Details ESXi Ransomware Attack and Defenses After vCenter Compromise

Nov 13, 2026 · Original article ↗

Summary

Kaspersky describes a 10-day ransomware incident in which attackers used compromised vCenter and valid credentials to access ESXi, establish persistence, disrupt backups and render VMs unavailable. The article details investigative evidence and defensive measures.

Key points

The investigation found no evidence that ESXi vulnerabilities were used for initial access; attackers reached vCenter using credentials obtained from systems inside the organization.
Attackers used vCenter Host Profiles to enable SSH on ESXi hosts, then accessed those hosts from the vCenter appliance.
The attackers established persistence on vCenter using MeshAgent and a Ligolo-ng tunnel configured as a systemd service.
Backup services and recovery infrastructure were disrupted before the ESXi detonation, limiting restoration capability.
The article correlates evidence from logs including auth.log, shell.log, vpxa.log and vobd.log to reconstruct activity and identify detection opportunities.
Recommended defenses include separating virtualization and enterprise credentials, restricting management access, monitoring high-risk configuration changes, and forwarding logs to independent remote storage.

Article Details

Attack Vectors: In the investigated incident, credentials obtained from non-virtualization systems were used to access the vCenter Server Appliances; the article reports no evidence that an ESXi vulnerability was the initial access path.
After compromising a backup system with administrative execution, the adversary extracted stored credentials, creating a route toward other infrastructure tiers.
The adversary accessed the vCenter appliance over SSH, deployed MeshAgent, and later installed a persistent Ligolo-ng reverse tunnel.
Using vCenter Host Profiles, the adversary changed TSM-SSH service state to enable direct SSH access to target ESXi hosts.
The ESXi payload was delivered via SFTP, staged under /tmp, and run for a short self-test before the destructive phase.
Before ESXi detonation, the adversary disabled antivirus protection on the backup environment, stopped backup services, encrypted recovery infrastructure, and disrupted administrative access.
As separate vulnerability examples—not as initial access in the investigated incident—the article describes the Twelve group chaining CVE-2021-21972 and CVE-2021-22005 to plant a vCenter web shell and load a backdoor.
Defensive Notes: Separate virtualization administration from ordinary enterprise and domain administration; use distinct privileged identities and credentials for ESXi, vCenter, and backup infrastructure.
Restrict ESXi and vCenter management interfaces to necessary network segments, accounts, and workstations, and monitor privileged sessions and high-risk configuration changes.
Alert on Host Profile changes that enable TSM or TSM-SSH outside approved windows, especially when followed by SSH from vCenter or another management appliance.
Monitor for new or modified systemd units and unapproved binaries on VCSA, including VMware-like service names or paths.
Treat unexpected executable staging under /tmp, followed by execution and access to /vmfs, as a high-priority sequence; correlate SFTP, SSH client identifiers, chmod, and short validation runs.
Monitor rapid VM power-off or world-kill activity, changes that weaken execInstalledOnly or host acceptance levels, and signs of datastore wiping.
Protect backup systems as a separate security boundary with independent identities, restricted management paths, and recovery options that do not depend on the production control plane.
Forward ESXi and vCenter logs to storage outside the virtualization trust domain; preserve key logs and system artifacts before rebooting or remediating.

Indicators of compromise

Type	Indicator	Context
DOMAIN	`api[.]cloudvflare[.]com`	Ligolo-ng C2 domain identified in the VCSA persistence artifact; the article describes it as a one-character typosquat of cloudflare.com.
IPV4	`188[.]240[.]57[.]94`	VPS used for initial portal access in the investigated incident.
IPV4	`31[.]41[.]33[.]212`	VPS used for initial portal access in the investigated incident.
IPV4	`45[.]149[.]154[.]135`	C2 infrastructure used by the remote-management agent in the investigated incident.
IPV4	`91[.]92[.]242[.]121`	VPS used for initial portal access in the investigated incident.
SHA1	`28f8da19ddcdf26e426875c7a834b34a79bc1c33`	Sample-specific hash associated with svhost.exe / lock.exe in the incident indicators.
SHA256	`15dc419b7fbeb50c50820a7cd27997541deafa4fa710f074bb657f0149574baf`	Hash identified for the remote-management agent in the incident indicators.
SHA256	`5a9b7a0d3f25757aea957713d7e84cabec87597b3474368328a8fd5ed7a12f78`	Hash identified for an installed remote-management agent variant in the incident indicators.