Detecting and Mitigating Container API Credential Theft (T1552.007)

Container platforms are managed through APIs. The Docker API and the Kubernetes API let you start workloads, read logs and fetch cluster configuration, all remotely. MITRE ATT&CK tracks the abuse of those APIs to collect credentials as Container API, technique T1552.007. It sits under the credential access tactic and applies to the Containers platform.

The short version: anything that can talk to a container API and has enough permission can read secrets. The defensive work is mostly about shrinking who can talk to the API and what they can read.

How attackers use it

MITRE describes two paths.

The first is the Docker API. An adversary who can reach it may collect container logs. Logs often contain credentials to cloud services, to other containers and to various resources in the environment, simply because applications print more than they should.

The second is the Kubernetes API. An adversary with enough permission, for example through a pod's service account, can use the API to retrieve credentials held by the API server. Those can include credentials needed to authenticate to the Docker API, and secrets belonging to cluster components.

Notice what is missing: no exploit is required. The access is a legitimate API call with a legitimate token. The problem is that the token was allowed to do more than the workload needed.

How to detect it

MITRE's page for this technique does not list specific detection data sources, so detection has to come from what these APIs already record and from your own baseline of normal behavior. Practical signals:

• Kubernetes audit logs showing reads of Secret objects, especially list or get calls from a service account that has never done that before.
• Requests to the API server from pods that have no business calling it, such as a simple web front end.
• Docker daemon access from addresses that are not your management hosts, and log retrieval for containers the caller does not own.
• A service account token used from outside the cluster, or from a different node than the pod it belongs to.

Turn on audit logging for the API server and ship it somewhere an attacker inside a pod cannot reach. Without it you cannot answer the question "who read that secret".

How to reduce the risk

These are the mitigations MITRE lists, in plain steps.

1. Use least privilege for service accounts. If a pod does not need the Kubernetes API, disable its service account token altogether.
2. Limit network access to the container service. Use managed and secured channels such as local Unix sockets or SSH. Require TLS for API access and disable unauthenticated access to both the Docker API and the Kubernetes API server.
3. Segment the network. Deny direct remote access to internal systems through proxies, gateways and firewalls.
4. Enforce authentication and role based access control on the container API. In Kubernetes, avoid wildcard permissions and avoid adding users to the system:masters group. Prefer RoleBindings over ClusterRoleBindings so privileges stay inside a namespace.

To stop a pod from receiving an API token, set this in the pod spec:

spec:
  automountServiceAccountToken: false

Check your own environment

Run these read-only checks from an admin workstation.

# Kubernetes: what can a given service account do?
kubectl auth can-i --list --as=system:serviceaccount:NAMESPACE:SERVICEACCOUNT -n NAMESPACE

# Kubernetes: who is bound to cluster wide roles?
kubectl get clusterrolebindings -o wide

# Linux host running Docker: is the daemon listening on TCP?
ss -ltn | grep -E ':(2375|2376)'

Port 2375 is the unencrypted Docker API port and 2376 is the TLS one. Anything on 2375 reachable beyond localhost deserves an immediate look.

Also scan your images for credentials baked into layers, since a log or API read is not the only place secrets leak. The demo below shows what an image scan reports.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• MITRE ATT&CK T1552.007 Container API