THREAT-ESXi-HypervisorRansomware

Service Stop — ESXi Hypervisor Ransomware — Mass VM Termination and Datastore Encryption

Impact Last updated:

Modern ransomware affiliates increasingly bypass Windows endpoints entirely and encrypt directly on the VMware ESXi hypervisor, since ESXi has no support for traditional AV/EDR agents and a single host often backs dozens of production VMs. The attack chain — used by ESXiArgs, Cheerscrypt, Royal, Black Basta, Akira, and LockBit's ESXi locker variant — is consistent across families: gain access via stolen vCenter/ESXi credentials, exposed SLP/OpenSLP services, or an unpatched CVE; enable the ESXi Shell/SSH (TSM-SSH) service if it is disabled by default; enumerate every running VM on the host (`esxcli vm process list` or `vim-cmd vmsvc/getallvms`); force-kill every VM process in rapid succession (`esxcli vm process kill --type=force`) so no file locks block encryption; then iterate the datastore(s) encrypting or corrupting each VMDK/VMSD/VMX file, typically with an embedded OpenSSL-based routine, before dropping a ransom note into every datastore directory. Because there is no endpoint agent, detection must rely on ESXi/vCenter log forwarding — Shell.log (interactive shell command history), hostd.log (VM lifecycle and datastore file operations), vobd.log (VMkernel observation events), and auth.log (SSH session activity) — shipped to a SIEM via syslog, plus vCenter task/event auditing where vCenter itself has not also been compromised or shut down.

What is THREAT-ESXi-HypervisorRansomware ESXi Hypervisor Ransomware — Mass VM Termination and Datastore Encryption?

ESXi Hypervisor Ransomware — Mass VM Termination and Datastore Encryption (THREAT-ESXi-HypervisorRansomware) is a sub-technique of Service Stop (T1489) in the MITRE ATT&CK framework. It maps to the Impact tactic — the adversary is trying to manipulate, interrupt, or destroy your systems and data.

This page provides production-ready detection logic for ESXi Hypervisor Ransomware — Mass VM Termination and Datastore Encryption, covering the data sources and telemetry it touches: VMware ESXi Shell.log, hostd.log, vobd.log, auth.log forwarded via syslog, Azure Monitor Agent Linux syslog collection, vCenter Server task/event logs (if vCenter itself remains available). The queries below are rated critical severity at high confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Impact
Microsoft Sentinel / Defender
kusto
// THREAT-ESXi-HypervisorRansomware (T1489 Service Stop -> T1486 Data Encrypted for Impact)
// Requires ESXi/vCenter syslog forwarded to the Syslog table (Azure Monitor Agent Linux syslog collection)
let ESXiHosts = dynamic(["<YOUR_ESXI_HOST_FQDNS_OR_IPS>"]); // populate from vCenter inventory; leave empty to match on ProcessName instead
let Lookback = 1h;
// Signal 1: SSH enabled/used on ESXi shortly before mass VM kill activity
let SSHActivity = Syslog
| where TimeGenerated > ago(Lookback)
| where ProcessName has_any ("sshd", "hostd")
| where SyslogMessage has_any ("Accepted password", "Accepted publickey", "TSM-SSH", "SSH login enabled")
| project TimeGenerated, Computer, SyslogMessage, Indicator = "SSHEnabledOrUsed";
// Signal 2: burst of forced VM kills / power-off commands on a single host
let VMKillBurst = Syslog
| where TimeGenerated > ago(Lookback)
| where (isempty(ESXiHosts) or Computer in (ESXiHosts))
| where SyslogMessage has_any ("esxcli vm process kill", "vim-cmd vmsvc/power.off", "vim-cmd vmsvc/power.shutdown")
| extend WorldOrVmId = extract(@"(world-id|--world-id)[= ]([0-9]+)", 2, SyslogMessage)
| summarize KillCount = count(), DistinctTargets = dcount(WorldOrVmId), SampleCommands = make_set(SyslogMessage, 10) by Computer, bin(TimeGenerated, 10m)
| where KillCount >= 5 or DistinctTargets >= 5
| project TimeGenerated, Computer, SyslogMessage = strcat_array(SampleCommands, " | "), Indicator = "MassVMKill";
// Signal 3: bulk datastore file rename/delete of VM disk files in the same window (encryption/corruption in progress)
let DatastoreBulkOps = Syslog
| where TimeGenerated > ago(Lookback)
| where ProcessName has "hostd"
| where SyslogMessage has_any (".vmdk", ".vmx", ".vmsd", ".vswp")
| where SyslogMessage has_any ("Rename", "rm -f", "unlink", "delete")
| summarize FileOpCount = count(), SampleFiles = make_set(SyslogMessage, 10) by Computer, bin(TimeGenerated, 10m)
| where FileOpCount >= 20
| project TimeGenerated, Computer, SyslogMessage = strcat_array(SampleFiles, " | "), Indicator = "BulkDatastoreFileOps";
union SSHActivity, VMKillBurst, DatastoreBulkOps
| sort by TimeGenerated desc

