How do you detect ransomware on ESXi hosts?

Forward ESXi shell.log, auth.log, hostd.log and vCenter events off the host in real time, because a root attacker can clear local logs. Alert on SSH or ESXi Shell enablement and lockdown mode changes outside change windows, on SSH logons from non-jump-host sources, and on esxcli vm process list and kill sequences and vim-cmd enumeration or power-off sweeps. Back this with identity monitoring for vCenter, immutable backups and storage-side alerts for bulk virtual disk modification, since most ESXi hosts cannot run an EDR agent.

Detecting ESXi and Hypervisor Ransomware

Ransomware operators target ESXi hosts directly because encrypting the datastore takes down dozens of virtual machines at once and bypasses guest-level security tools. The playbook is consistent: gain vCenter or host credentials, enable SSH or the ESXi Shell, enumerate and power off the VMs, then encrypt the virtual disk and related files. Most ESXi hosts have no EDR, so detection relies on log forwarding and behaviour at the management layer.

Signals at a Glance

Signal	Where	ATT&CK
SSH or ESXi Shell enabled on a host that normally has them off	vCenter events, hostd.log	T1021.004
SSH logon to ESXi from a non-jump-host source or new account	auth.log, syslog	T1078
esxcli vm process list followed by kill with force type	shell.log	T1489
vim-cmd vmsvc/getallvms and power-off sweeps	shell.log, hostd.log	T1673
Virtual disk, config and swap files rewritten or renamed in datastores	Datastore audit, storage array	T1486
Admin password or lockdown mode changes	vCenter events, hostd.log	T1098

Logs You Need Off the Host

ESXi keeps local logs that an attacker with root can clear, so forward them in real time. The key sources are shell.log (commands run in the shell), auth.log (SSH logons), hostd.log and vCenter events (shell enablement and VM operations). With those in Splunk, a search for VM-kill and enumeration commands is straightforward:

index=esxi (sourcetype=vmware:esxlog:shell OR source="*shell.log")
    ("esxcli vm process kill" OR "esxcli vm process list" OR "vim-cmd vmsvc/getallvms"
     OR "vim-cmd vmsvc/power.off" OR "esxcli storage filesystem list")
| rex field=_raw "(?<user>root|\w+)\s*:"
| bin _time span=10m
| stats count dc(_raw) as distinct_cmds values(_raw) as cmds by host, _time
| where count >= 3
| sort - count
# tune/validate: confirm sourcetype names for your syslog pipeline; allowlist maintenance windows.

Also alert on the enablement events themselves. Enabling SSH or the ESXi Shell outside a change window is a precursor you can catch before any VM is touched:

index=esxi (sourcetype=vmware:esxlog:hostd OR source="*hostd.log")
    ("SSH access has been enabled" OR "ESXi Shell for the host has been enabled"
     OR "Lockdown mode has been disabled")
| table _time host _raw
# tune/validate: message wording varies by ESXi version; check your own logs.

Harden and Detect Together

Keep SSH and the ESXi Shell disabled by default, enable lockdown mode, and route all management through vCenter from a dedicated admin network.
Protect the identity layer: ESXi intrusions typically start with vCenter or domain admin credentials, so alert on new vCenter admins, role changes and logons from unusual sources.
Take immutable or offline backups of VMs, and monitor the backup infrastructure itself, since operators target it first.
Where a storage array or datastore audit exists, alert on bulk modification of virtual disk files from an unexpected source.

Vetted sources

Use the VMware security guidance for ESXi hardening and logging, CISA #StopRansomware advisories on ESXi-targeting families, and the Elastic and SigmaHQ ESXi and Linux rules where present. Baseline your own administrators’ shell usage; some teams do use SSH routinely.

Build Detections That Fire

Mjolnir Security helps blue teams turn threat intelligence into high-fidelity detections across endpoint, network, identity and cloud telemetry.

Detection EngineeringManaged Detection & ResponseThreat HuntingIncident ResponsePurple Teaming

Detection Engineering We build and tune detections mapped to ATT&CK from your own telemetry.
Threat Hunting as a Service Hypothesis-driven hunts for the behaviours on this page.
24/7 Incident Response Containment when a detection fires. Call +1 833 403 5875.

Written by: Mjolnir Threat Research (MTAC)  |  Published: October 12, 2026  |  Last reviewed: October 12, 2026

Signals at a Glance

Logs You Need Off the Host

Harden and Detect Together

Build Detections That Fire

Endpoint Ransomware Detection

Detection Hub

Linux Ransomware Detection