AN0571: Analytic 0571
Detection correlates anomalous Docker or Kubernetes API requests with access to logs, secrets, or service accounts. Observes unauthorized use of `docker logs`, `kubectl get secrets`, or direct API calls to Kubernetes API server endpoints. Identifies behavioral patterns where adversaries escalate from basic pod/container interaction to privileged API calls exposing sensitive credential material.
Analyst context for executives and security teams
This analytic matters because container control planes can expose high-value operational secrets when normal container or pod access turns into requests for logs, Kubernetes secrets, service accounts, or API server endpoints. For leaders, the practical question is whether the organization can see and investigate suspicious Docker or Kubernetes API activity before credential material is exposed and reused elsewhere.
Executive priority
Prioritize this as a container security and incident readiness validation item. It supports decisions around cloud/container logging coverage, access governance for Kubernetes and Docker interfaces, and evidence needed to show that sensitive credential access is monitored. Because ATT&CK provides no relationship context or tactic mapping for this object, treat it as a focused detection-control check rather than a complete risk scenario.
Technical view
For SOC and detection teams, validate whether container-platform telemetry can correlate anomalous Docker or Kubernetes API requests with access to sensitive resources such as logs, secrets, service accounts, and Kubernetes API server endpoints. Useful review points include unusual use of docker logs, kubectl requests for secrets, direct Kubernetes API calls, and behavioral progression from basic pod or container interaction to privileged API access. The supplied ATT&CK object does not include an official detection implementation, so local baselining, authorization context, and workload ownership data are required to make this analytic actionable.
Likely telemetry
- Docker API or daemon activity logs where available
- Kubernetes API server audit logs
- kubectl command or API request records where collected
- Container and pod access events
- Requests involving logs, secrets, and service accounts
Detection direction
- Confirm that Kubernetes API server audit logging and relevant Docker activity logging are enabled and retained for investigation.
- Correlate basic pod/container interaction with subsequent access to logs, secrets, service accounts, or privileged API endpoints.
- Tune against known administrative workflows, automation, CI/CD jobs, and platform controllers that legitimately query secrets or logs.
- Look for anomalous request patterns by identity, namespace, workload, source, time, and resource type rather than relying on a single command string.
- Document blind spots where direct API calls, unmanaged clusters, limited audit policies, or missing identity context would prevent correlation.
Mitigation priorities
- Restrict access to Kubernetes secrets, service accounts, logs, and Docker/Kubernetes APIs using least privilege.
- Review service account permissions and remove unnecessary rights to read secrets or sensitive logs.
- Ensure audit logging is configured to capture sensitive API resource access without creating unusable noise.
- Separate routine administrative access from workload identities so suspicious escalation paths are easier to identify.
- Prepare IR procedures for investigating suspected credential exposure from container logs, secrets, or service account access.
Analyst notes and limits
AN0571 is a detection analytic for Containers in the enterprise ATT&CK domain. Its value is strongest as a validation of container telemetry and privilege monitoring around Docker and Kubernetes APIs. No tactics, relationships, aliases, labels, or official detection logic were supplied, so this take avoids assigning technique context or claiming coverage beyond the described analytic behavior.
The object provides a description but no official detection content, no relationship context, and no ATT&CK tactic mapping. Effectiveness depends on local Kubernetes/Docker logging, audit policy configuration, identity context, and knowledge of normal administrative and automation behavior.
Analytic 0571
Detection correlates anomalous Docker or Kubernetes API requests with access to logs, secrets, or service accounts. Observes unauthorized use of `docker logs`, `kubectl get secrets`, or direct API calls to Kubernetes API server endpoints. Identifies behavioral patterns where adversaries escalate from basic pod/container interaction to privileged API calls exposing sensitive credential material.
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 | 398c1237a981… |
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 AN0571Open 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.