Three-signal detection over ESXi/vCenter logs forwarded to the Syslog table. Signal 1 flags SSH being enabled or used on the ESXi shell (SSH is disabled by default, so any use is notable). Signal 2 flags a burst of forced VM process kills or power-off commands against five or more distinct VMs within a 10-minute window on a single host — normal maintenance restarts one VM at a time, ransomware kills all of them almost simultaneously to clear file locks before encryption. Signal 3 flags bulk rename/delete operations against VM disk files (.vmdk/.vmx/.vmsd/.vswp), which is what the encryption or corruption routine looks like at the datastore-file level. Any one signal alone can be benign; two or more from the same host within the lookback window is a high-confidence hypervisor ransomware indicator.

critical severity high confidence

Data Sources

VMware ESXi Shell.log, hostd.log, vobd.log, auth.log forwarded via syslog Azure Monitor Agent Linux syslog collection vCenter Server task/event logs (if vCenter itself remains available)

Required Tables

Syslog

False Positives

  • Planned maintenance windows (ESXi patching, host reboot, DRS maintenance mode) where an administrator or vCenter orchestrates an intentional mass VM shutdown across a host
  • Disaster recovery failover tests that power off VMs on a source host as part of a rehearsed cutover
  • Backup software (Veeam, Commvault) that briefly quiesces or snapshots VMs, which can appear in hostd.log as file operations against VMDK/VMSD files
  • vMotion or Storage vMotion operations that create transient rename/copy activity against datastore files during live migration
  • Legitimate SSH access by infrastructure teams for authorized troubleshooting, especially where SSH is intentionally left enabled in lab/dev clusters

Sigma rule & cross-platform mapping

The detection logic for ESXi Hypervisor Ransomware — Mass VM Termination and Datastore Encryption (THREAT-ESXi-HypervisorRansomware) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource:

logsource:
  product: azure

Browse the community-maintained Sigma rules for this technique:


Testing Methodology

Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Simulated ESXi VM Enumeration and Forced Kill (Lab Only)

    Expected signal: Shell.log/hostd.log entries recording the esxcli vm process list and esxcli vm process kill --type=force invocations with the target world ID, timestamped seconds apart. hostd.log records the corresponding VM power-state transition to poweredOff.

  2. Test 2Simulated SSH Enablement on ESXi (Lab Only)

    Expected signal: vobd.log records the TSM-SSH service state change to running; a subsequent successful SSH login appears in auth.log with 'Accepted password' or 'Accepted publickey'.

  3. Test 3Simulated Bulk Datastore File Rename (Lab Only)

    Expected signal: hostd.log records rename operations against the .vmdk-named test files in rapid succession.


Response Playbook

