AN1018: Analytic 1018
Execution of `ping`, `vmkping`, or `curl` from shell or through automation jobs/scripts to verify Internet egress.
Analyst context for executives and security teams
This analytic is about ESXi activity where someone or something runs `ping`, `vmkping`, or `curl` to confirm Internet egress. For leaders, the key issue is not the commands themselves; it is whether ESXi hosts are allowed, monitored, and governed when they reach outward. The same behavior can be normal troubleshooting or automation, but it can also expose a blind spot in virtualization-layer monitoring and outbound control.
Executive priority
Treat this as a control-validation item for virtualization resilience. Security leaders should ask whether ESXi hosts have approved reasons to access the Internet, whether exceptions are documented, and whether SOC and IR teams can distinguish sanctioned admin or automation activity from unexpected egress testing. This matters for incident decision-making because unmanaged outbound paths from infrastructure hosts can complicate containment and evidence collection.
Technical view
Validate visibility on ESXi for command execution involving `ping`, `vmkping`, and `curl`, especially when launched from an interactive shell or automation jobs/scripts. Because no official detection logic or tactic mapping is supplied, teams should baseline expected administrative and scripted use, then alert on unusual users, timing, destinations, or hosts. Network evidence should be correlated with ESXi-side activity to confirm whether the command actually attempted external connectivity.
Likely telemetry
- ESXi shell command execution records or command history where available
- ESXi authentication and administrator session logs
- Automation job or script execution records on or targeting ESXi hosts
- Network egress logs from firewalls, gateways, or other boundary controls
- DNS, ICMP, and HTTP/HTTPS metadata associated with ESXi-originated connectivity
Detection direction
- Inventory which ESXi hosts can produce command, shell, and automation telemetry; treat missing telemetry as a coverage gap.
- Create allowlists or baselines for approved administrators, automation accounts, maintenance windows, and known test destinations.
- Correlate `ping`, `vmkping`, or `curl` execution with outbound network events to reduce false positives from failed or local-only tests.
- Tune carefully for legitimate troubleshooting, health checks, and scripted validation jobs.
- Prioritize unexpected Internet-directed tests from production ESXi hosts, nonstandard accounts, unusual times, or hosts without approved egress requirements.
Mitigation priorities
- Define and enforce approved Internet egress paths for ESXi hosts; deny unnecessary outbound access where operationally feasible.
- Limit interactive shell access and automation privileges to authorized administrators and service accounts.
- Require documented change or maintenance context for ESXi egress testing.
- Ensure ESXi management, automation, and boundary network logs are retained for incident response and audit evidence.
- Review exceptions periodically so temporary troubleshooting access does not become permanent exposure.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic for ESXi and specifically names execution of `ping`, `vmkping`, or `curl` from shell or automation jobs/scripts to verify Internet egress. No relationships, tactic mapping, or official detection procedure were provided, so the take focuses on validation, telemetry coverage, and defensive decision value rather than a prescriptive detection rule.
This summary is limited to the official STIX fields and the single external ATT&CK reference supplied. It does not establish malicious intent, active exploitation, attribution, impact, or guaranteed detectability. Local ESXi configuration, logging depth, automation design, and network architecture are required to determine risk and coverage.
Analytic 1018
Execution of `ping`, `vmkping`, or `curl` from shell or through automation jobs/scripts to verify Internet egress.
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 | 357fe4101060… |
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 AN1018Open 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.