Why Hypervisors Are the New Ransomware Target

Ransomware operators encrypting individual Windows endpoints face a throughput problem: encrypting thousands of workstations takes time, and each one is an opportunity for detection and shutdown. ESXi-targeted ransomware eliminates this friction. By encrypting the hypervisor datastore directly, attackers render every hosted virtual machine simultaneously inoperable — with a single operation against a single host that frequently lacks endpoint detection coverage.

Mandiant’s M-Trends 2026 report identifies hypervisor management plane targeting as an accelerating ransomware technique, specifically naming REDBIKE (deployed by Akira-affiliated operators) and AGENDA (used by Qilin) as the primary ESXi payloads observed in 2025 investigations. The attack pattern is consistent across groups: establish access, move laterally to vCenter or ESXi management interfaces, deploy Linux ELF ransomware, encrypt VMFS datastores.

Standard endpoint detection tools don’t run on ESXi. If you don’t have specific detection logic for hypervisor-level events, you’re blind.

The ESXi Attack Chain

Phase 1: Initial Access and Lateral Movement to vCenter

Ransomware operators typically don’t attack ESXi directly first. They compromise a Windows admin workstation or jump server, harvest credentials (Mimikatz against LSASS, or extracting vCenter credentials from browser stores or configuration files), and authenticate to vCenter or the ESXi management interface (port 443 or SSH on port 22).

Credential targets:

  • vCenter Server Appliance admin credentials stored in Windows credential stores
  • vpxd service account credentials in vCenter’s embedded database
  • ESXi root password from documentation, password managers, or config management systems
  • SSH private keys for ESXi root access

Phase 2: ESXi Access and VM Shutdown

Before encryption, the ransomware shuts down running VMs using the ESXi esxcli or vim-cmd utilities. Running VMs have open file handles on their VMDK files, which prevents encryption. The shutdown sequence is:

# List all running VMs
esxcli vm process list

# Shutdown all VMs (force kill if needed)
for vmid in $(esxcli vm process list | grep "World ID:" | awk '{print $3}'); do
    esxcli vm process kill --type=force --world-id=$vmid
done

or via vim-cmd:

vim-cmd vmsvc/getallvms
vim-cmd vmsvc/power.off <vmid>

Detection opportunity: mass VM power-off events are anomalous outside a known maintenance window.

Phase 3: Datastore Encryption

REDBIKE and AGENDA target VMFS datastores directly, encrypting .vmdk, .vmx, .vmsd, and .nvram files. AGENDA (Qilin) also supports --vmkill flags that issue ESXi-level shutdown commands before encryption and --log flags that suppress normal ESXi logging activity.

Detection: ESXi Syslog Analysis

ESXi generates syslog entries for authentication events, shell activity, and VM power state changes. Forwarding ESXi syslog to your SIEM is the baseline requirement — without it, detection coverage doesn’t exist.

Configure syslog forwarding from each ESXi host:

esxcli system syslog config set --loghost=udp://your-siem:514
esxcli system syslog reload

Sigma Rule: ESXi SSH Authentication from New Source

title: ESXi SSH Authentication from Previously Unseen Source
id: a4c7f3b1-8e2d-4f19-b6a1-9e0c2d3f4b5a
status: experimental
description: Detects SSH authentication to an ESXi host from an IP not observed in the past 30 days
references:
  - https://www.mandiant.com/resources/reports/m-trends-2026
author: SOC Analyst Hub
date: 2026/07/06
tags:
  - attack.lateral_movement
  - attack.t1021.004
  - attack.impact
  - attack.t1486
logsource:
  product: vmware
  service: esxi
  category: authentication
detection:
  selection:
    EventType: 'sshd'
    Message|contains: 'Accepted'
  filter_known_admins:
    src_ip|cidr:
      - '10.0.0.0/8'  # adjust to known admin subnets only
  timeframe: 30d
  condition: selection and not filter_known_admins
falsepositives:
  - New admin workstations
  - DR/failover jump servers
level: high

Sigma Rule: Mass VM Power-Off Events

title: Mass Virtual Machine Power-Off — Potential Ransomware Pre-Encryption
id: b7d2e4f1-9a3c-4b28-c5e2-0f1a3b4d6c7e
status: experimental
description: >
  Detects more than 5 VM power-off events within 5 minutes from a single actor,
  consistent with ransomware shutdown scripting before VMFS encryption.
