AN0530: Analytic 0530
Compromised service account tokens mounted inside containers and reused for external API calls or lateral movement across services.
Analyst context for executives and security teams
This analytic is about a container identity risk: service account tokens that are mounted inside containers can be stolen or misused to call external APIs or move across services. For leaders, the practical issue is whether container workloads have more identity privilege than they need, whether token use is visible, and whether an incident team could quickly determine which services were accessed if a workload token was compromised.
Executive priority
Prioritize this where containerized services rely on mounted service account tokens for access to internal or external APIs. The business risk is not just container compromise; it is identity reuse that may let an attacker cross service boundaries. Executives should ask whether cloud/container identity permissions are least-privilege, whether token activity is logged, and whether SOC and IR teams can trace service-to-service API access during an investigation.
Technical view
For SOC, detection engineering, and IR teams, validate visibility around container workload identity use rather than relying only on container runtime alerts. The supplied ATT&CK object names Containers as the platform and describes compromised mounted service account tokens reused for external API calls or lateral movement across services. Because no official detection logic is provided, teams should build local analytics from available container, API, identity, and network telemetry and baseline expected service account behavior.
Likely telemetry
- Container orchestration audit logs showing pod/container creation, service account assignment, and token mounting behavior
- Cloud or platform identity logs for service account authentication and API calls
- API gateway, application, or service mesh logs showing service-to-service requests
- Network egress logs from container workloads to external APIs or unexpected internal services
- Container runtime or workload logs that may show abnormal token access or unusual process behavior
Detection direction
- Baseline normal API destinations, methods, and frequency for each container service account, then alert on unusual external API calls or unexpected cross-service access.
- Correlate service account identity activity with the originating workload, namespace, container, or service where possible.
- Look for service account use from unexpected locations, workloads, or time windows, while accounting for legitimate deployments, autoscaling, and service failover to reduce false positives.
- Validate whether logs preserve enough identity context to distinguish a human user, workload identity, and service account token use.
- Treat missing official detection guidance as a coverage gap requiring environment-specific analytic design and testing.
Mitigation priorities
- Reduce token exposure by reviewing which containers need mounted service account tokens and disabling unnecessary mounts where the platform supports it.
- Apply least privilege to service account permissions so a compromised token cannot broadly access APIs or other services.
- Segment service-to-service access so workload identity misuse has limited lateral movement paths.
- Ensure token use, API calls, and container workload identity context are retained for investigation and compliance evidence.
- Include compromised service account token scenarios in incident response exercises for container environments.
Analyst notes and limits
This object is a detection analytic, not a technique description, and it has no supplied tactic, relationship context, or official detection text. The key decision value is validating whether container identity telemetry and least-privilege controls are strong enough to detect and contain misuse of mounted service account tokens.
Assessment is limited to the supplied ATT&CK fields. No active exploitation, attribution, specific cloud provider, product behavior, or guaranteed detection coverage is implied. Local architecture, logging configuration, and service account permission models determine actual risk and detectability.
Analytic 0530
Compromised service account tokens mounted inside containers and reused for external API calls or lateral movement across 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 | abc87780e29c… |
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 AN0530Open 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.