Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

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.

EnterpriseT1059.013Sub-techniqueObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

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.

Official MITRE ATT&CK definition

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.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

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.

1 rows
Domain ID Name Relationship / procedure
Enterprise T1059 Command and Scripting Interpreter This object subtechnique of Command and Scripting Interpreter.
Associated objects

Groups, software, and campaigns

Group Enterprise

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]

Relationship explorer

All related ATT&CK context

Mitigations

Mitigation direction

Change history

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 .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
4bc8051333ab54d3...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 4bc8051333ab…
Raw source

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.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    Docker Desktop CLI

    dockerdocs. (n.d.). Use the Docker Desktop CLI. Retrieved October 21, 2025.

    Open source URL
  2. [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. [3]
    Cisco Talos Blog

    Jaeson Schultz, Darin Smith. (2022, April 21). TeamTNT Targeting AWS, Alibaba. Retrieved June 15, 2025.

    Open source URL
  4. [4]
    aquasec

    Ofek Itach, Assaf Morag. (2023, July 13). TeamTNT Reemerged with New Aggressive Cloud Campaign. Retrieved June 15, 2025.

    Open source URL
  5. [5]
    mitre-attack T1059.013
    Open source URL
Source and licensing

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.