AN0348: Analytic 0348
ESXi shell (BusyBox) or VMware utilities (openssl, python if present) used to Base64/hex encode data from datastore or config files → followed by abnormal egress from the host (NSX/flow logs) with asymmetric bytes_out or HTTPS posts to non-management endpoints.
Analyst context for executives and security teams
This analytic matters because it focuses on possible data preparation and outbound transfer activity directly from an ESXi host. For a security leader, the key issue is not just command usage; it is whether virtualization infrastructure has enough monitoring to show when datastore or configuration data is being encoded and then leaving the host through abnormal network paths.
Executive priority
Prioritize this as a virtualization and business-continuity visibility question. ESXi hosts often support critical workloads, so leaders should ask whether management-plane activity, host-level utility use, datastore access, and egress flow records are collected and reviewable during an incident. The control decision is whether ESXi environments are treated as monitored infrastructure assets, not just as underlying platforms.
Technical view
SOC and IR teams should validate visibility for ESXi shell or BusyBox activity and VMware utility execution involving encoding behavior, especially against datastore or configuration files. Because the ATT&CK object specifies abnormal egress from the host, detections should correlate suspicious local activity with NSX or network flow evidence such as asymmetric bytes_out or HTTPS posts to non-management endpoints. No official detection logic or tactic mapping is provided, so local baselining is required.
Likely telemetry
- ESXi shell or BusyBox command activity where available
- VMware utility execution telemetry, including openssl or python if present
- Access to datastore or ESXi configuration files
- NSX logs or equivalent network flow records from ESXi hosts
- Outbound connection metadata, including destination, protocol, bytes_out, and management versus non-management endpoint classification
Detection direction
- Validate whether ESXi command activity is logged with enough detail to identify encoding utilities and target file paths.
- Correlate host-side encoding activity with outbound network flows from the same ESXi host.
- Baseline expected ESXi management destinations and tune for HTTPS posts or high bytes_out to non-management endpoints.
- Review false positives from administrative maintenance, backups, diagnostics, or scripted support activity that may legitimately read configuration data or move files.
- Identify blind spots where ESXi hosts are excluded from endpoint telemetry, centralized logging, or egress monitoring.
Mitigation priorities
- Restrict and monitor ESXi shell access according to operational need.
- Limit outbound network paths from ESXi hosts to approved management and infrastructure destinations.
- Ensure ESXi, NSX, and network flow logs are retained and accessible for incident response.
- Separate administrative, backup, and management traffic patterns so abnormal egress is easier to identify.
- Document expected datastore and configuration access workflows to support audit evidence and investigation triage.
Analyst notes and limits
This is a detection analytic for ESXi environments, not a full technique description. Its value is in driving validation of virtualization-host telemetry and egress monitoring, especially where datastore or configuration file access could precede unusual outbound transfer behavior.
The supplied ATT&CK object provides a description but no official detection text, tactics, relationships, procedure examples, or mitigations. Any production detection must be adapted to the organization’s ESXi logging capability, network architecture, and approved management workflows.
Analytic 0348
ESXi shell (BusyBox) or VMware utilities (openssl, python if present) used to Base64/hex encode data from datastore or config files → followed by abnormal egress from the host (NSX/flow logs) with asymmetric bytes_out or HTTPS posts to non-management endpoints.
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 | ef6d6a300286… |
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 AN0348Open 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.