AN1455: Analytic 1455
Execution of `esxcli system hostname get`, `esxcli system version get`, or `esxcli hardware` commands through SSH or local shell.
Analyst context for executives and security teams
This analytic is relevant because it focuses on ESXi host discovery commands that reveal hostname, version, and hardware details through SSH or a local shell. For security leaders, the decision value is whether the organization can see administrative command activity on virtualization infrastructure, not just guest workload activity. ESXi visibility gaps can weaken incident response, audit evidence, and resilience planning because hypervisors sit underneath many business-critical systems.
Executive priority
Prioritize this as a virtualization infrastructure visibility question: can the SOC and incident response team prove who executed ESXi shell or SSH commands, when they ran, and on which host? Even without a supplied ATT&CK tactic or detection logic, the behavior is material because ESXi host identity, version, and hardware enumeration can inform follow-on administrative or intrusive activity. Leaders should validate logging, access governance, and evidence retention for ESXi management paths as part of business continuity, compliance readiness, and incident decision-making.
Technical view
The supplied analytic describes execution of `esxcli system hostname get`, `esxcli system version get`, or `esxcli hardware` through SSH or a local shell on ESXi. SOC and detection teams should validate whether ESXi hosts produce and forward shell/SSH session evidence and command execution records sufficient to identify these commands, the user or account context, source access path, timestamp, and target host. Because no official detection text or relationship context is provided, teams should treat this as a coverage validation item rather than a complete detection rule.
Likely telemetry
- ESXi SSH authentication and session logs
- ESXi local shell activity records where available
- Command execution evidence for `esxcli` invocations
- Administrative account and privilege context for ESXi access
- Host inventory records including ESXi hostname, version, and hardware metadata
Detection direction
- Confirm that ESXi SSH and local shell activity is logged and centrally retained; absence of this telemetry is the primary blind spot.
- Create or validate detections for execution of `esxcli system hostname get`, `esxcli system version get`, and `esxcli hardware` on ESXi management interfaces.
- Tune for legitimate administrator activity, maintenance windows, inventory jobs, and troubleshooting workflows to reduce false positives.
- Correlate command execution with user identity, source system, access method, and change-management context before escalation.
- Because no ATT&CK tactic or relationship context is supplied, avoid overclassifying the behavior; use it as a suspicious discovery signal when it is unexpected, unauthorized, or clustered with other ESXi administrative activity.
Mitigation priorities
- Restrict ESXi SSH and local shell access to authorized administrators and approved management paths.
- Review privileged access controls for ESXi management accounts, including accountability for shared or emergency access where applicable.
- Ensure ESXi logs are forwarded to centralized monitoring with retention aligned to incident response and audit needs.
- Maintain accurate ESXi asset inventory so hostname, version, and hardware enumeration can be compared against expected administrative activity.
- Document approved operational uses of these commands so the SOC can distinguish routine maintenance from anomalous activity.
Analyst notes and limits
This object is a detection analytic, not a technique, and it provides a narrow behavior description only. The key defensive value is validating visibility into ESXi management command activity. The supplied data includes platform ESXi and the exact commands of interest, but does not include official detection logic, ATT&CK tactics, related techniques, or procedure examples.
No official detection content, tactic, relationship context, attribution, or exploitation claim was supplied. Local ESXi logging configuration and SIEM ingestion determine whether this analytic can be operationalized. This take should not be interpreted as proof of malicious activity without environment-specific identity, access, and change context.
Analytic 1455
Execution of `esxcli system hostname get`, `esxcli system version get`, or `esxcli hardware` commands through SSH or local shell.
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 | f304a63b408b… |
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 AN1455Open 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.