references:
  - https://www.mandiant.com/resources/reports/m-trends-2026
author: SOC Analyst Hub
date: 2026/07/06
tags:
  - attack.impact
  - attack.t1486
  - attack.t1529
logsource:
  product: vmware
  service: vcenter
detection:
  selection:
    EventType:
      - 'VmPoweredOffEvent'
      - 'VmSuspendedEvent'
  timeframe: 5m
  condition: selection | count() by UserName > 5
falsepositives:
  - Planned maintenance runbooks
  - Automated DR exercises
level: critical

Sigma Rule: ESXi Shell Commands Executing VM Management Utilities

title: ESXi Interactive Shell — VM Process Kill Commands
id: c9e1f5a2-b4d7-4c39-d6f3-1a2b4c5e7d8f
status: experimental
description: >
  Detects execution of esxcli or vim-cmd with kill or power-off arguments via
  ESXi shell, which ransomware uses to shut down VMs before encrypting datastores.
author: SOC Analyst Hub
date: 2026/07/06
tags:
  - attack.impact
  - attack.t1486
logsource:
  product: vmware
  service: esxi
  category: shell
detection:
  selection:
    CommandLine|contains:
      - 'esxcli vm process kill'
      - 'vim-cmd vmsvc/power.off'
      - 'vim-cmd vmsvc/power.shutdown'
      - '--type=force'
  condition: selection
falsepositives:
  - Legitimate admin shutdown scripts (should be from known service accounts only)
level: high

KQL: Mass VM Power-Off in Microsoft Sentinel

If you’re ingesting vCenter events via Azure Monitor or a third-party connector:

// Mass VM power-off — potential ransomware pre-encryption
VMwareActivity
| where TimeGenerated > ago(1h)
| where EventType in ("VmPoweredOffEvent", "VmSuspendedEvent", "VmStoppedEvent")
| summarize VMCount = count(), VMNames = make_set(ObjectName) by UserName, bin(TimeGenerated, 5m)
| where VMCount > 5
| extend Alert = strcat("User ", UserName, " powered off ", VMCount, " VMs in 5 min")
| project TimeGenerated, UserName, VMCount, VMNames, Alert
| order by TimeGenerated desc
// ESXi SSH access from external IPs
SyslogHosts
| where Computer contains "esxi" or Computer contains "vmware"
| where ProcessName == "sshd"
| where SyslogMessage contains "Accepted"
| extend SrcIP = extract(@"from (\d+\.\d+\.\d+\.\d+)", 1, SyslogMessage)
| where SrcIP !startswith "10." and SrcIP !startswith "192.168." and SrcIP !startswith "172."
| project TimeGenerated, Computer, SrcIP, SyslogMessage

Hardening to Reduce the Attack Surface

Lockdown Mode: Enable ESXi Lockdown Mode to disable direct root SSH access. All management must go through vCenter, which provides better audit trails.

vim-cmd hostsvc/enable_strict_lockdown

Separate vCenter credentials from Active Directory: vCenter joined to AD means a domain compromise equals vCenter access. Use local vCenter accounts for break-glass access and enforce MFA on the vCenter SAML identity source.

Dedicated management network: ESXi management interfaces (VMkernel port for management traffic) should be on a dedicated VLAN unreachable from standard user or server networks. Ransomware operators reach ESXi by pivoting from compromised Windows hosts — remove that network path.

Backup isolation: Backups that use agents running on VMs inside the same datastore can be encrypted alongside production data. Use hardware snapshots, replication to an independent target, or backup solutions that access datastores at the storage layer rather than the VM layer.

Log all ESXi shell activity: Set Security.AccountLockoutFailures and enable syslog forwarding for all shell-category events. Every command run in the ESXi shell should appear in your SIEM.

Hunting for Pre-Attack Staging

Beyond detection rules, hunt proactively for the pre-attack indicators:

  • New accounts created in vCenter or ESXi with administrator privileges
  • vCenter role changes that grant the VirtualMachine.Interact.PowerOff privilege to unusual accounts
  • SSH key additions to /etc/ssh/keys-root/authorized_keys on ESXi hosts
  • Datastore browser access from accounts that don’t normally access it
  • File uploads to ESXi datastores via SFTP or the vCenter datastore browser (ransomware binary staging)

If your threat hunting queries surface any of these behaviours outside of known change windows, treat it as an active incident.