AN0640: Analytic 0640
CLI-based or API-based network call from the hypervisor to external staging host, shortly followed by a connection to a second external IP by a spawned process or scheduled task.
Analyst context for executives and security teams
AN0640 matters because it focuses on suspicious outbound activity from an ESXi hypervisor: a command-line or API-driven network call to an external staging host, followed shortly by another external connection from a spawned process or scheduled task. For leaders, the practical issue is not just malware detection; it is whether hypervisor management, network egress, and logging are strong enough to show when a critical virtualization host is reaching out to unexpected internet infrastructure.
Executive priority
Treat this as a resilience and visibility validation item for ESXi environments. Hypervisors sit underneath many business services, so unexplained outbound connections from them should be investigated quickly. Security leaders should ask whether ESXi hosts are allowed to make direct internet connections, whether exceptions are documented, and whether SOC and IR teams have evidence to reconstruct process, task, API, and network activity from the hypervisor layer.
Technical view
For SOC and detection teams, validate whether ESXi telemetry can correlate three elements: an initial CLI-based or API-based outbound network call from the hypervisor, a short time window, and a second outbound connection to a different external IP by a spawned process or scheduled task. Because ATT&CK provides no separate detection logic, tuning should be environment-specific: baseline legitimate ESXi management, update, backup, monitoring, and automation traffic, then alert on unusual external destinations, new scheduled tasks, unexpected child processes, or network activity inconsistent with approved administration paths.
Likely telemetry
- ESXi host command-line or shell execution records where available
- ESXi API or management-plane activity logs
- Hypervisor outbound network connection logs
- Firewall, proxy, or network flow records showing ESXi-to-external IP traffic
- Scheduled task creation or execution records on ESXi
Detection direction
- Confirm whether ESXi hosts are included in network egress monitoring and whether their traffic can be distinguished from guest VM traffic.
- Correlate outbound connections from the hypervisor with preceding CLI or API activity and subsequent spawned process or scheduled task behavior.
- Prioritize alerts where the first and second external destinations are not approved management, update, backup, or monitoring endpoints.
- Tune for known administrative automation to reduce false positives, especially API-driven maintenance tasks.
- Look for blind spots where ESXi shell, API, scheduled task, or process telemetry is absent, short-retained, or not forwarded to the SOC.
Mitigation priorities
- Restrict direct internet egress from ESXi hosts to documented and necessary destinations.
- Harden and monitor ESXi management access, including API usage and administrative shell access.
- Maintain an approved baseline of hypervisor management, update, backup, and monitoring traffic.
- Ensure firewall, network flow, and hypervisor logs are retained and available for incident response.
- Review scheduled tasks and automation on ESXi hosts for necessity, ownership, and change-control evidence.
Analyst notes and limits
This analytic is specific to the ESXi platform and describes a behavioral sequence involving outbound hypervisor network activity and a follow-on connection from a spawned process or scheduled task. No ATT&CK tactics, related techniques, relationships, aliases, or separate official detection text were supplied, so the take is framed as a visibility and validation guide rather than a complete detection rule.
The supplied object is sparse: it provides a description but no official detection procedure, relationship context, threat group/software linkage, or tactic mapping. Local ESXi architecture, approved egress paths, logging configuration, and administrative automation are required to determine severity and reduce false positives.
Analytic 0640
CLI-based or API-based network call from the hypervisor to external staging host, shortly followed by a connection to a second external IP by a spawned process or scheduled task.
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 | c12e90d0d50a… |
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 AN0640Open 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.