AN1431: Analytic 1431
Detects use of 'esxcli system' or direct interpreter commands (e.g., busybox shell) invoked from SSH or host terminal unexpectedly.
Analyst context for executives and security teams
This analytic is about watching ESXi hosts for unexpected administrative command activity, specifically use of `esxcli system` or direct interpreter commands such as a BusyBox shell launched from SSH or the host terminal. For executives and security leaders, the practical issue is control over virtualization infrastructure: if ESXi management access is not well monitored, suspicious hands-on-keyboard activity may be missed until it affects hosted business services.
Executive priority
Prioritize this as a virtualization and operational resilience control question: do security and infrastructure teams have evidence of who accessed ESXi hosts, from where, and what privileged commands were run? This matters for incident decision-making, compliance evidence around privileged administration, and recovery confidence for systems dependent on ESXi. Because the supplied ATT&CK object is a detection analytic with no tactic or relationship context, it should be treated as a coverage validation item rather than proof of a specific threat campaign or technique chain.
Technical view
Validate whether ESXi command and access telemetry can show unexpected `esxcli system` usage or direct interpreter activity invoked via SSH or the host terminal. SOC and IR teams should confirm that ESXi host access logs, shell/session records, and administrative command evidence are collected, retained, and searchable. Detection engineering should define what is expected for normal ESXi administration in the local environment, then alert on deviations such as unusual source, user, timing, host, or command context. Since the official detection logic is not provided, implementation requires local baselining and testing rather than copying a MITRE rule.
Likely telemetry
- ESXi SSH authentication and session logs
- ESXi host terminal or shell access records
- Administrative command execution evidence involving `esxcli system`
- Evidence of BusyBox or other direct interpreter invocation on ESXi
- User, source address, timestamp, and target host context for ESXi administrative access
Detection direction
- Confirm whether ESXi telemetry is centralized into the SOC or SIEM; host-local logs alone may be insufficient during incident response.
- Baseline approved ESXi administrative behavior, including expected administrators, jump hosts, maintenance windows, and routine `esxcli` usage.
- Tune detections for unexpected invocation context rather than command presence alone, because legitimate administrators may use `esxcli system` during maintenance.
- Include SSH and direct host terminal activity; focusing only on one access path may create a blind spot.
- Correlate command activity with identity, source, and change records to reduce false positives and improve triage value.
Mitigation priorities
- Restrict and review ESXi SSH and host terminal access to approved administrators and approved management paths.
- Require accountable privileged access practices for ESXi administration, including named users where feasible and auditable session context.
- Centralize ESXi access and command-related logs with retention aligned to incident response and audit needs.
- Use change-management context to distinguish approved maintenance from unexpected administrative activity.
- Periodically test whether SOC analysts can retrieve ESXi access and command evidence during tabletop or incident response exercises.
Analyst notes and limits
This object is an ATT&CK detection analytic for ESXi. The official description is narrow: detecting unexpected `esxcli system` or direct interpreter commands from SSH or the host terminal. No ATT&CK tactics, relationships, aliases, labels, or official detection logic were supplied, so the take focuses on defensive validation and telemetry readiness rather than inferred adversary objectives.
The supplied object does not provide detection code, data source mappings, tactics, related techniques, mitigations, or adversary context. Local ESXi configuration, logging level, administrative practices, and SIEM ingestion determine whether this analytic can be implemented effectively.
Analytic 1431
Detects use of 'esxcli system' or direct interpreter commands (e.g., busybox shell) invoked from SSH or host terminal unexpectedly.
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 | 9f8bf2f5ca00… |
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 AN1431Open 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.