ESXi Account Granted Admin Role

Detects an ESXi account being granted the Administrator role. Administrator is full control of the host, including the firewall, SSH, accounts, and every virtual machine. Granting it to another account keeps that access after the original session ends.

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 an ESXi account being granted the Administrator role. Administrator is full control of the host, including
11the firewall, SSH, accounts, and every virtual machine. Granting it to another account keeps that access after the
12original session ends.
13"""
14false_positives = [
15    """
16    New virtualization administrators and service accounts are granted Admin during approved
17account provisioning. Confirm the account name against the identity ticket.
18    """,
19]
20from = "now-9m"
21index = ["logs-vsphere.log-*"]
22language = "kuery"
23license = "Elastic License v2"
24name = "ESXi Account Granted Admin Role"
25note = """## Triage and analysis
26
27### Investigating ESXi Account Granted Admin Role
28
29Admin on a standalone ESXi host can change the firewall, syslog, SSH, and every virtual machine. Granting that role to an unexpected account is a persistence path that survives the interactive session.
30
31#### Possible investigation steps
32
33- Read the account name in message. The shell form uses --id. The hostd form is Permission created for <name>.
34- Compare that name with known ESXi accounts (root, dcui, vpxuser, and approved operators).
35- Look for a preceding Account <name> was created or esxcli system account add for the same id.
36- Check whether that account was used for SSH or further esxcli commands.
37
38### False positive analysis
39
40Joiner automation and break-glass account setup grant Admin on purpose. The account id should match a ticket.
41
42### Response and remediation
43
44- If the account is unknown, remove the permission and the account: esxcli system permission unset and esxcli system account remove.
45- Rotate credentials that were exposed in the same session.
46- Hunt other hosts for the same account id.
47"""
48references = [
49    "https://lolesxi-project.github.io/LOLESXi/#",
50    "https://blogs.vmware.com/security/2022/10/esxi-targeting-ransomware-tactics-and-techniques-part-2.html",
51    "https://detect.fyi/vmware-esxi-logging-detection-opportunities-4fb56411ec21",
52]
53setup = """## Setup
54
55This rule requires ESXi host logs collected by the Elastic vSphere integration: https://www.elastic.co/docs/reference/integrations/vsphere
56"""
57risk_score = 73
58rule_id = "2e6ec182-2a31-5ff9-8b42-fdcb6f04e4c7"
59severity = "high"
60tags = [
61    "Domain: Endpoint",
62    "Data Source: VMware vSphere",
63    "Use Case: Threat Detection",
64    "Tactic: Persistence",
65    "Resources: Investigation Guide",
66    "Rule Type: Custom Query (KQL)",
67    "Platform: VMware ESXi",
68]
69timestamp_override = "event.ingested"
70type = "query"
71
72query = '''
73data_stream.dataset:vsphere.log and event.module:vsphere and message:("system permission set" and ("--role Admin" or "--role=Admin") or "Permission created" and "role is Administrator")
74'''
75
76[[rule.threat]]
77framework = "MITRE ATT&CK"
78[[rule.threat.technique]]
79id = "T1098"
80name = "Account Manipulation"
81reference = "https://attack.mitre.org/techniques/T1098/"
82
83[rule.threat.tactic]
84id = "TA0003"
85name = "Persistence"
86reference = "https://attack.mitre.org/tactics/TA0003/"
87
88[rule.investigation_fields]
89field_names = [
90    "@timestamp",
91    "message",
92    "event.original",
93    "host.hostname",
94    "log.file.path",
95]

Triage and analysis

Investigating ESXi Account Granted Admin Role

Admin on a standalone ESXi host can change the firewall, syslog, SSH, and every virtual machine. Granting that role to an unexpected account is a persistence path that survives the interactive session.

Possible investigation steps

  • Read the account name in message. The shell form uses --id. The hostd form is Permission created for .
  • Compare that name with known ESXi accounts (root, dcui, vpxuser, and approved operators).
  • Look for a preceding Account was created or esxcli system account add for the same id.
  • Check whether that account was used for SSH or further esxcli commands.

False positive analysis

Joiner automation and break-glass account setup grant Admin on purpose. The account id should match a ticket.

Response and remediation

  • If the account is unknown, remove the permission and the account: esxcli system permission unset and esxcli system account remove.
  • Rotate credentials that were exposed in the same session.
  • Hunt other hosts for the same account id.

References

Related rules

to-top