AN0930: Analytic 0930
ESXi shell or scripts produce long, high-entropy tokens (non-standard alphabets) in shell.log/hostd, followed by outbound flows (NSX/Zeek) with asymmetric ratios or protocol mismatches to non-management endpoints.
Analyst context for executives and security teams
This analytic is about spotting suspicious ESXi activity where shell commands or scripts generate unusual long, high-entropy tokens and are followed by abnormal outbound network flows. For leaders, the practical issue is whether virtualization infrastructure has enough logging and network visibility to detect suspicious activity before it affects business-critical workloads.
Executive priority
Treat this as a control-validation item for virtualization resilience. ESXi hosts often support critical systems, but their logs and east-west or outbound network flows may not be monitored as thoroughly as endpoints. Security leaders should ask whether ESXi shell.log, hostd logs, and relevant network telemetry are collected, retained, and reviewed, and whether outbound communication from hypervisor management environments is restricted to expected destinations.
Technical view
Validate coverage on ESXi platforms for the pattern described by MITRE: long, high-entropy, non-standard alphabet tokens appearing in ESXi shell.log or hostd activity, followed by outbound flows observed in NSX or Zeek showing asymmetric traffic ratios or protocol mismatches to non-management endpoints. Because no official detection logic is provided, SOC and detection engineering teams should build and tune locally using known-good ESXi administrative scripts, backup tooling, monitoring agents, and management destinations as baselines.
Likely telemetry
- ESXi shell.log entries
- ESXi hostd logs
- NSX flow telemetry
- Zeek network logs
- Outbound connection metadata from ESXi management networks
Detection direction
- Confirm ESXi shell.log and hostd logs are centrally collected with sufficient retention and host attribution.
- Develop high-entropy token detection carefully to avoid flagging legitimate keys, session identifiers, backup tooling output, or administrative automation.
- Correlate suspicious token generation with outbound network behavior rather than relying on string entropy alone.
- Baseline approved ESXi management destinations and alert on outbound flows to non-management endpoints when paired with suspicious host logs.
- Review asymmetric traffic ratios and protocol mismatches in NSX or Zeek telemetry, but tune for legitimate replication, backup, monitoring, and update patterns.
Mitigation priorities
- Prioritize centralized logging for ESXi shell.log and hostd before relying on this analytic.
- Restrict ESXi outbound network access to approved management, monitoring, backup, and update destinations where operationally feasible.
- Maintain an inventory of ESXi hosts, management networks, and authorized administrative automation.
- Review ESXi shell access governance and ensure administrative activity is attributable.
- Use detection testing to confirm that log and flow correlation works across the SOC pipeline.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic for ESXi and provides a behavioral description but no official detection logic, tactics, or relationship context. The strongest use is as a validation prompt for hypervisor logging and outbound network monitoring rather than as a complete rule.
No relationships, tactics, procedure examples, mitigations, or official detection implementation were supplied. Local baselines are required to distinguish suspicious high-entropy strings and abnormal outbound flows from legitimate ESXi administration, backup, monitoring, or automation activity.
Analytic 0930
ESXi shell or scripts produce long, high-entropy tokens (non-standard alphabets) in shell.log/hostd, followed by outbound flows (NSX/Zeek) with asymmetric ratios or protocol mismatches 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 | 05c7188b0bb2… |
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 AN0930Open 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.