AN0098: Analytic 0098
Detects process enumeration using `esxcli system process list` or `ps` on ESXi shell or via unauthorized SSH sessions. Correlates with interactive sessions and abnormal user roles.
Analyst context for executives and security teams
AN0098 is an ESXi-focused detection analytic for process enumeration through commands such as `esxcli system process list` or `ps`, especially when seen in ESXi shell or unauthorized SSH sessions. For leaders, the practical issue is visibility into hypervisor administration: if teams cannot reliably see who is interactively enumerating processes on ESXi hosts, incident responders may miss early hands-on activity affecting virtual infrastructure operations.
Executive priority
Prioritize this analytic where ESXi hosts support critical workloads. The business decision value is not just detecting a command; it is validating whether hypervisor administrative access, SSH usage, role assignments, and session logging are governed well enough to support incident decisions, audit evidence, and business-continuity response. Security leaders should ask whether ESXi shell and SSH access are expected, approved, logged, and reviewable by role.
Technical view
SOC and detection engineering teams should validate collection and correlation for ESXi command execution involving `esxcli system process list` and `ps`, interactive ESXi shell activity, SSH session context, and user role information. The supplied analytic specifically calls for correlation with interactive sessions and abnormal user roles, so detection logic should not rely on command strings alone. IR teams should be able to reconstruct the user, source session, access method, role, host, and timing around process enumeration events.
Likely telemetry
- ESXi shell command activity or command history where available
- SSH session logs for ESXi hosts
- Interactive login/session records for ESXi administration
- User and role assignment information for ESXi access
- Host-level timestamps identifying when process enumeration commands were run
Detection direction
- Validate whether `esxcli system process list` and `ps` activity on ESXi can be observed and tied to a user/session.
- Correlate command execution with interactive ESXi shell or SSH access rather than treating all process listing as malicious.
- Tune for abnormal user roles or unauthorized SSH sessions, as specified by the analytic description.
- Define expected administrative workflows to reduce false positives from legitimate troubleshooting.
- Review blind spots where ESXi shell, SSH, or role telemetry is not centrally collected or retained.
Mitigation priorities
- Restrict ESXi shell and SSH access to approved administrative use cases.
- Review ESXi user roles and remove excessive or abnormal privileges.
- Maintain centralized logging for ESXi access, sessions, and administrative activity.
- Document approved hypervisor administration procedures so SOC teams can distinguish expected maintenance from suspicious enumeration.
- Ensure incident response playbooks include rapid validation of ESXi user, role, session source, and command activity.
Analyst notes and limits
This take is based on a detection analytic, not a technique object. The object provides an ESXi platform scope and a description focused on process enumeration using `esxcli system process list` or `ps`, correlated with interactive sessions and abnormal user roles. No ATT&CK tactics, relationships, or separate official detection text were supplied.
No relationship context, tactic mapping, procedure examples, mitigation objects, or official detection implementation details were supplied. Local ESXi configuration, logging capabilities, retention, role model, and authorized administration patterns are required to determine practical coverage and tuning.
Analytic 0098
Detects process enumeration using `esxcli system process list` or `ps` on ESXi shell or via unauthorized SSH sessions. Correlates with interactive sessions and abnormal user roles.
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 | ae0e1f323fbb… |
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 AN0098Open 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.