AN1104: Analytic 1104
Adversary uses 'esxcli software vib list' to enumerate installed VIBs, drivers, and modules.
Analyst context for executives and security teams
This analytic highlights a VMware ESXi host enumeration behavior: use of `esxcli software vib list` to list installed VIBs, drivers, and modules. For leaders, the value is not that the command is inherently malicious, but that visibility into ESXi administrative activity can affect incident response readiness, change validation, and resilience of virtualization infrastructure that may host critical workloads.
Executive priority
Treat this as a coverage validation item for virtualization security operations. Security and infrastructure leaders should ask whether ESXi command activity is logged, retained, reviewed, and correlated with approved administration. Because the supplied ATT&CK object provides no detection logic or relationship context, priority should be based on local dependence on ESXi for business-critical services and the organization’s need to prove monitoring and change-control evidence for hypervisor administration.
Technical view
SOC, IR, and detection engineering teams should validate whether they can observe execution of `esxcli software vib list` on ESXi systems and distinguish expected administrator inventory or troubleshooting from unusual host enumeration. Since no official detection is provided, teams should build local context around authorized users, maintenance windows, source access paths, and host criticality rather than treating the command alone as conclusive malicious activity.
Likely telemetry
- ESXi shell or command execution logs showing `esxcli` activity
- ESXi host management/authentication logs identifying user, time, and access source
- Administrative session records for SSH, console, or management access to ESXi hosts
- Change-management or maintenance-window records for expected VIB, driver, or module inventory activity
- Centralized SIEM or log pipeline records confirming ESXi logs are collected and retained
Detection direction
- Confirm that ESXi administrative command activity is actually collected; many environments have weaker telemetry on hypervisors than on guest workloads.
- Alerting should be contextual: `esxcli software vib list` may be legitimate during patching, troubleshooting, audits, or inventory collection.
- Prioritize anomalies such as execution outside maintenance windows, by unexpected users, from unusual access paths, or on highly critical ESXi hosts.
- Correlate command activity with authentication events and recent administrative changes to reduce false positives.
- Because ATT&CK supplies no detection text for this analytic, local baselining and operational context are required before production alerting.
Mitigation priorities
- Restrict ESXi administrative access to authorized personnel and approved management paths.
- Ensure ESXi logging is enabled, centralized, time-synchronized, and retained for investigation and audit needs.
- Maintain clear change-control records for VIB, driver, and module inventory or maintenance activity.
- Review privileged access practices for hypervisor administration, including account ownership and session accountability.
- Test incident response procedures for collecting ESXi host evidence without disrupting critical virtualized workloads.
Analyst notes and limits
This object is a detection analytic for ESXi and describes enumeration of installed VIBs, drivers, and modules using `esxcli software vib list`. No tactics, relationships, labels, aliases, or official detection logic were supplied. The most useful defensive takeaway is to validate monitoring and governance around ESXi administrative command visibility.
The source object does not provide detection logic, associated techniques, adversary relationships, impact claims, or evidence of active exploitation. Any severity, alert thresholds, or assumptions about maliciousness must be determined from local ESXi architecture, administrative practices, and telemetry quality.
Analytic 1104
Adversary uses 'esxcli software vib list' to enumerate installed VIBs, drivers, and modules.
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 | c3b01c376064… |
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 AN1104Open 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.