Triage

  1. Confirm scope immediately: connect to vCenter (if still reachable) or another ESXi host in the cluster and check which VMs on the affected host are powered off and whether their VMDK files show signs of encryption (renamed extensions, ransom note files in the datastore directory)
  2. Check whether SSH/TSM-SSH was recently enabled on the host — 'esxcli system settings advanced list -o /UserVars/ESXiShellTimeOut' and lockdown mode status ('esxcli system security certificatestore list' won't show this; instead check the DCUI or vCenter host configuration > Security Profile > Services) — SSH being on when your baseline says it should be off is itself an incident
  3. Pull the auth.log entries around the incident window to identify the source IP and account used to SSH into the host — was this a service account, a jump host, or an unrecognized external IP?
  4. Enumerate exactly which VMs were killed and in what order using hostd.log/Shell.log timestamps — near-simultaneous kills across every VM on the host (rather than one at a time) confirms scripted mass termination rather than an operational restart
  5. Check for a ransom note dropped into datastore root directories (commonly named similar to 'How To Restore Your Files.txt', 'ransomware.args', or a group-specific filename) — its presence and modification timestamp anchors the encryption completion time
  6. Determine whether the same credentials were used across other ESXi hosts or vCenter in the same timeframe — hypervisor ransomware crews typically script the attack across every host in a cluster, not just one

Containment

  1. Immediately disable SSH/TSM-SSH on every other ESXi host in the cluster and rotate the root password on all hosts — do not wait for confirmation on additional hosts, given how fast the encryption routine runs once VM kills complete
  2. Isolate the management network (vMotion/management VLAN) for the affected cluster to prevent the attacker from reaching additional hosts or vCenter itself
  3. If vCenter is still accessible and uncompromised, place unaffected hosts into a locked-down state (disable SSH, enable lockdown mode) before the attacker can reach them
  4. Do NOT power on or attempt to boot affected VMs until forensic imaging of the datastore has been captured — booting can overwrite recoverable unencrypted blocks or trigger secondary payloads
  5. Revoke and rotate any vCenter Single Sign-On (SSO) and ESXi root credentials that may have been used, and check for any newly created local ESXi accounts left as backdoors
  6. Notify the backup/DR team immediately to confirm the state of off-host and offline (immutable) backups before the attacker can pivot to delete those as well (see THREAT-CloudBackup-SnapshotPurge for the cloud-backup equivalent of this)

Evidence Collection

  1. Full Shell.log, hostd.log, vobd.log, and auth.log from the affected host(s) — these are typically at /var/log/ on ESXi and should be pulled before any reboot, since ESXi log persistence to disk depends on host configuration (some hosts run logs from RAM only)
  2. vCenter Server task and event history (Tasks & Events tab, or the vpxd logs) for PowerOffVM_Task, DestroyDatastore, and any UnregisterVM operations in the incident window
  3. A list of every datastore file with a modified timestamp during the incident window, sorted chronologically, to reconstruct the encryption sequence and identify the entry point VM
  4. The ransom note file itself (do not delete — capture hash and full content for law-enforcement/insurer engagement and to identify the specific ransomware family/negotiation portal)
  5. SSH session artifacts: source IP, authentication method (password vs key), and session duration from auth.log
  6. A full inventory snapshot of ESXi host build/patch version to identify whether a known unpatched CVE (rather than stolen credentials) was the entry vector

Escalation Criteria

  • ! Five or more VMs on a single host killed within a 10-minute window with no corresponding maintenance ticket or change request
  • ! SSH/TSM-SSH found enabled on a host where organizational policy and baseline configuration mandate it disabled
  • ! A ransom note or encrypted-file-extension pattern discovered in any datastore directory
  • ! The same attacker-controlled credentials or source IP observed against more than one ESXi host or against vCenter itself
  • ! Evidence that backup infrastructure (Veeam repository, cloud snapshot vaults) was also targeted in the same operational window, indicating a coordinated recovery-denial campaign rather than an isolated host compromise

Investigation Guide

Forensic Artifacts

  • > ESXi Shell.log (/var/log/Shell.log or /scratch/log/shell.log): full command history for any interactive ESXi Shell/SSH session, including every esxcli and vim-cmd invocation
  • > hostd.log (/var/log/hostd.log): VM lifecycle events (power state changes) and datastore file operation records
  • > vobd.log (/var/log/vobd.log): VMkernel observation events including service state changes such as SSH/TSM-SSH enablement
  • > auth.log (/var/log/auth.log): SSH authentication attempts, source IPs, and session start/end times
  • > vCenter vpxd logs and the Tasks & Events database: PowerOffVM_Task, DestroyDatastore, and UnregisterVM task records with initiating user identity
  • > Datastore .lck lock files and orphaned .vswp swap files left behind after abrupt VM termination — their presence and timestamps help reconstruct which VMs were killed and when
  • > Any dropped ransom note file in the datastore root — filename, content, and modification time

Tuning Guidance

The highest-value tuning step is maintaining an allowlist of expected maintenance windows (change tickets, DRS-orchestrated host evacuation) so that legitimate mass VM shutdowns during patching don't drown out the rare true positive — cross-reference kill bursts against your CMDB/change calendar before alerting. Because SSH is disabled by default on ESXi, treat ANY SSH enablement event as at least a medium-severity alert regardless of the VM-kill correlation, since enabling it is itself outside normal operations for most vCenter-managed environments. For the datastore bulk-file-operation signal, exclude known backup-software service accounts and vMotion/Storage vMotion activity windows (visible in vCenter task history) to avoid false positives from routine data protection and migration operations. Where possible, feed this detection from vCenter's centralized event stream rather than per-host syslog alone — vCenter aggregates across the whole cluster and makes it far easier to spot the same attacker credential touching multiple hosts within minutes, which is the strongest single indicator of an active hypervisor ransomware event versus a single-host anomaly.


Hunting Queries

Baseline hunt across 30 days of ESXi syslog for any SSH enablement or login activity. Since SSH is disabled by default and most organizations manage ESXi exclusively through vCenter, any occurrence at all is worth investigating — this hunt establishes which hosts have SSH usage as an accepted operational pattern versus which show it for the first time.

Hunting — KQL
kql
// Hunt: any SSH/TSM-SSH enablement or use on ESXi hosts in the last 30 days, baselined against expected maintenance windows
Syslog
| where TimeGenerated > ago(30d)
| where ProcessName has_any ("sshd", "hostd")
| where SyslogMessage has_any ("Accepted password", "Accepted publickey", "TSM-SSH")
| summarize Occurrences = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by Computer
| order by Occurrences desc
Hunting — SPL
spl
index=esxi sourcetype=syslog (_raw="*Accepted password*" OR _raw="*Accepted publickey*" OR _raw="*TSM-SSH*")
| stats count as Occurrences, earliest(_time) as FirstSeen, latest(_time) as LastSeen by host
| sort - Occurrences

Wider hunt (15-minute window, lower threshold of 3 distinct VMs) than the primary detection to catch smaller clusters or hosts with fewer total VMs, where a 5-VM burst threshold would never fire.

Hunting — KQL
kql
// Hunt: hosts with 3+ distinct VMs powered off within any 15-minute window over the last 14 days
Syslog
| where TimeGenerated > ago(14d)
| where SyslogMessage has_any ("vim-cmd vmsvc/power.off", "esxcli vm process kill")
| extend VmRef = extract(@"(vmid|world-id)[= ]([0-9]+)", 2, SyslogMessage)
| summarize KillCount = count(), DistinctVms = dcount(VmRef) by Computer, bin(TimeGenerated, 15m)
| where DistinctVms >= 3
| order by DistinctVms desc
Hunting — SPL
spl
index=esxi sourcetype=syslog (_raw="*vim-cmd vmsvc/power.off*" OR _raw="*esxcli vm process kill*")
| bin _time span=15m
| stats count as KillCount, dc(_raw) as DistinctEvents by host, _time
| where DistinctEvents >= 3
| sort - DistinctEvents

Atomic Red Team Tests

Test 1 Simulated ESXi VM Enumeration and Forced Kill (Lab Only)
linux

Replicates the reconnaissance-then-kill sequence used by hypervisor ransomware: list all running VM worlds, then force-kill a target VM process. WARNING: run only against a disposable lab VM on a non-production ESXi host — this is a real, destructive power-off, not a simulation of one.

Command

bash
esxcli vm process list && esxcli vm process kill --type=force --world-id=<TEST_VM_WORLD_ID>

Cleanup

bash
vim-cmd vmsvc/power.on <TEST_VM_ID>

Expected Telemetry

Shell.log/hostd.log entries recording the esxcli vm process list and esxcli vm process kill --type=force invocations with the target world ID, timestamped seconds apart. hostd.log records the corresponding VM power-state transition to poweredOff.

Expected Detection

KQL/SPL VMKillBurst signal will not fire on a single kill (threshold is 5+ distinct VMs) — this atomic validates the underlying log pattern; run it against 5+ disposable lab VMs in the same 10-minute window to trigger the full burst detection.

Test 2 Simulated SSH Enablement on ESXi (Lab Only)
linux

Enables the TSM-SSH service on an ESXi host, replicating the first step an attacker takes when SSH/ESXi Shell access is required and not already available. Only run on a lab host where SSH is expected to be off by policy.

Command

bash
vim-cmd hostsvc/enable_ssh

Cleanup

bash
vim-cmd hostsvc/disable_ssh

Expected Telemetry

vobd.log records the TSM-SSH service state change to running; a subsequent successful SSH login appears in auth.log with 'Accepted password' or 'Accepted publickey'.

Expected Detection

KQL/SPL SSHEnabledOrUsed / SSHActivity signal fires on the service-state and/or login event.

Test 3 Simulated Bulk Datastore File Rename (Lab Only)
linux

Renames a batch of test VMDK-extension files on a disposable lab datastore path to simulate the file-level footprint of an encryption routine iterating over VM disk files. Use only synthetic test files, never files belonging to a real VM.

Command

bash
cd /vmfs/volumes/<TEST_DATASTORE>/atomic-test-dir && for f in test_disk_*.vmdk; do mv "$f" "$f.locked"; done

Cleanup

bash
cd /vmfs/volumes/<TEST_DATASTORE>/atomic-test-dir && for f in test_disk_*.vmdk.locked; do mv "$f" "${f%.locked}"; done

Expected Telemetry

hostd.log records rename operations against the .vmdk-named test files in rapid succession.

Expected Detection

KQL/SPL BulkDatastoreFileOps/DatastoreFileOp signal fires once 20+ rename/delete operations are logged within the 10-minute window — scale the test file count accordingly to cross the threshold.

Related Detections

Tactic Hub