AN1586: Analytic 1586
ESXi shell or SSH access issuing `esxcli network diag ping` or viewing routing tables to identify connected hosts.
Analyst context for executives and security teams
This analytic concerns ESXi administrators or intruders using shell or SSH access to run ESXi network discovery commands, such as ping diagnostics or viewing routing tables, to understand what hosts are reachable from a hypervisor. For leaders, the significance is that ESXi sits close to critical workloads: visibility gaps on hypervisors can delay incident scoping, business continuity decisions, and containment planning.
Executive priority
Prioritize this as an ESXi visibility and incident-readiness question, not as proof of compromise by itself. Security leaders should ask whether ESXi shell and SSH use is governed, logged, reviewed, and tied to approved administrative activity. The business value is strongest for environments where virtualization supports critical services, because network discovery from a hypervisor can inform later movement or targeting, while poor logging can leave responders without evidence during an outage or investigation.
Technical view
Validate whether ESXi hosts produce and retain evidence of shell or SSH access and command execution involving `esxcli network diag ping` or routing table inspection. Because ATT&CK provides no official detection logic or related techniques for this analytic, SOC teams should treat it as a detection-engineering starting point: baseline legitimate ESXi administrative workflows, identify expected maintenance windows and admin accounts, and alert on unusual use of ESXi shell or SSH network discovery activity, especially from unexpected users, source systems, or times.
Likely telemetry
- ESXi host shell access logs
- ESXi SSH authentication and session logs
- Command execution records or audit logs for ESXi administrative commands where available
- Events showing use of `esxcli network diag ping`
- Evidence of routing table inspection on ESXi hosts
Detection direction
- Confirm that ESXi shell and SSH access events are collected centrally and retained long enough for incident response.
- Build allowlists or baselines for authorized ESXi administrators, jump hosts, maintenance windows, and expected diagnostic activity.
- Tune detections to reduce false positives from routine troubleshooting while preserving alerts for unexpected network discovery from ESXi hosts.
- Correlate command activity with authentication source, account privilege, change tickets, and other ESXi administration events.
- Document blind spots where command-level telemetry is unavailable; in those cases, rely on SSH/session evidence and administrative access review rather than claiming command-specific detection.
Mitigation priorities
- Restrict ESXi shell and SSH access to approved administrators and controlled management paths.
- Disable or limit interactive ESXi shell/SSH access when not operationally required.
- Enforce strong administrative access governance, including named accounts and reviewable privileged access processes.
- Centralize ESXi authentication, session, and administrative activity logging for SOC and incident response use.
- Maintain an approved-use baseline for ESXi diagnostic commands so investigations can distinguish maintenance from suspicious discovery behavior.
Analyst notes and limits
The supplied object is a detection analytic for ESXi only. It describes ESXi shell or SSH access being used to run network diagnostic ping or view routing tables to identify connected hosts. No ATT&CK tactic, official detection logic, aliases, labels, or relationship context were supplied, so the take focuses on telemetry validation, administrative access governance, and detection-readiness questions.
This assessment is limited to the supplied ATT&CK fields and external reference. It does not establish malicious intent, active exploitation, attribution, impact, or guaranteed detectability. Local ESXi configuration, logging depth, administrative practices, and SIEM ingestion determine whether this behavior can be observed reliably.
Analytic 1586
ESXi shell or SSH access issuing `esxcli network diag ping` or viewing routing tables to identify connected hosts.
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 | f43a95768f9d… |
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 AN1586Open 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.