DET0198: Detect Abuse of Container APIs for Credential Access
DET0198 is a detection strategy for identifying abuse of container management APIs for credential access. The business issue is not just container security...
Analyst context for executives and security teams
DET0198 is a detection strategy for identifying abuse of container management APIs for credential access. The business issue is not just container security; it is whether credentials exposed through Docker, Kubernetes, or similar container APIs could let an intruder move from a container environment into cloud, application, or operational systems. Leaders should treat this as a validation point for container logging, API access governance, and incident response readiness.
Executive priority
Prioritize this where containers are used to run business-critical workloads or where container environments can access cloud resources, secrets, or production data. The key executive question is whether the organization can prove who accessed container APIs, what they retrieved, and whether credentials were exposed in logs or API-accessible resources. This supports resilience planning, identity and access management decisions, cloud/container control investment, and audit evidence around privileged access and monitoring.
Technical view
The ATT&CK relationship maps this strategy to T1552.007 Container API under credential-access for the Containers platform. Because the detection strategy object does not include official detection logic, SOC and detection engineering teams should validate coverage around container API activity rather than assume a specific analytic exists. Focus on API access to Docker and Kubernetes management interfaces, especially requests or administrative actions that could expose logs, secrets, configuration, pod metadata, or other credential-bearing data. IR teams should ensure investigations can reconstruct API caller identity, source, target resource, timing, and whether retrieved data may have contained credentials.
Likely telemetry
- Container API audit logs, including Kubernetes API audit events where available
- Docker daemon or container runtime API access logs where collected
- Authentication and authorization records for users, service accounts, and administrative identities accessing container APIs
- Cloud or platform control-plane logs related to managed container clusters, if applicable in the local environment
- Container workload logs that may contain credentials or tokens
Detection direction
- Validate whether container API access is logged with sufficient identity, source, action, resource, and result fields to support credential-access investigations.
- Tune for unusual or high-risk access to logs, secrets, configuration objects, service account material, or cluster resources through container APIs.
- Compare container API activity against expected administrator, automation, and CI/CD behavior to reduce false positives from normal operations.
- Review blind spots around unmanaged Docker daemons, incomplete Kubernetes audit logging, short log retention, and service-account activity that is difficult to attribute to a human owner.
- Use the related ATT&CK context, T1552.007 Container API, to frame hunts around credential exposure rather than only generic container administration.
Mitigation priorities
- Inventory container management APIs and confirm they are not exposed beyond intended administrative or platform access paths.
- Enforce least-privilege access for users, service accounts, and automation interacting with container APIs.
- Reduce credential exposure in container logs, configuration, and runtime-accessible resources; validate secret-handling practices.
- Ensure audit logging and retention are enabled for container API activity before relying on detection or incident reconstruction.
- Integrate container API evidence into SOC playbooks and incident response procedures for credential-access investigations.
Analyst notes and limits
The supplied ATT&CK object is a detection strategy with no official description, no official detection text, and no specified platforms or tactics on the strategy itself. The practical interpretation comes from its relationship to T1552.007 Container API, which is a credential-access technique on the Containers platform and references Docker and Kubernetes APIs. Local architecture determines which telemetry sources and controls are applicable.
This take does not assert active exploitation, attribution, or existing detection coverage. Specific analytic logic, thresholds, event IDs, and vendor implementation details are not present in the supplied fields and must be developed from local container platform telemetry and expected administrative behavior.
Detect Abuse of Container APIs for Credential Access
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1552.007 | Container API Sub-technique | This object detects Container API. |
All related ATT&CK context
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 | 14b5e6f34d1e… |
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 DET0198Open 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.