AN0958: Analytic 0958
Container process uses mounted cloud credentials or token cache to authenticate without known orchestration.
Analyst context for executives and security teams
This analytic is about a container process using mounted cloud credentials or a token cache to authenticate when that use is not tied to known orchestration. For leaders, the practical issue is credential exposure and cloud access from containerized workloads: if teams cannot explain which containers should possess cloud authentication material, investigations and access reviews become much harder.
Executive priority
Prioritize this as a cloud and container governance question: can the organization prove which container workloads are allowed to use cloud credentials, and can SOC or IR teams quickly distinguish approved workload identity behavior from unexpected credential use? This matters for incident decision-making, least-privilege reviews, audit evidence, and limiting business disruption if container-hosted credentials are misused.
Technical view
For SOC, detection engineering, and IR teams, validate whether container telemetry can connect three facts: the process is running in a container, cloud credential material or token cache is mounted or accessed, and the authentication is not associated with known orchestration or approved workload identity patterns. Because ATT&CK provides no official detection logic and no relationship context for AN0958, local baselining is required to define what 'known orchestration' means in each environment.
Likely telemetry
- Container runtime process execution events
- Container image, pod/task, namespace, and workload metadata where available
- Volume mount and filesystem access evidence for credential or token cache paths
- Cloud authentication logs showing principal, source, workload, and token usage context
- Orchestrator or container platform inventory showing approved workload identity and credential-mount patterns
Detection direction
- Inventory expected container workloads that legitimately receive cloud credentials or token caches, then alert on deviations rather than raw credential file access alone.
- Correlate container process activity with cloud authentication events to confirm whether the same workload context is responsible for credential use.
- Tune for legitimate CI/CD, backup, monitoring, and platform-agent containers that may use mounted credentials by design.
- Look for blind spots where container runtime logs, mount metadata, or cloud authentication logs are not retained long enough for IR correlation.
- Because no MITRE detection text is supplied, treat AN0958 as an analytic objective, not a ready-to-deploy rule.
Mitigation priorities
- Reduce or eliminate static credential mounts in containers where managed workload identity or short-lived credentials are available.
- Maintain an approved inventory of container workloads permitted to access cloud authentication material.
- Apply least privilege to any cloud identities used by containerized workloads.
- Restrict credential and token cache mounts to only the containers that require them.
- Ensure container, host, and cloud authentication logs are retained and can be correlated during investigations.
Analyst notes and limits
AN0958 is a detection analytic for the Containers platform. The supplied object names a specific behavioral condition but does not include tactics, official detection logic, mitigations, or related ATT&CK techniques. The main defensive value is using it to test whether container identity usage is governed, observable, and explainable.
This take is limited to the supplied ATT&CK fields. There is no evidence here of active exploitation, actor attribution, business impact, or guaranteed detection coverage. Local architecture, orchestration model, credential handling, and logging quality determine whether this analytic is actionable.
Analytic 0958
Container process uses mounted cloud credentials or token cache to authenticate without known orchestration.
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 | ff33bd5a5395… |
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 AN0958Open 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.