AN0001: Analytic 0001
Detects access attempts to cloud instance metadata endpoints (e.g., 169.254.169.254) from virtual machines or containerized workloads. This includes both direct access and SSRF exploitation patterns.
Analyst context for executives and security teams
AN0001 focuses on spotting workloads in IaaS environments that try to reach cloud instance metadata endpoints such as 169.254.169.254, including access patterns that may come from server-side request forgery. For leaders, this is important because metadata endpoint access can be a key boundary between an application workload and the surrounding cloud environment; if monitoring is absent, suspicious workload behavior may be missed until later in an incident.
Executive priority
Prioritize this analytic where virtual machines or containerized workloads run in IaaS and where cloud incident response depends on proving whether workloads attempted metadata access. Security leaders should ask whether teams can see direct workload-to-metadata traffic, whether application-layer logs could reveal SSRF-style requests, and whether this evidence is retained well enough for investigation, compliance support, and cloud security assurance.
Technical view
Validate coverage for access attempts from virtual machines and containerized workloads to instance metadata endpoints, especially 169.254.169.254. Because ATT&CK provides no official detection logic for this analytic, SOC and detection engineering teams should define local baselines for expected metadata access by workload type, then alert on unusual sources, unexpected containers, abnormal request volume, or application request patterns consistent with SSRF reaching metadata endpoints. Tune carefully because some legitimate cloud agents, bootstrap processes, or workload identity mechanisms may access metadata services.
Likely telemetry
- Workload network telemetry showing connections from VMs or containers to instance metadata endpoints such as 169.254.169.254
- Host or container runtime logs that identify the process, container, pod, or workload initiating metadata access
- Cloud or IaaS network flow records where available and where link-local metadata traffic is observable
- Application, reverse proxy, web server, or API gateway logs that may show SSRF-style requests targeting metadata endpoints
- EDR or workload security telemetry that can correlate process execution with outbound metadata endpoint connections
Detection direction
- Confirm whether the environment actually records traffic to link-local metadata endpoints; some network logging sources may not capture this path.
- Baseline legitimate metadata access by workload role, image, container, and lifecycle phase to reduce false positives from expected cloud agents or initialization routines.
- Correlate metadata endpoint attempts with application-layer inputs when investigating possible SSRF patterns.
- Prioritize alerts where metadata access originates from unexpected containers, internet-facing applications, recently changed workloads, or processes with no normal reason to query metadata.
- Document detection gaps caused by missing container identity, lack of process attribution, or insufficient retention.
Mitigation priorities
- Inventory IaaS workloads and identify which VMs or containers are expected to access metadata endpoints.
- Restrict or harden metadata access where platform controls and workload design allow, especially for internet-facing applications and containerized services.
- Improve workload identity, least privilege, and segmentation practices so metadata access does not create unnecessary cloud control-plane exposure.
- Ensure incident response playbooks include steps to review metadata endpoint access attempts and related application logs.
- Use detection validation exercises to prove that direct metadata access and SSRF-like patterns generate usable alerts and investigation evidence.
Analyst notes and limits
This is a detection analytic object, not a technique object. The supplied ATT&CK fields specify IaaS as the platform and describe detection of direct and SSRF-related access attempts to cloud instance metadata endpoints. No tactics, relationships, or official detection logic were supplied, so implementation must be based on local cloud architecture and telemetry availability.
No relationship context, tactic mapping, or official detection query was provided. This take does not establish active exploitation, adversary attribution, customer exposure, or guaranteed detection coverage. Local validation is required to determine which telemetry sources can observe metadata endpoint traffic in the specific IaaS environment.
Analytic 0001
Detects access attempts to cloud instance metadata endpoints (e.g., 169.254.169.254) from virtual machines or containerized workloads. This includes both direct access and SSRF exploitation patterns.
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 | 30fbfab71cff… |
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 AN0001Open 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.