ESXi Virtual Machine Powered Off

Detects vim-cmd vmsvc/power.off on an ESXi host. Powering a virtual machine off releases the lock the hypervisor holds on its virtual disks. With the guest stopped, those disks can be rewritten or encrypted while the machine is down.

Elastic rule (View on GitHub)

 1[metadata]
 2creation_date = "2026/09/30"
 3integration = ["vsphere"]
 4maturity = "production"
 5updated_date = "2026/09/30"
 6
 7[rule]
 8author = ["Elastic"]
 9description = """
10Detects `vim-cmd vmsvc/power.off` on an ESXi host. Powering a virtual machine off releases the lock the hypervisor
11holds on its virtual disks. With the guest stopped, those disks can be rewritten or encrypted while the machine
12is down.
13"""
14false_positives = [
15    """
16    Administrators power off virtual machines for patching, decommissioning, and hardware
17maintenance. Review the account and whether the command targeted one VM id or every id returned by `getallvms`.
18    """,
19]
20from = "now-9m"
21index = ["logs-vsphere.log-*"]
22language = "kuery"
23license = "Elastic License v2"
24name = "ESXi Virtual Machine Powered Off"
25note = """## Triage and analysis
26
27### Investigating ESXi Virtual Machine Powered Off
28
29vim-cmd vmsvc/power.off is the guest-aware shutdown path ransomware uses when esxcli vm process kill is not enough. A for loop over getallvms powers off every guest on the host.
30
31#### Possible investigation steps
32
33- Read message for a single VM id versus a loop over vim-cmd vmsvc/getallvms.
34- Correlate with snapshot removal, vm process kill, and find commands for *.vmdk on the same host.
35- Ask the VM owner whether that power-off was scheduled.
36
37### False positive analysis
38
39One VM powered off by a known administrator during a change window is commonly benign. Powering off every VM in one shell loop is the ransomware pattern.
40
41### Response and remediation
42
43- If the power-off was not approved, isolate the host and do not reboot it.
44- Power guests back on only after confirming their disks were not encrypted, or restore them from backup.
45- Preserve shell and hostd logs for the session that issued power.off.
46"""
47references = [
48    "https://lolesxi-project.github.io/LOLESXi/#",
49    "https://blogs.vmware.com/security/2022/10/esxi-targeting-ransomware-tactics-and-techniques-part-2.html",
50    "https://detect.fyi/vmware-esxi-logging-detection-opportunities-4fb56411ec21",
51]
52setup = """## Setup
53
54This rule requires ESXi host logs collected by the Elastic vSphere integration: https://www.elastic.co/docs/reference/integrations/vsphere
55"""
56risk_score = 47
57rule_id = "eefac402-2845-5498-90ff-e2e6eda987db"
58severity = "medium"
59tags = [
60    "Domain: Endpoint",
61    "Data Source: VMware vSphere",
62    "Use Case: Threat Detection",
63    "Tactic: Impact",
64    "Resources: Investigation Guide",
65    "Rule Type: Custom Query (KQL)",
66    "Platform: VMware ESXi",
67    "Threat: Ransomware",
68]
69timestamp_override = "event.ingested"
70type = "query"
71
72query = '''
73data_stream.dataset: "vsphere.log" and (
74  message: "vmsvc/power.off"
75)
76'''
77
78[[rule.threat]]
79framework = "MITRE ATT&CK"
80[[rule.threat.technique]]
81id = "T1529"
82name = "System Shutdown/Reboot"
83reference = "https://attack.mitre.org/techniques/T1529/"
84
85[rule.threat.tactic]
86id = "TA0040"
87name = "Impact"
88reference = "https://attack.mitre.org/tactics/TA0040/"
89
90[rule.investigation_fields]
91field_names = [
92    "@timestamp",
93    "message",
94    "event.original",
95    "host.hostname",
96    "log.file.path",
97]

Triage and analysis

Investigating ESXi Virtual Machine Powered Off

vim-cmd vmsvc/power.off is the guest-aware shutdown path ransomware uses when esxcli vm process kill is not enough. A for loop over getallvms powers off every guest on the host.

Possible investigation steps

  • Read message for a single VM id versus a loop over vim-cmd vmsvc/getallvms.
  • Correlate with snapshot removal, vm process kill, and find commands for *.vmdk on the same host.
  • Ask the VM owner whether that power-off was scheduled.

False positive analysis

One VM powered off by a known administrator during a change window is commonly benign. Powering off every VM in one shell loop is the ransomware pattern.

Response and remediation

  • If the power-off was not approved, isolate the host and do not reboot it.
  • Power guests back on only after confirming their disks were not encrypted, or restore them from backup.
  • Preserve shell and hostd logs for the session that issued power.off.

References

Related rules

to-top