AN0859: Analytic 0859
Container processes accessing mounted secrets or configuration paths (e.g., /run/secrets, /mnt/config) followed by network access or credential use.
Analyst context for executives and security teams
This analytic is about spotting a container process that reads mounted secrets or configuration paths and then makes network connections or uses credentials. For leaders, the practical risk is that sensitive runtime material inside containers can become a pivot point for unauthorized access if monitoring only watches the host or perimeter and not container-level behavior.
Executive priority
Prioritize this as a container security and incident-readiness validation item. Ask whether teams can prove which container processes accessed mounted secrets or configuration paths, what network activity followed, and whether any credential use can be tied back to that container context. This matters for operational resilience, audit evidence, and scoping incidents involving containerized workloads.
Technical view
For SOC, detection engineering, and IR teams, validate visibility across container process execution, file access to paths such as /run/secrets and /mnt/config, subsequent network access, and credential-use events. Because ATT&CK provides no official detection logic or tactic mapping for this analytic, implementation should be treated as a local correlation use case: process accesses sensitive mounted paths, then initiates network activity or credential use within a meaningful time window. Tune against expected application behavior that legitimately reads mounted secrets at startup.
Likely telemetry
- Container process execution telemetry
- File access events for mounted secret or configuration paths
- Container-to-network connection or egress telemetry
- Credential or authentication-use logs where available
- Container metadata needed to map process activity to image, workload, namespace, host, or service owner
Detection direction
- Confirm telemetry includes container context, not only host-level process or network events.
- Correlate access to mounted secrets/configuration paths with later network access or credential use.
- Baseline legitimate secret/configuration reads, especially application startup behavior, to reduce false positives.
- Prioritize unusual timing, unexpected processes, unexpected destinations, or credential use inconsistent with the workload role.
- Document blind spots where file access, container metadata, or credential-use telemetry is unavailable.
Mitigation priorities
- Limit which containers receive mounted secrets or configuration files to the minimum required.
- Restrict workload permissions and credential scope so exposed runtime material has limited downstream value.
- Control and monitor container egress paths appropriate to workload purpose.
- Ensure incident response playbooks can identify affected containers, accessed paths, related network activity, and potentially used credentials.
- Maintain evidence showing container secret access and egress monitoring for compliance and readiness reviews.
Analyst notes and limits
This is a detection analytic object, not a technique description. The strongest decision value is using it to test whether container security monitoring can connect sensitive file access to follow-on network or credential activity. Relationship context was not supplied, so no associated technique, tactic, campaign, or actor context is asserted.
The official object provides a short behavioral description only. No official detection text, tactics, relationships, aliases, or labels were supplied. Local container architecture, logging configuration, mounted path conventions, and expected application behavior are required to implement and tune this reliably.
Analytic 0859
Container processes accessing mounted secrets or configuration paths (e.g., /run/secrets, /mnt/config) followed by network access or credential use.
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 | 5312a68b4499… |
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 AN0859Open 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.