AN0161: Analytic 0161
Detection of a process or script that accesses a common web service to retrieve content containing obfuscated indicators of a secondary C2 server (dead drop resolver behavior).
Analyst context for executives and security teams
This analytic is about spotting ESXi-hosted activity where a process or script reaches out to a common web service to retrieve content that hides indicators for a secondary command-and-control location. For leaders, the practical issue is that ordinary-looking web access can be used as a lookup mechanism for follow-on infrastructure, making perimeter allowlists and simple domain reputation less reliable.
Executive priority
Prioritize this as a resilience and incident-readiness question for ESXi environments: can the organization explain and evidence outbound web access from ESXi systems, and can the SOC distinguish expected management/update behavior from scripts or processes retrieving unusual content from common web services? The business value is in reducing blind spots around virtualization infrastructure, where compromise or misuse can affect multiple workloads even when the observed network traffic appears benign.
Technical view
Validate whether ESXi telemetry can show process or script execution together with outbound network connections to common web services. Because the ATT&CK object provides no formal detection logic, teams should treat AN0161 as a detection objective: identify ESXi processes or scripts that access public web content and then parse, decode, or consume returned content that may contain obfuscated indicators for secondary C2. Focus on correlating host activity, network destination, request metadata, and subsequent outbound connections rather than relying on a single domain or URL indicator.
Likely telemetry
- ESXi host process or script execution records, where available
- Outbound network connection logs from ESXi hosts
- Proxy, firewall, DNS, and web gateway logs showing ESXi-originated requests
- HTTP/S request metadata such as destination, URL path, user agent, timing, and response size where available
- Subsequent outbound connection attempts following access to common web services
Detection direction
- Inventory which ESXi systems are expected to initiate outbound web requests and baseline their normal destinations and processes.
- Correlate ESXi-originated access to common web services with process/script context and any follow-on network connections to new or unusual destinations.
- Tune carefully for legitimate automation, monitoring, backup, update, and administrative scripts that may retrieve public web content.
- Look for weak coverage where ESXi hosts bypass proxy logging, lack process visibility, or share egress paths that obscure the originating host.
- Avoid over-reliance on domain reputation because the behavior described uses common web services as an intermediary.
Mitigation priorities
- Restrict ESXi outbound internet access to documented business requirements and route it through monitored egress controls where feasible.
- Maintain an approved inventory of ESXi management, monitoring, backup, and update workflows that require web access.
- Ensure logging from ESXi hosts, network egress points, DNS, proxy, and firewalls is retained and correlated for incident response.
- Review administrative scripting and automation on ESXi systems for unnecessary external content retrieval.
- Use incident response playbooks that treat unexplained ESXi web retrieval followed by new outbound connections as a triage priority.
Analyst notes and limits
AN0161 is a detection analytic for ESXi and describes dead drop resolver behavior: retrieving content from a common web service that contains obfuscated indicators for a secondary C2 server. No ATT&CK tactic, relationship context, or official detection logic was supplied, so this take frames validation around observable telemetry and control gaps rather than a specific rule.
The source fields do not provide a query, data components, related techniques, procedures, adversary attribution, or confirmed exploitation context. Local ESXi architecture, egress design, and logging capability are required to determine whether this analytic can be implemented effectively.
Analytic 0161
Detection of a process or script that accesses a common web service to retrieve content containing obfuscated indicators of a secondary C2 server (dead drop resolver behavior).
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 | eeb920e4e2f2… |
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 AN0161Open 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.