tfMITRE ATT&CK technique

Deploy Container T1610

Tactic: Execution
Platform: Containers
Version: 2.0
Created: 29 March 2021
Last modified: 12 May 2026
Contributors: Alfredo Oliveira, Trend Micro; Ariel Shuper, Cisco; Center for Threat-Informed Defense (CTID); Idan Frimark, Cisco; Joas Antonio dos Santos, @C0d3Cr4zy; Magno Logan, @magnologan, Trend Micro; Pawan Kinger, @kingerpawan, Trend Micro; Vishwas Manral, McAfee; Yossi Weizman, Azure Defender Research Team

Adversaries may deploy a container into an environment to facilitate execution or evade defenses. In some cases, adversaries may deploy a new container to execute processes associated with a particular image or deployment, such as processes that execute or download malware. In others, an adversary may deploy a new container configured without network rules, user limitations, etc. to bypass existing defenses within the environment. In Kubernetes environments, an adversary may attempt to deploy a privileged or vulnerable container into a specific node in order to Escape to Host and access other containers running on the node. [1]

ReconResource DevInitial AccessExecutionPersistencePriv EscStealthDef ImpairmentCred AccessDiscoveryLateral MoveCollectionC2ExfiltrationImpact

Threat groups45th pct

Threat groups45th percentile · 55% of ATT&CK techniques have more threat groups attributed.

CampaignsNone recorded

CampaignsNone recorded · 54% of ATT&CK techniques have none either.

Tools & malware57th pct

Tools & malware57th percentile · 57% of ATT&CK techniques have this many tools implementing them or fewer.

Detection rules50th pct

Detection rules50th percentile · 50% of ATT&CK techniques have more detection rules written.

Deploy Container MITRE reference T1610

45th pctamong all ATT&CK techniques for number of groups

1 group has been recorded using this technique. Newest first; each entry carries MITRE’s procedure text and a link to the group’s full record. Click a name to filter the rules below.

TeamTNTG0139 ↗

Has deployed different types of containers into victim environments to facilitate execution.1 2 TeamTNT has also transferred cryptocurrency mining software to Kubernetes clusters discovered within local IP address ranges.3

created 2021-10-013 references

All 1 groups for this technique

Offense vs defense T1610

Is defensive coverage keeping up with adversary use? Eight counts, each ranked against all 697 ATT&CK techniques. Attack sits left, defense right, so a shape leaning left means adversaries are better documented here than defenders are equipped. Hover any spoke for its percentile and the share of techniques that have more. The timeline below shows when each side arrived.

How it got here

Range

Adversary activity (campaign spans) over cumulative rule output. Each source is plotted independently from zero, so neither line includes the other. Campaign dates are year-granularity.

Campaigns · 0Sigma rules (cumulative) · 0Splunk ESCU (cumulative) · 2

first rule: 2026 Q3

Deploy Container detection strategy DET0249

MITRE names one behaviour worth catching for this technique and breaks it into 1 analytic, one per platform. Each carries the log sources it needs and the fields you tune per environment.

Behavior-chain detection for T1610 Deploy Container across Docker & Kubernetes control/node planes

Enterprise

1 platform

AN0693 · Containers

Remote/API driven creation **and** start of a container whose image is not on an allow‑list (or is tagged latest), executed by a non-admin principal, and/or started with risky runtime attributes (e.g., --privileged, host PID/NET namespaces, sensitive host path mounts, capability adds). Correlates *create* ➜ *start* ➜ first network/process actions from that container within a short time window.

Log sources

The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.

Data component	Name	Channel
Process CreationDC0032	ebpf:syscalls	process execution or network connect from just-created container PID namespace
Application Log ContentDC0038	docker:daemon	container_create,container_start
Container StartDC0077	containerd:runtime	CRI CreateContainer/StartContainer with privileged=true OR added capabilities OR host* namespaces
Network Traffic ContentDC0085	docker:events	remote API calls to /containers/create or /containers/{id}/start

Tunable fields

MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.

Field	What you tune
known_images	Environment-specific allow-list of approved images (with digests).
known_admins	Service accounts or CI/CD users permitted to deploy containers.
TimeWindow	Max time between create, start, and first activity to consider events causally linked (default 5m).
RiskThreshold	Minimum number of risky attributes (e.g., unknown image + privileged) to alert.
PrivilegedFlags	Set of runtime flags considered high risk (e.g., --privileged, --cap-add=SYS_ADMIN, hostPID, hostNetwork, /var/run/docker.sock mount).

AuditM1047

Scan images before deployment, and block those that are not in compliance with security policies. In Kubernetes environments, the admission controller can be used to validate images after a container deployment request is authenticated but before the container is deployed.

Limit Access to Resource Over NetworkM1035

Limit communications with the container service to managed and secured channels, such as local Unix sockets or remote access via SSH. Require secure port access to communicate with the APIs over TLS by disabling unauthenticated access to the Docker API, Kubernetes API Server, and container orchestration web applications. In Kubernetes clusters deployed in cloud environments, use native cloud platform features to restrict the IP ranges that are permitted to access to API server. Where possible, consider enabling just-in-time (JIT) access to the Kubernetes API to place additional restrictions on access.

Network SegmentationM1030

Deny direct remote access to internal systems through the use of network proxies, gateways, and firewalls.

User Account ManagementM1018

Enforce the principle of least privilege by limiting container dashboard access to only the necessary users. When using Kubernetes, avoid giving users wildcard permissions or adding users to the system:masters group, and use RoleBindings rather than ClusterRoleBindings to limit user privileges to specific namespaces.

Tests1Executorsbash 1Need elevation0 of 1Have prerequisites1Have cleanup1Platformscontainers

#	Test	Platform	Executor	Elevation	Prereqs	Cleanup	Ref
01	Deploy Docker container	containers	bash	—	2	Yes
Adversaries may deploy containers based on retrieved or built malicious images or from benign images that download and execute malicious payloads at runtime. They can do this using docker create and docker start commands. Kinsing & Doki was exploited using this technique. Attack command docker build -t t1610 $PathtoAtomicsFolder/T1610/src/ docker run --name t1610_container --rm -itd t1610 bash /tmp/script.sh Cleanup command docker stop t1610_container docker rmi -f t1610:latest Prerequisite Verify docker is installed. Check which docker Satisfy if [ "" == "`which docker`" ]; then echo "Docker Not Found"; if [ -n "`which apt-get`" ]; then sudo apt-get -y install docker ; elif [ -n "`which yum`" ]; then sudo yum -y install docker ; fi ; else echo "Docker installed"; fi Prerequisite Verify docker service is running. Check sudo systemctl status docker --no-pager Satisfy sudo systemctl start docker GUID1748c360-82a2-4186-8722-716d928b7280

Tests from Atomic Red Team (MIT licence) · technique definition

Deploy Container detections T1610

2 rules are mapped to this technique. Parent techniques also include their sub-techniques’ rules. Click a slice or key entry to filter the table.

50th pctamong all ATT&CK techniques for number of rules

Product

Severity

Library

Drag headers to reorder | Drag edges to resize

Loading detections...

Select	Title	Description	Category	Status	Event	Product	MITRE ATT&CK	CVEs	Severity	Author	Created	Updated	ID	Refs