AN0860: Analytic 0860
Access to local credential/config files (e.g., ~/.aws/credentials) followed by metadata API calls or cloud role assumptions.
Analyst context for executives and security teams
This analytic points to a cloud identity risk pattern: someone or something accesses local cloud credential/configuration files and then uses cloud instance metadata or role-assumption paths. For leaders, the significance is not the file access alone; it is the possibility that locally stored credentials or instance-linked roles become a bridge into IaaS control-plane access.
Executive priority
Prioritize this as a cloud security and incident-response readiness question: can the organization prove when local cloud credential files are accessed, and can it correlate that activity with metadata API use or cloud role assumptions? The business value is in reducing uncertainty during cloud incidents, supporting audit evidence for credential handling, and validating whether IAM design limits damage if local credentials or instance roles are misused.
Technical view
For SOC and detection engineering teams, validate whether IaaS workloads generate enough endpoint, host, and cloud control-plane telemetry to connect three events: access to local credential/config files such as AWS credential paths, subsequent metadata API activity, and cloud role assumption events. Because ATT&CK provides no official detection logic for this analytic, teams should treat it as a correlation requirement rather than a ready-made rule. Tune for legitimate automation, SDK behavior, backup/indexing tools, and administrative scripts that may read credential files or assume roles during normal operations.
Likely telemetry
- Endpoint or host file access telemetry for local cloud credential/configuration files
- Process execution context associated with credential file access
- Network telemetry showing calls to cloud instance metadata services where available
- Cloud control-plane audit logs for role assumption activity
- IaaS workload identity and instance metadata configuration records
Detection direction
- Confirm collection exists on IaaS workloads, not only in central cloud audit logs.
- Correlate credential/config file access with metadata API calls or role assumption activity within a defensible time window.
- Baseline approved automation and administrative tools that legitimately read credential files or assume roles to reduce false positives.
- Look for unusual principals, hosts, processes, or timing rather than treating every credential-file read as malicious.
- Validate whether metadata API access is observable in the local environment; many deployments have blind spots at the host network layer.
Mitigation priorities
- Reduce reliance on long-lived local cloud credentials where operationally possible.
- Harden IAM role design using least privilege and scoped role assumption paths.
- Review IaaS workload metadata service exposure and configuration according to cloud-provider guidance.
- Limit access to local credential/configuration files to required users and processes.
- Ensure incident response playbooks include credential rotation, role session review, and cloud audit log preservation.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic for IaaS environments. It describes a behavioral sequence involving local credential/config file access followed by metadata API calls or cloud role assumptions. No tactic, relationship context, or official detection procedure was supplied, so the practical value is in guiding telemetry validation and correlation design rather than asserting a specific ATT&CK technique mapping or detection outcome.
This take is limited to the official fields provided. It does not claim active exploitation, attribution, impact, or guaranteed detection. Local architecture, cloud provider, logging configuration, endpoint coverage, IAM design, and approved automation must be reviewed before assigning severity or building production detections.
Analytic 0860
Access to local credential/config files (e.g., ~/.aws/credentials) followed by metadata API calls or cloud role assumptions.
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 | 4028d210c47e… |
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 AN0860Open 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.