AN1602: Analytic 1602
ESXi shell or scheduled tasks initiating outbound HTTPS to known public services without inbound return or loggable response, used to fetch instructions.
Analyst context for executives and security teams
AN1602 highlights a narrow but important ESXi monitoring concern: ESXi shell activity or scheduled tasks making outbound HTTPS connections to known public services to fetch instructions. For leaders, the value is not the label of the analytic, but the control question it raises: can the organization see and govern unexpected internet egress from virtualization infrastructure? ESXi hosts often support critical business services, so unmanaged outbound communications from them can create incident-response and resilience blind spots.
Executive priority
Prioritize this as an infrastructure visibility and egress-control issue for VMware/ESXi environments. Security leaders should ask whether ESXi hosts are expected to reach public HTTPS services, whether exceptions are documented, and whether SOC and network teams can prove visibility through logs or network telemetry. This supports operational resilience, incident decision-making, and audit evidence around privileged infrastructure monitoring.
Technical view
Validate coverage on ESXi platforms for outbound HTTPS initiated by ESXi shell activity or scheduled tasks. Because no official detection logic is provided and no tactics or relationships are supplied, teams should treat this as a detection-validation prompt rather than a complete rule. Focus on correlating ESXi host activity with network egress to public services, especially cases where there is no clear inbound return path or loggable response. Establish a baseline of legitimate ESXi update, management, backup, monitoring, and support traffic before alerting broadly.
Likely telemetry
- ESXi shell command/activity logs where available
- ESXi scheduled task or cron-like execution evidence
- Host management and audit logs from ESXi/vCenter where available
- Firewall, proxy, or secure web gateway logs showing outbound HTTPS from ESXi hosts
- Network flow records for ESXi management and host interfaces
Detection direction
- Confirm whether ESXi hosts are included in network egress monitoring and whether their source addresses are reliably identified.
- Baseline approved outbound HTTPS destinations for ESXi hosts, including management, update, backup, monitoring, and support services.
- Tune for ESXi shell or scheduled-task context initiating HTTPS to public services when that behavior is not expected.
- Correlate host-side execution evidence with network-side outbound connections; either source alone may be incomplete.
- Account for false positives from legitimate vendor services or administrative automation that uses public HTTPS endpoints.
Mitigation priorities
- Reduce direct internet egress from ESXi hosts to documented business-required destinations only.
- Require outbound ESXi traffic to pass through monitored control points such as firewalls or proxies where feasible.
- Limit and audit ESXi shell access and scheduled task creation consistent with administrative need.
- Maintain an approved destination inventory for virtualization infrastructure and review exceptions periodically.
- Ensure incident response runbooks include ESXi host log collection, network-flow review, and validation of scheduled tasks or shell activity.
Analyst notes and limits
This object is a detection analytic for ESXi and describes outbound HTTPS from ESXi shell or scheduled tasks to known public services to fetch instructions. No official detection logic, tactics, or relationship context was supplied, so the strongest use is as a coverage-validation and hunting concept for virtualization infrastructure egress.
The supplied ATT&CK fields do not provide a detection query, data source list, related techniques, threat groups, software, campaigns, or mitigations. Local baselines are required to distinguish suspicious ESXi outbound HTTPS from legitimate administration, vendor, update, monitoring, backup, or support activity.
Analytic 1602
ESXi shell or scheduled tasks initiating outbound HTTPS to known public services without inbound return or loggable response, used to fetch instructions.
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 | 2ad136864654… |
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 AN1602Open 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.