ESXi Virtual Machine Process Killed

 1[metadata]
 2creation_date = "2026/09/30"
 3integration = ["vsphere"]
 4maturity = "production"
 5updated_date = "2026/09/30"
 6
 7[rule]
 8author = ["Elastic"]
 9description = """
10Detects termination of a virtual machine process on an ESXi host, including `esxcli vm process kill`, `pkill` of
11`vmx` processes, and `vmdumper` suspend. A running VM holds a lock on its disks. Stopping the process releases
12that lock and makes the disks writable.
13"""
14false_positives = [
15    """
16    Virtual machine process kills also happen during planned maintenance, host upgrades, and
17troubleshooting of a stuck VM. Confirm the world id, the account, and whether the same session also enumerates
18`/vmfs/volumes` or removes snapshots.
19    """,
20]
21from = "now-9m"
22index = ["logs-vsphere.log-*"]
23language = "kuery"
24license = "Elastic License v2"
25name = "ESXi Virtual Machine Process Killed"
26note = """## Triage and analysis
27
28### Investigating ESXi Virtual Machine Process Killed
29
30Stopping vmx releases the lock on a virtual disk. ESXi ransomware does this immediately before it encrypts files under /vmfs/volumes.
31
32#### Possible investigation steps
33
34- Read the full command in message and event.original. Note --type (soft, hard, force), --world-id / -w, and whether the line is an awk loop over vm process list.
35- Identify the account and source from the same host in /var/log/shell.log and /var/log/auth.log around @timestamp.
36- Check whether the same session listed VMs, searched for *.vmdk, removed snapshots, or reset the syslog loghost.
37- Confirm with the VM owner whether that world id was shut down on purpose.
38
39### False positive analysis
40
41Maintenance and crash recovery use the same esxcli kill types. A single soft shutdown of a named VM during a change window is often expected. A loop that kills every world id is not.
42
43### Response and remediation
44
45- If the kill was not approved, isolate the host from the management network and stop further shell activity.
46- Leave powered-on VMs running. Shutting them down releases disk locks and lets encryption continue.
47- Preserve shell.log, hostd.log, and auth.log, and restore any VM that was stopped from a known-good backup.
48"""
49references = [
50    "https://lolesxi-project.github.io/LOLESXi/#",
51    "https://blogs.vmware.com/security/2022/10/esxi-targeting-ransomware-tactics-and-techniques-part-2.html",
52    "https://detect.fyi/vmware-esxi-logging-detection-opportunities-4fb56411ec21",
53]
54setup = """## Setup
55
56This rule requires ESXi host logs collected by the Elastic vSphere integration: https://www.elastic.co/docs/reference/integrations/vsphere
57"""
58risk_score = 73
59rule_id = "2f0a3a40-1b21-5201-8657-ed84f67600c9"
60severity = "high"
61tags = [
62    "Domain: Endpoint",
63    "Data Source: VMware vSphere",
64    "Use Case: Threat Detection",
65    "Tactic: Impact",
66    "Resources: Investigation Guide",
67    "Rule Type: Custom Query (KQL)",
68    "Platform: VMware ESXi",
69    "Threat: Ransomware",
70]
71timestamp_override = "event.ingested"
72type = "query"
73
74query = '''
75data_stream.dataset:vsphere.log and message:("vm process kill" or pkill and vmx or suspend_v and vmdumper)
76'''
77
78[[rule.threat]]
79framework = "MITRE ATT&CK"
80[[rule.threat.technique]]
81id = "T1489"
82name = "Service Stop"
83reference = "https://attack.mitre.org/techniques/T1489/"
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]