AN0562: Analytic 0562
Use of `esxcli network` commands (e.g., `esxcli network nic list`, `esxcli network ip interface ipv4 get`) via SSH or hostd to enumerate adapter and IP information.
Analyst context for executives and security teams
This analytic focuses on ESXi hosts where `esxcli network` commands are used through SSH or hostd to enumerate network adapters and IP configuration. For leaders, the significance is not the command itself, but whether ESXi management activity is visible enough to distinguish routine administration from suspicious discovery of virtualization infrastructure.
Executive priority
ESXi hosts often support critical business services, so visibility into management-plane discovery matters for resilience and incident decision-making. Security leaders should ask whether SSH and hostd activity on ESXi is logged, retained, and reviewed, and whether administrative use of `esxcli network` can be tied back to an approved operator or change record.
Technical view
SOC and IR teams should validate whether ESXi telemetry can show execution or invocation of `esxcli network nic list`, `esxcli network ip interface ipv4 get`, and similar `esxcli network` commands via SSH or hostd. Because ATT&CK provides no official detection logic for this analytic, teams should build local baselines for expected administrator, automation, and maintenance activity before alerting on command use alone.
Likely telemetry
- ESXi SSH authentication and session records
- hostd management activity logs
- ESXi shell or command execution audit data where enabled
- Administrative task and event logs from ESXi management workflows
- Network access records to ESXi management interfaces
Detection direction
- Confirm that ESXi SSH and hostd activity is centrally collected and time-synchronized.
- Look for `esxcli network` command usage that enumerates NICs, IP interfaces, or IPv4 configuration.
- Correlate command activity with authenticated user, source system, access path, and approved maintenance windows.
- Tune for known administration and automation to reduce false positives, since these commands can be legitimate.
- Treat lack of command-level visibility on ESXi as a material blind spot rather than assuming coverage.
Mitigation priorities
- Limit ESXi management access to approved administrative paths and trusted sources.
- Disable or tightly control SSH access where it is not operationally required.
- Use role-based administrative access and review who can invoke ESXi management functions through SSH or hostd.
- Maintain baselines of expected ESXi network configuration checks and administrative workflows.
- Ensure ESXi management logs are retained long enough to support incident response and audit review.
Analyst notes and limits
The supplied object is a detection analytic for ESXi and describes network adapter and IP enumeration using `esxcli network` via SSH or hostd. No tactics, relationships, aliases, or official detection logic were supplied, so this take emphasizes validation of telemetry, baselining, and management-plane visibility rather than a specific detection rule.
This assessment is limited to the official STIX fields, external reference, and empty relationship context provided. It does not establish adversary use, exploitation, impact, or existing detection coverage. Local ESXi logging configuration and administrative practices are required to determine practical coverage.
Analytic 0562
Use of `esxcli network` commands (e.g., `esxcli network nic list`, `esxcli network ip interface ipv4 get`) via SSH or hostd to enumerate adapter and IP information.
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 | a78bdf44c5b2… |
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 AN0562Open 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.