AN0269: Analytic 0269
Addition of new users or changes to role permissions (e.g., ReadOnly -> Admin) via API or vSphere Client, particularly from non-jumpbox IPs.
Analyst context for executives and security teams
This analytic is about watching for new ESXi/vSphere users or privilege changes, especially when they come from sources other than approved administration jumpboxes. For leaders, the value is not just detecting an account change; it is confirming that privileged access to virtualization infrastructure is governed, auditable, and quickly reviewable during an incident.
Executive priority
ESXi administration controls critical server workloads, so unauthorized user creation or role elevation can create material risk to business continuity and incident response. Security leaders should ask whether vSphere/ESXi administrative changes are logged centrally, whether approved admin source locations are defined, and whether SOC or IT operations can rapidly validate who made a privilege change, from where, and whether it was authorized.
Technical view
Validate monitoring for additions of users and changes to role permissions on ESXi/vSphere, including role elevation such as ReadOnly to Admin. The supplied analytic specifically calls out activity via API or vSphere Client and highlights non-jumpbox IPs as higher-value context. SOC teams should baseline legitimate administrator paths and tune alerting around privileged account and role changes originating outside those paths.
Likely telemetry
- ESXi or vCenter user and role management events
- vSphere Client administrative activity logs
- vSphere or ESXi API activity logs
- Source IP address for administrative sessions or API calls
- Identity/account metadata for the actor making the change
Detection direction
- Confirm that ESXi/vSphere user creation and role-permission changes are actually collected and forwarded to the monitoring platform.
- Maintain an authoritative list of approved jumpboxes or administrative source networks so non-jumpbox activity can be evaluated consistently.
- Prioritize alerts for privilege elevation to administrative roles or creation of new privileged users.
- Tune for expected administrative maintenance to reduce false positives, but require change-ticket or operator validation for unusual source IPs.
- Because no official detection logic is provided, detection engineering should derive local logic from available ESXi/vCenter event fields and test it against approved admin workflows.
Mitigation priorities
- Restrict ESXi/vSphere administrative access to approved management paths such as controlled jumpboxes or management networks.
- Review and minimize administrative roles and assignments on ESXi/vSphere platforms.
- Require documented approval for user creation and role changes in virtualization administration.
- Centralize and retain ESXi/vSphere administrative audit logs for SOC and incident response use.
- Periodically reconcile actual ESXi/vSphere users and roles against expected identity and access records.
Analyst notes and limits
This object is a detection analytic for the ESXi platform. The official description focuses on new users and role-permission changes via API or vSphere Client, with emphasis on non-jumpbox IPs. No ATT&CK tactics, technique relationships, procedures, or formal detection logic were supplied, so the take is framed around defensive validation and governance rather than a specific adversary behavior chain.
The source does not provide detection pseudocode, event IDs, data component mappings, relationships, tactics, or mitigation mappings. Local ESXi/vCenter logging configuration, network architecture, identity model, and approved administrative workflows are required to turn this into reliable detection coverage.
Analytic 0269
Addition of new users or changes to role permissions (e.g., ReadOnly -> Admin) via API or vSphere Client, particularly from non-jumpbox IPs.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 0f449553e4b6… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN0269Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.