THREAT-ESXi-HypervisorRansomware Google Chronicle · YARA-L

Detect ESXi Hypervisor Ransomware — Mass VM Termination and Datastore Encryption in Google Chronicle

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.

MITRE ATT&CK

Tactic
Impact

YARA-L Detection Query

Google Chronicle (YARA-L)
yaral 
rule esxi_hypervisor_ransomware {
  meta:
    author = "df00tech Detection Engineering"
    description = "Detects ESXi hypervisor ransomware precursor activity: SSH enablement/use, mass VM kill commands, and bulk datastore file operations"
    reference = "https://attack.mitre.org/techniques/T1489/"
    severity = "CRITICAL"
    priority = "HIGH"
    mitre_attack_tactic = "Impact"
    mitre_attack_technique = "T1489, T1486"
    false_positives = "Planned maintenance, DR tests, backup software quiescing, Storage vMotion"
    version = "1.0"

  events:
    $e.metadata.event_type = "GENERIC_EVENT"
    (
      re.regex($e.metadata.description, `(?i)(accepted password|accepted publickey|tsm-ssh)`) or
      re.regex($e.metadata.description, `(?i)(esxcli vm process kill|vim-cmd vmsvc/power)`) or
      (
        re.regex($e.metadata.description, `(?i)(\.vmdk|\.vmx|\.vmsd|\.vswp)`) and
        re.regex($e.metadata.description, `(?i)(rename|rm -f|unlink|delete)`)
      )
    )

  condition:
    $e
}
critical severity medium confidence

Chronicle YARA-L 2.0 rule matching GENERIC_EVENT UDM records populated from ESXi syslog forwarding (ESXi/vCenter logs typically arrive as unstructured/generic events rather than a dedicated Chronicle parser). Fires on SSH enablement/use, VM kill/power-off command patterns, or bulk datastore file rename/delete activity captured in the event description field. Correlate $e.principal.hostname across matches within a 10-minute window in Chronicle's rule aggregation to build the full burst-detection signal.

Data Sources

Google Chronicle UDM GENERIC_EVENT records from ESXi syslog forwarding

Required Tables

UDM events with metadata.event_type = GENERIC_EVENT

False Positives & Tuning

  • Planned maintenance windows with intentional mass VM shutdown
  • Backup software VM quiescing/snapshot activity
  • Storage vMotion live-migration file operations
  • Authorized SSH troubleshooting where SSH is deliberately enabled

Other platforms for THREAT-ESXi-HypervisorRansomware

Microsoft Sentinel (KQL) Splunk (SPL) Elastic Security (Elastic) IBM QRadar (QRadar) Sumo Logic CSE (Sumo) CrowdStrike LogScale (LogScale) All platforms (combined) →

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.

Last updated: 2026-07-17 Research depth: deep
References (6)

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

Related Techniques

T1486 — Data Encrypted for Impact (the VMDK/datastore encryption that follows the mass VM kill)T1490 — Inhibit System Recovery (attackers frequently also delete VM snapshots and target backup infrastructure in the same operation)T1021.004 — Remote Services: SSH (enabling and using ESXi Shell/SSH is the primary access vector)T1078 — Valid Accounts (stolen vCenter SSO or ESXi root credentials are the most common initial access method)T1210 — Exploitation of Remote Services (unpatched ESXi CVEs, e.g. OpenSLP-based vulnerabilities, as an alternative entry vector to credential theft)T1489 — Service Stop (this technique's parent — forced VM process termination is itself a service-stop action against every guest OS running on the host)

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

TA0040Impact

Detection Variants (2)

Different telemetry and tradecraft for the same technique — pick the one that matches the data you collect.

Parent Technique

T1489Service Stop

Related Techniques

T1486Data Encrypted for ImpactT1490Inhibit System RecoveryT1021.004SSHT1078Valid AccountsT1210Exploitation of Remote ServicesT1489Service Stop

Same Tactic: Impact

Popular Detections