AN1423: Analytic 1423
Access and retrieval of container service account tokens followed by unauthorized API requests using those tokens to interact with the Kubernetes API server or internal services.
Analyst context for executives and security teams
This analytic concerns a high-value container security behavior: access to Kubernetes/container service account tokens followed by unauthorized use of those tokens against the Kubernetes API server or internal services. For leaders, the practical issue is identity misuse inside the container environment—an attacker may not need a new exploit if a token can be retrieved and reused. The business decision value is to verify whether container identity, API access, and audit telemetry are strong enough to prove or disprove unauthorized service account activity during an incident.
Executive priority
Prioritize this as a container identity and operational resilience concern. Security leaders should ask whether Kubernetes service account token use is governed, logged, and reviewable; whether API server activity can be tied back to expected workloads; and whether incident responders can quickly determine if a token was accessed and then used outside its intended context. This supports cloud/container security readiness, SOC detection validation, incident response decision-making, and compliance evidence for access control monitoring.
Technical view
The supplied ATT&CK analytic is scoped to Containers and describes retrieval of container service account tokens followed by unauthorized API requests using those tokens. Because no official detection logic or relationships are supplied, defenders should validate coverage around two evidence points: token access from workloads and subsequent Kubernetes API server or internal service requests made with service account credentials. SOC and detection teams should baseline expected service account behavior by namespace, workload, source pod/node, API verb, and target resource, then look for deviations such as unexpected API calls, unusual source context, or service accounts interacting with resources outside their normal role.
Likely telemetry
- Kubernetes API server audit logs showing authenticated service account requests
- Container runtime or workload logs that may show access to mounted service account token paths
- Pod, namespace, node, and workload metadata for context on where token access or API activity originated
- Identity and authorization context for Kubernetes service accounts, roles, role bindings, and permissions
- Network telemetry for workload-to-API-server or workload-to-internal-service communication where available
Detection direction
- Validate that Kubernetes API server audit logging is enabled and retained at a level sufficient to identify service account, source context, verb, resource, namespace, and request outcome.
- Build baselines for expected service account API activity and tune detections for service accounts making unusual requests, accessing unusual resources, or acting from unexpected workloads or namespaces.
- Correlate suspected token access from containers with later API requests using the same service account identity; either signal alone may be noisy, but the sequence is more decision-useful.
- Review false positives from legitimate controllers, operators, CI/CD jobs, and service meshes that may make broad or frequent API calls using service account credentials.
- Account for blind spots where workload logs are sparse, token file access is not monitored, API audit logs are disabled or low fidelity, or internal services do not record caller identity.
Mitigation priorities
- Inventory service accounts and confirm each has a clear workload owner and business purpose.
- Apply least privilege to service account permissions using Kubernetes authorization controls; remove broad or unused access where possible.
- Reduce unnecessary exposure of service account tokens to workloads that do not need Kubernetes API access.
- Ensure API server audit logging and relevant container/workload telemetry are centrally collected, retained, and usable during incident response.
- Create an incident response procedure for suspected service account token misuse, including scoping affected workloads, reviewing API activity, and rotating or revoking affected credentials where appropriate.
Analyst notes and limits
This is a detection analytic object, not a technique object, and the supplied fields provide a concise behavior description but no official detection logic, tactics, or relationship context. The key defensive value is validating container identity telemetry and Kubernetes API auditability around service account token use.
Official detection content was not provided, and no relationships were supplied. This take is limited to the Containers platform and the described Kubernetes API server/internal service token-use behavior. Local architecture, logging configuration, RBAC design, and workload behavior are required to determine actual exposure, detection feasibility, and priority.
Analytic 1423
Access and retrieval of container service account tokens followed by unauthorized API requests using those tokens to interact with the Kubernetes API server or internal services.
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 | 73e790e02d13… |
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 AN1423Open 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.