Container CLI and API abuse (MITRE ATT&CK T1059.013) is an Execution technique for containerized environments.
Containers are managed through command line tools and APIs, and those same interfaces can be used to run commands. If someone can reach them with enough permission, they can pull images, start containers, and execute commands inside containers that are already running.
How attackers use it
MITRE covers Docker and Kubernetes separately.
Docker. The Docker CLI manages containers through an exposed API endpoint from the dockerd daemon. Docker Desktop CLI and Docker Compose are common examples, and SDKs such as the Docker SDK for Python can call the same API. MITRE says adversaries may use the CLI, API or SDK to pull or build images, run containers, or execute commands inside running ones. In some cases they pull a legitimate image that already contains tools they need, for example an image that includes curl to download payloads. They may also use docker inspect and docker ps to look for cloud environment variables and other running containers.
Kubernetes. The control plane manages orchestration across clusters and can be invoked directly through the API, or indirectly through tools such as kubectl and client libraries in languages like Go or Python. MITRE says adversaries call the API server with curl or other tools to learn about pods, deployments, daemonsets, namespaces or environment variables, and can also run commands related to resource management.
Related ATT&CK techniques that MITRE links from this page include Ingress Tool Transfer, Build Image on Host, Deploy Container, Container Administration Command, and Container and Resource Discovery.
How to detect it
MITRE's detection strategy is one analytic: execution of orchestration commands such as docker exec or kubectl exec, or API-driven interaction with running containers, from unauthorized hosts or non-standard user contexts. You are looking for command execution inside containers outside your expected CI/CD tools and automation frameworks, often followed by file writes, privilege escalation or lateral discovery.
Data to collect:
- Kubernetes audit logs, which record API requests including who made them and from where.
- Docker daemon and host logs, including who reached the Docker socket or API.
- Container runtime and process events, to see what ran inside a container after an exec.
- Identity records for service accounts and users that hold cluster permissions.
A useful baseline is the list of identities and pipelines that are supposed to exec into containers. Anything else is worth a look.
How to reduce the risk
MITRE lists two mitigations:
- Privileged account management. Restrict permissions on API access. Kubernetes RBAC permissions are additive, meaning there are no explicit deny rules, and they can be set within a namespace or on cluster-scoped resources. Secure the Docker daemon with SSH or TLS using certificate authorization. Tools such as Docker and Podman may also offer rootless mode, which stops containers from running with privileged permissions.
- Execution prevention. Deny scripting where appropriate. Languages like Python or Go can use Kubernetes and Docker client libraries to run commands inside an application.
Because the images themselves matter, scan them before they run. A base image with extra tools gives an intruder more to work with. See the container image demo below.
Try it yourself
Click through it at your own pace, or open it full screen.
Check your own environment
# Kubernetes (kubectl): what can the current identity do? (read only)
kubectl auth can-i --list
# Kubernetes: which subjects are bound to cluster-admin and other cluster roles
kubectl get clusterrolebindings -o wide
# Docker: running containers and their images
docker ps
# Docker: is the daemon API exposed on a TCP port? Look for tcp:// in the output
ps aux | grep dockerd
Then ask:
- Is the Docker socket mounted into any container that does not need it?
- Is the Docker API listening on the network, and is it protected with TLS?
- Which service accounts can exec into pods?
- Are Kubernetes audit logs enabled and sent off the cluster?
- Can your pipelines be told apart from humans in the logs?
Quick check
What do Kubernetes RBAC permissions mean by additive?
There are no explicit deny rules. Permissions only add up, so you control risk by granting less in the first place.
Why might an adversary pull a legitimate image?
It may already contain tools they want, such as curl, to download payloads.
What command pattern does MITRE's analytic flag?
docker exec or kubectl exec, or API-driven interaction with running containers, from unauthorized hosts or non-standard user contexts, outside expected CI/CD tools.
