AN0960: Analytic 0960
Use of instance metadata tokens across instances or misuse of short-lived tokens issued for different roles.
Analyst context for executives and security teams
This analytic concerns misuse of cloud instance metadata tokens in IaaS environments, especially tokens used across instances or short-lived tokens used outside the role they were issued for. For leaders, the practical issue is whether cloud identity controls and monitoring can distinguish legitimate workload credential use from token replay or role misuse before it becomes broader cloud access risk.
Executive priority
Prioritize this where IaaS workloads rely on instance metadata and temporary role credentials. The business decision value is validating that cloud identity, logging, and incident response processes can prove which instance, role, and token use patterns are legitimate. This supports resilience, access governance, and audit evidence for cloud control effectiveness, but local cloud architecture and logging availability will determine actual risk and coverage.
Technical view
SOC, cloud security, and IR teams should validate whether telemetry can correlate metadata-token issuance or use with the originating instance, assigned role, destination service activity, and timing. Detection logic should focus on tokens appearing to be used across instances or short-lived credentials being used in ways inconsistent with the role or workload context. Because no official detection text or relationships are supplied, teams should treat this as a detection validation requirement rather than a ready-made analytic.
Likely telemetry
- IaaS instance metadata service access logs where available
- Cloud identity and temporary credential usage logs
- Role assumption or instance profile activity records
- Cloud API activity tied to instance roles or workload identities
- Instance inventory, role-to-instance mappings, and workload ownership context
Detection direction
- Confirm that logs can tie temporary credential use back to a specific instance, role, time window, and cloud API action.
- Look for credential or token use that appears inconsistent with the issuing instance, expected role, or workload behavior.
- Tune detections against known automation, autoscaling, deployment, and maintenance activity to reduce false positives.
- Validate blind spots around ephemeral instances, incomplete cloud audit logging, short log retention, and lack of workload-to-role ownership data.
- Use this analytic as part of cloud identity monitoring rather than as a standalone alert, since no ATT&CK detection logic is provided.
Mitigation priorities
- Inventory IaaS workloads that use instance metadata and temporary role credentials.
- Enforce least-privilege role assignments for instances and workloads.
- Restrict and monitor access to instance metadata services according to cloud-provider capabilities and organizational policy.
- Maintain authoritative mappings of instances, roles, workloads, and owners for investigation and tuning.
- Ensure cloud audit logs and identity logs are retained long enough to support incident response and compliance evidence.
Analyst notes and limits
The supplied ATT&CK object is an analytic for IaaS platforms and describes token use across instances or misuse of short-lived tokens issued for different roles. There are no tactics, technique relationships, or official detection details supplied, so the take focuses on defensive validation, telemetry requirements, and cloud identity context.
This summary uses only the supplied STIX fields, external reference, and relationship context. It does not establish active exploitation, adversary attribution, specific affected cloud providers, or guaranteed detection coverage. Local architecture, logging configuration, and identity design are required to assess exposure and build production detections.
Analytic 0960
Use of instance metadata tokens across instances or misuse of short-lived tokens issued for different roles.
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 | 240b19ade958… |
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 AN0960Open 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.