T1059.013: Container CLI/API
Adversaries may abuse built-in CLI tools or API calls to execute malicious commands in containerized environments.
The Docker CLI is used for managing containers via an exposed API point from the `dockerd` daemon. Some common examples of Docker CLI include Docker Desktop CLI and Docker Compose, but users are also able to use SDKs to interact with the API. For example, Docker SDK for Python can be used to run commands within a Python application.[1]
Adversaries may leverage the Docker CLI, API, or SDK to pull or build Docker images (i.e., Ingress Tool Transfer, Build Image on Host), run containers (i.e., Deploy Container), or execute commands inside running containers (i.e., Container Administration Command). In some cases, threat actors may pull legitimate images that include scripts or tools that they can leverage - for example, using an image that includes the `curl` command to download payloads.[2] Adversaries may also utilize `docker inspect` and `docker ps` to scan for cloud environment variables and other running containers (i.e., Container and Resource Discovery).[3][4]
Kubernetes is responsible for the management and orchestration of containers across clusters. The Kubernetes control plane, which manages the state of the cluster and is responsible for scheduling, communication, and resource monitoring, can be invoked directly via the API or indirectly via CLI tools such as `kubectl`. It may also be accessed within client libraries such as Go or Python. By utilizing the API, administrators can interact with resources within the cluster such as listing or creating pods, which is a group of one or more containers. Adversaries call the API server via `curl` or other tools, allowing them to obtain further information about the environment such as pods, deployments, daemonsets, namespaces, or sysvars.[4] They may also run various commands regarding resource management.
Analyst context for executives and security teams
Container CLI/API abuse matters because the same Docker and Kubernetes interfaces administrators use to run, inspect, and manage containers can be used by an adversary to execute commands, start containers, pull images, or query the environment. For leaders, this is a control and visibility question: can the organization prove who can use Docker or Kubernetes APIs, what they did, and whether unusual execution would be noticed quickly?
Executive priority
Prioritize this where containers are part of production, cloud, CI/CD, or developer infrastructure. The business risk is not just malware execution; it is unauthorized control-plane or container-runtime activity that can affect operational resilience, cloud governance, incident scope, and audit evidence. Executives should ask whether privileged container administration is tightly governed, logged, and reviewed, and whether SOC/IR teams have a tested playbook for suspicious Docker or Kubernetes API activity.
Technical view
This is an execution sub-technique for the Containers platform under Command and Scripting Interpreter. Validate visibility into Docker CLI/API and Kubernetes API usage, including commands or API calls that pull/build images, run containers, execute commands inside containers, inspect containers, list resources, or query pods, deployments, daemonsets, namespaces, sysvars, and environment variables. ATT&CK provides no official detection text for this object, but the relationship to DET0083 indicates a relevant detection strategy exists for Docker/Kubernetes CLI and API abuse. Detection engineering should focus on administrative actions occurring from unexpected identities, hosts, service accounts, namespaces, or automation paths, while accounting for legitimate DevOps and platform operations.
Likely telemetry
- Docker daemon/API access logs and container runtime events
- Docker CLI usage evidence from hosts where available
- Kubernetes API server audit logs
- kubectl and client-library access patterns where logged
- Container create, run, exec, inspect, ps, image pull, and image build events
Detection direction
- Confirm that Docker and Kubernetes administrative actions are logged with actor, source, target resource, command/API verb, timestamp, and outcome.
- Baseline expected CI/CD, developer, and platform-automation usage so detections do not treat all container administration as suspicious.
- Tune for unusual image pulls/builds, container launches, exec activity into running containers, broad resource enumeration, and API calls from unexpected identities or locations.
- Correlate container CLI/API activity with related ATT&CK behaviors referenced by the object, including ingress tool transfer, image build on host, deploy container, container administration command, and container/resource discovery.
- Review coverage against DET0083 if available internally, but do not assume coverage because ATT&CK does not provide official detection content in this object.
Mitigation priorities
- Start with privileged account management: restrict Docker daemon, Kubernetes API, cluster-admin, namespace-admin, and service-account permissions using least privilege and RBAC.
- Limit who and what automation can create containers, execute into running containers, pull/build images, or enumerate sensitive resources.
- Apply execution prevention principles where feasible so only authorized images, tools, scripts, and administrative workflows can run in container environments.
- Ensure privileged container administration is logged, attributable, and reviewable for incident response and compliance evidence.
- Regularly validate access paths from developer workstations, CI/CD systems, cloud workloads, and management hosts to Docker and Kubernetes APIs.
Analyst notes and limits
The object is specific to containerized environments and focuses on abuse of built-in Docker and Kubernetes CLI/API capabilities. The TeamTNT relationship indicates this technique has been associated with that ATT&CK group, but this take does not infer current activity or customer exposure. The most important local validation is whether container administration is observable and attributable across both runtime and orchestration layers.
Official ATT&CK detection guidance is not provided for this technique, and the supplied relationship to DET0083 does not include detection logic details. Telemetry availability and false-positive rates depend heavily on local container architecture, Kubernetes audit configuration, CI/CD design, identity model, and logging retention.
Container CLI/API
Adversaries may abuse built-in CLI tools or API calls to execute malicious commands in containerized environments.
The Docker CLI is used for managing containers via an exposed API point from the `dockerd` daemon. Some common examples of Docker CLI include Docker Desktop CLI and Docker Compose, but users are also able to use SDKs to interact with the API. For example, Docker SDK for Python can be used to run commands within a Python application.[1]
Adversaries may leverage the Docker CLI, API, or SDK to pull or build Docker images (i.e., Ingress Tool Transfer, Build Image on Host), run containers (i.e., Deploy Container), or execute commands inside running containers (i.e., Container Administration Command). In some cases, threat actors may pull legitimate images that include scripts or tools that they can leverage - for example, using an image that includes the `curl` command to download payloads.[2] Adversaries may also utilize `docker inspect` and `docker ps` to scan for cloud environment variables and other running containers (i.e., Container and Resource Discovery).[3][4]
Kubernetes is responsible for the management and orchestration of containers across clusters. The Kubernetes control plane, which manages the state of the cluster and is responsible for scheduling, communication, and resource monitoring, can be invoked directly via the API or indirectly via CLI tools such as `kubectl`. It may also be accessed within client libraries such as Go or Python. By utilizing the API, administrators can interact with resources within the cluster such as listing or creating pods, which is a group of one or more containers. Adversaries call the API server via `curl` or other tools, allowing them to obtain further information about the environment such as pods, deployments, daemonsets, namespaces, or sysvars.[4] They may also run various commands regarding resource management.
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.
Related techniques
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 | T1059 | Command and Scripting Interpreter | This object subtechnique of Command and Scripting Interpreter. |
Groups, software, and campaigns
G0139: TeamTNT
TeamTNT is a threat group that has primarily targeted cloud and containerized environments. The group as been active since at least October 2019 and has mainly focused its efforts on leveraging cloud and container resources to deploy cryptocurrency miners in victim environments.[1][2][3][4][5][6][7][8][9]
All related ATT&CK context
Mitigation direction
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 | 4bc8051333ab… |
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]
Docker Desktop CLI
dockerdocs. (n.d.). Use the Docker Desktop CLI. Retrieved October 21, 2025.
Open source URL -
[2]
Intezer
Nicole Fishbein. (2020, July 28). Watch Your Containers: Doki Infecting Docker Servers in the Cloud. Retrieved June 15, 2025.
Open source URL -
[3]
Cisco Talos Blog
Jaeson Schultz, Darin Smith. (2022, April 21). TeamTNT Targeting AWS, Alibaba. Retrieved June 15, 2025.
Open source URL -
[4]
aquasec
Ofek Itach, Assaf Morag. (2023, July 13). TeamTNT Reemerged with New Aggressive Cloud Campaign. Retrieved June 15, 2025.
Open source URL -
[5]
mitre-attack T1059.013Open 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.