AN1424: Analytic 1424
Token retrieval from instance metadata endpoints such as AWS IMDS or Azure IMDS, followed by API usage using the obtained token from non-standard applications.
Analyst context for executives and security teams
This analytic concerns a cloud identity risk: tokens retrieved from IaaS instance metadata services, such as AWS IMDS or Azure IMDS, and then used by non-standard applications. For leaders, the material issue is whether cloud workloads can unintentionally become a path to API access if metadata-issued credentials are exposed or misused. The business value is validating that cloud telemetry, workload identity controls, and SOC processes can distinguish expected instance role usage from unusual application-driven token use.
Executive priority
Prioritize this as a cloud security and incident readiness question: do teams know which workloads are allowed to obtain and use metadata-derived tokens, and can they produce evidence when token use is abnormal? This affects access governance, cloud control assurance, incident scoping, and auditability for IaaS environments. Because ATT&CK provides no detection logic for this analytic, leaders should ask whether current cloud logging and workload inventory are sufficient to prove coverage rather than assume it exists.
Technical view
For SOC, detection engineering, and IR teams, validate visibility around IaaS instance metadata token retrieval and subsequent API activity using the obtained identity. Focus on identifying API usage patterns that originate from non-standard applications or unexpected workload contexts. Since no tactic, relationship context, or official detection logic is supplied, implementation should be environment-specific: baseline expected applications, instance roles, service principals, metadata access patterns, and normal cloud API call behavior before alerting on deviations.
Likely telemetry
- Cloud control plane/API audit logs for token-derived identity activity
- Instance or workload logs showing applications/processes that access metadata endpoints
- Network telemetry for requests from workloads to instance metadata services where available
- Cloud asset inventory mapping instances, roles, applications, and expected API permissions
- Identity and access logs showing assumed role or managed identity usage patterns
Detection direction
- Validate that cloud audit logging is enabled and retained for relevant IaaS accounts/subscriptions/projects.
- Build baselines of which applications on each workload are expected to request metadata tokens and which APIs those identities normally call.
- Investigate mismatches between the workload identity and the application or process using it, especially where API calls come from non-standard applications.
- Tune carefully for legitimate agents, monitoring tools, automation, and cloud-native services that may normally use metadata credentials.
- Document blind spots where endpoint/process telemetry is unavailable, because cloud API logs alone may show identity use without proving which local application retrieved the token.
Mitigation priorities
- Inventory IaaS workloads, attached identities/roles, and expected application use of metadata-issued credentials.
- Apply least-privilege permissions to instance roles or managed identities so token misuse has limited business impact.
- Restrict and monitor metadata service access where platform and architecture allow.
- Ensure cloud audit logging, workload logging, and incident response playbooks can support investigation of metadata token misuse.
- Use findings to strengthen cloud identity governance and compliance evidence around workload access controls.
Analyst notes and limits
The object is an ATT&CK detection analytic for IaaS environments. The supplied description specifically references AWS IMDS and Azure IMDS, token retrieval, and subsequent API usage from non-standard applications. No relationships, tactics, labels, or official detection procedure were supplied, so this take emphasizes validation questions, telemetry requirements, and conservative detection engineering direction.
Official detection content is not provided, and no relationship context is supplied. This summary does not assert active exploitation, adversary attribution, impact, or guaranteed detection coverage. Local cloud architecture, logging configuration, workload inventory, and identity design are required to turn this analytic into reliable detections or control evidence.
Analytic 1424
Token retrieval from instance metadata endpoints such as AWS IMDS or Azure IMDS, followed by API usage using the obtained token from non-standard applications.
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 | d3db73b7aa06… |
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 AN1424Open 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.