AN1158: Analytic 1158
Access to container image layers or mounted secrets (e.g., Docker secrets) by processes not tied to entrypoint or orchestration context.
Analyst context for executives and security teams
This analytic matters because it focuses on unexpected access to container image layers or mounted secrets, such as Docker secrets, by processes that do not appear to belong to the normal container entrypoint or orchestration context. For leaders, the decision value is whether container platforms can prove who or what accessed sensitive runtime material, especially secrets that may support service availability, lateral movement prevention, and incident containment.
Executive priority
Prioritize this as a container security and incident-readiness validation item. The key business question is whether the organization can distinguish normal workload behavior from unauthorized or abnormal access to container layers and mounted secrets. This affects resilience and audit evidence because weak visibility into secret access can delay containment, complicate root-cause analysis, and undermine confidence in cloud-native controls.
Technical view
For SOC, detection engineering, and IR teams, validate whether telemetry can identify process-level access to container image layers and mounted secrets and correlate that activity to the expected container entrypoint or orchestration context. Because ATT&CK provides no detection logic for AN1158 and no tactic mapping in the supplied object, teams should treat this as a coverage assessment pattern rather than a ready-made rule. Baseline expected processes per container image, service, and orchestrated workload, then investigate access by processes that are not part of that expected runtime model.
Likely telemetry
- Container runtime process telemetry
- File access events for mounted secrets or secret paths
- Container image layer access or filesystem access logs where available
- Orchestration metadata linking containers, workloads, entrypoints, and expected processes
- Host-level process and file monitoring for containerized workloads
Detection direction
- Confirm whether process identity, container identity, image identity, and orchestration context are collected together; without that correlation, this analytic will be difficult to operationalize.
- Build workload-specific baselines for expected entrypoint and child-process behavior before alerting on access to mounted secrets or image layers.
- Tune for legitimate administrative, backup, scanning, or observability processes that may read container files or mounted paths to reduce false positives.
- Investigate events where secret or image-layer access is performed by an unexpected process, a process outside the normal entrypoint lineage, or a process lacking clear orchestration context.
- Document blind spots where container runtime, host file access, or orchestration metadata is not retained long enough for incident response.
Mitigation priorities
- Inventory where containers use mounted secrets and which workloads are expected to access them.
- Limit secret exposure to only the containers and processes that require it, using least-privilege design where supported by the container platform.
- Harden container runtime and orchestration configurations to preserve clear workload identity and expected entrypoint behavior.
- Ensure logging and retention support process-to-container-to-orchestration correlation for investigations.
- Use incident response exercises to test whether teams can confirm whether secret access was expected or abnormal.
Analyst notes and limits
The supplied object is a detection analytic for the Containers platform with an official description but no official detection text, no tactics, and no relationship context. The main value is to guide validation of container secret and filesystem access monitoring rather than to deploy a specific rule.
This take is limited to the supplied ATT&CK fields and external reference. It does not assert active exploitation, attribution, impact, or existing detection coverage. Local container architecture, runtime, orchestration platform, logging configuration, and secret-management design are required to determine practical coverage and priority.
Analytic 1158
Access to container image layers or mounted secrets (e.g., Docker secrets) by processes not tied to entrypoint or orchestration context.
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 | e5d08e323e4f… |
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 AN1158Open 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.