DET0001: Detect Access to Cloud Instance Metadata API (IaaS)
This detection strategy matters because access to a cloud instance metadata API can expose temporary credentials and other sensitive instance data in IaaS...
Analyst context for executives and security teams
This detection strategy matters because access to a cloud instance metadata API can expose temporary credentials and other sensitive instance data in IaaS environments. For leaders, the practical issue is whether cloud workloads can silently become a source of credential compromise, enabling follow-on access that may affect business continuity, cloud governance, and incident response scope.
Executive priority
Prioritize this as a cloud security and identity risk validation item for IaaS workloads. Executives and risk owners should ask whether teams can prove when instance metadata is accessed, whether exposed credentials would be detected or constrained, and whether incident responders can quickly determine which workloads, identities, and permissions were involved. This also supports audit and compliance evidence around cloud credential handling and monitoring, but the supplied ATT&CK object does not provide a specific detection implementation.
Technical view
The detection strategy is associated with ATT&CK technique T1552.005, Cloud Instance Metadata API, under credential access for IaaS. SOC, detection engineering, and IR teams should validate visibility around metadata service access from cloud instances, especially where access may reveal credentials, UserData scripts, instance identity, security group information, or other metadata. Because the official detection field is not provided and the detection strategy itself lists no platforms or tactics, engineering should use the relationship to T1552.005 as the technical anchor and test against local IaaS telemetry and workload architecture.
Likely telemetry
- Cloud workload network telemetry showing requests to instance metadata service endpoints where available
- Host or workload logs that can show local processes or services initiating metadata access
- Cloud control-plane and identity logs showing subsequent use of credentials associated with an instance role or workload identity
- Instance configuration and metadata-related settings relevant to credential exposure risk
- Incident response evidence tying metadata access to a specific instance, workload, identity, and time window
Detection direction
- Confirm whether metadata API access is observable in the organization’s IaaS environments; this is a common blind spot if only cloud control-plane logs are collected.
- Baseline expected metadata access by legitimate agents, bootstrapping processes, and applications to reduce false positives.
- Correlate unusual metadata access with later credential use, identity activity, or access to sensitive cloud resources.
- Validate alert enrichment includes instance identity, role or permissions context, security group context, and workload ownership so responders can scope quickly.
- Document limitations explicitly because the ATT&CK detection strategy provides no official detection logic in the supplied fields.
Mitigation priorities
- Inventory IaaS workloads that rely on instance metadata and identify where sensitive credentials or scripts may be exposed through metadata.
- Apply least privilege to instance roles or workload identities so metadata-accessible credentials have constrained impact.
- Reduce unnecessary metadata exposure and harden workload configurations according to the relevant cloud provider’s supported controls.
- Ensure cloud identity, workload, and network telemetry are retained long enough to support credential-access investigations.
- Prepare IR playbooks for suspected metadata credential access, including credential rotation, workload isolation, and review of subsequent cloud API activity.
Analyst notes and limits
The business value is in validating whether cloud credential-access behavior can be seen and scoped, not in assuming that metadata access is always malicious. Legitimate software may access metadata during normal operation, so local baselines and workload ownership context are essential.
The supplied detection strategy has no official description, no official detection text, and no directly specified platforms or tactics. The only technical context supplied is its relationship to T1552.005, Cloud Instance Metadata API, which is credential access on IaaS. Recommendations are therefore conservative and must be adapted to the organization’s actual cloud providers, workloads, logging, and identity model.
Detect Access to Cloud Instance Metadata API (IaaS)
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1552.005 | Cloud Instance Metadata API Sub-technique | This object detects Cloud Instance Metadata API. |
All related ATT&CK context
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 | 2b2228e89cb6… |
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 DET0001Open 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.