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

T1610: Deploy Container

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]

Containers can be deployed by various means, such as via Docker's create and start APIs or via a web application such as the Kubernetes dashboard or Kubeflow. [2][3][4] In Kubernetes environments, containers may be deployed through workloads such as ReplicaSets or DaemonSets, which can allow containers to be deployed across multiple nodes.[5] Adversaries may deploy containers based on retrieved or built malicious images or from benign images that download and execute malicious payloads at runtime.[6]

EnterpriseT1610TechniqueObject v2.0 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

Deploy Container matters because a container platform can become an execution path, not just an application runtime. If an attacker or misused account can create new Docker or Kubernetes workloads, they may run a malicious image, launch a benign image that downloads payloads at runtime, or start a container with weak controls such as excessive privilege, missing network rules, or insufficient user limits. For leaders, the key question is whether container deployment is governed, logged, and reviewable across both control-plane interfaces and node-level activity.

Executive priority

Prioritize this where Kubernetes, Docker, dashboards, Kubeflow, ReplicaSets, DaemonSets, or similar workload mechanisms support production services. The business risk is loss of execution control in container environments, with possible follow-on risk to host escape scenarios noted by ATT&CK. This technique should drive budget and assurance questions around identity governance for deployment rights, segmentation and network access restrictions, audit evidence for workload creation, and incident response readiness for unauthorized or abnormal container launches.

Technical view

ATT&CK lists this as an execution technique for Containers. Validate whether SOC and IR teams can reconstruct container creation and start activity through Docker APIs, Kubernetes workload creation, dashboard or Kubeflow activity, and node-level runtime events. Pay particular attention to privileged or vulnerable containers, containers deployed to specific nodes, workloads that fan out across nodes such as ReplicaSets or DaemonSets, and containers based on newly retrieved, newly built, or otherwise unexpected images. Official ATT&CK detection text is not provided, but the supplied relationship to DET0249 points to behavior-chain detection across Docker and Kubernetes control and node planes.

Likely telemetry

  • Docker container create and start API or CLI activity
  • Kubernetes API audit records for pod and workload creation
  • Kubernetes Dashboard access and deployment activity where used
  • Kubeflow pipeline or workload execution records where used
  • ReplicaSet and DaemonSet creation or modification events

Detection direction

  • Inventory all approved paths for deploying containers, then confirm each path produces centrally retained audit records.
  • Correlate control-plane events with node-plane runtime evidence so a declared workload can be tied to the actual container, image, process, and node where it ran.
  • Tune for unusual deployment initiators, unexpected service accounts, new or rarely used images, privileged containers, weak user restrictions, missing network controls, and workloads deployed broadly through ReplicaSets or DaemonSets.
  • Review runtime-download patterns separately from image reputation because ATT&CK notes benign images may download and execute malicious payloads at runtime.
  • Account for false positives from CI/CD systems, cluster operators, autoscaling, and legitimate batch or pipeline workloads; baselining authorized deployment automation is critical.

Mitigation priorities

  • Apply user account management and least-privilege principles to restrict who and what can create or modify containers and workloads.
  • Limit access to container management interfaces and deployment services over the network to accounts and systems with a business requirement.
  • Use network segmentation to reduce the reach of newly deployed containers and to constrain lateral movement opportunities.
  • Audit container deployment activity, account permissions, workload configuration, and runtime behavior on a recurring basis to support both detection and compliance evidence.
  • Review deployment policies for privileged containers, weak user limitations, permissive network settings, risky mounts, and node placement that could support host escape scenarios described by ATT&CK.
Analyst notes and limits

This take is based on ATT&CK T1610 Deploy Container, its external references, and supplied relationships. The technique is materially relevant to cloud-native and container operations because deployment authority can become execution authority. The most useful defensive assessment is not whether a tool can flag a container creation event, but whether the organization can prove who requested it, through which interface, what image and configuration were used, where it ran, and whether that behavior matched approved operational patterns.

MITRE did not provide official detection guidance for this object. Telemetry and control recommendations therefore rely on the ATT&CK description, cited deployment mechanisms, and supplied mitigation and detection-strategy relationships. Local platform architecture, enabled audit settings, orchestrator configuration, and CI/CD design are required to determine actual exposure or coverage.

Official MITRE ATT&CK definition

Deploy Container

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]

Containers can be deployed by various means, such as via Docker's create and start APIs or via a web application such as the Kubernetes dashboard or Kubeflow. [2][3][4] In Kubernetes environments, containers may be deployed through workloads such as ReplicaSets or DaemonSets, which can allow containers to be deployed across multiple nodes.[5] Adversaries may deploy containers based on retrieved or built malicious images or from benign images that download and execute malicious payloads at runtime.[6]

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.

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]

Malware Enterprise

S0599: Kinsing

Kinsing is Golang-based malware that runs a cryptocurrency miner and attempts to spread itself to other hosts in the victim environment. [1][2][3]

ContainersLinux
Tool Enterprise

S0683: Peirates

Peirates is a post-exploitation Kubernetes exploitation framework with a focus on gathering service account tokens for lateral movement and privilege escalation. The tool is written in GoLang and publicly available on GitHub.[1]

Containers
Malware Enterprise

S0600: Doki

Doki is a backdoor that uses a unique Dogecoin-based Domain Generation Algorithm and was first observed in July 2020. Doki was used in conjunction with the ngrok Mining Botnet in a campaign that targeted Docker servers in cloud platforms. [1]

LinuxContainers
Relationship explorer

All related ATT&CK context

uses · Malware S0599: Kinsing Enterprise mitigates · Mitigation M1018: User Account Management Enterprise uses · Group G0139: TeamTNT Enterprise mitigates · Mitigation M1047: Audit Enterprise detects · Detection Strategy DET0249: Behavior-chain detection for T1610 Deploy Container across Docker & Kubernetes control/node planes Enterprise mitigates · Mitigation M1030: Network Segmentation Enterprise uses · Tool S0683: Peirates Enterprise uses · Malware S0600: Doki Enterprise mitigates · Mitigation M1035: Limit Access to Resource Over Network Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1018: User Account Management

User Account Management involves implementing and enforcing policies for the lifecycle of user accounts, including creation, modification, and deactivation. Proper account management reduces the attack surface by limiting unauthorized access, managing account privileges, and ensuring accounts are used according to organizational policies. This mitigation can be implemented through the following measures:

Enforcing the Principle of Least Privilege

- Implementation: Assign users only the minimum permissions required to perform their job functions. Regularly audit accounts to ensure no excess permissions are granted. - Use Case: Reduces the risk of privilege escalation by ensuring accounts cannot perform unauthorized actions.

Implementing Strong Password Policies

- Implementation: Enforce password complexity requirements (e.g., length, character types). Require password expiration every 90 days and disallow password reuse. - Use Case: Prevents adversaries from gaining unauthorized access through password guessing or brute force attacks.

Managing Dormant and Orphaned Accounts

- Implementation: Implement automated workflows to disable accounts after a set period of inactivity (e.g., 30 days). Remove orphaned accounts (e.g., accounts without an assigned owner) during regular account audits. - Use Case: Eliminates dormant accounts that could be exploited by attackers.

Account Lockout Policies

- Implementation: Configure account lockout thresholds (e.g., lock accounts after five failed login attempts). Set lockout durations to a minimum of 15 minutes. - Use Case: Mitigates automated attack techniques that rely on repeated login attempts.

Multi-Factor Authentication (MFA) for High-Risk Accounts

- Implementation: Require MFA for all administrative accounts and high-risk users. Use MFA mechanisms like hardware tokens, authenticator apps, or biometrics. - Use Case: Prevents unauthorized access, even if credentials are stolen.

Restricting Interactive Logins

- Implementation: Restrict interactive logins for privileged accounts to specific secure systems or management consoles. Use group policies to enforce logon restrictions. - Use Case: Protects sensitive accounts from misuse or exploitation.

*Tools for Implementation*

Built-in Tools:

- Microsoft Active Directory (AD): Centralized account management and RBAC enforcement. - Group Policy Object (GPO): Enforce password policies, logon restrictions, and account lockout policies.

Identity and Access Management (IAM) Tools:

- Okta: Centralized user provisioning, MFA, and SSO integration. - Microsoft Azure Active Directory: Provides advanced account lifecycle management, role-based access, and conditional access policies.

Privileged Account Management (PAM): - CyberArk, BeyondTrust, Thycotic: Manage and monitor privileged account usage, enforce session recording, and JIT access.

Mitigation Enterprise

M1047: Audit

Auditing is the process of recording activity and systematically reviewing and analyzing the activity and system configurations. The primary purpose of auditing is to detect anomalies and identify potential threats or weaknesses in the environment. Proper auditing configurations can also help to meet compliance requirements. The process of auditing encompasses regular analysis of user behaviors and system logs in support of proactive security measures.

Auditing is applicable to all systems used within an organization, from the front door of a building to accessing a file on a fileserver. It is considered more critical for regulated industries such as, healthcare, finance and government where compliance requirements demand stringent tracking of user and system activates.This mitigation can be implemented through the following measures:

System Audit:

- Use Case: Regularly assess system configurations to ensure compliance with organizational security policies. - Implementation: Use tools to scan for deviations from established benchmarks.

Permission Audits:

- Use Case: Review file and folder permissions to minimize the risk of unauthorized access or privilege escalation. - Implementation: Run access reviews to identify users or groups with excessive permissions.

Software Audits:

- Use Case: Identify outdated, unsupported, or insecure software that could serve as an attack vector. - Implementation: Use inventory and vulnerability scanning tools to detect outdated versions and recommend secure alternatives.

Configuration Audits:

- Use Case: Evaluate system and network configurations to ensure secure settings (e.g., disabled SMBv1, enabled MFA). - Implementation: Implement automated configuration scanning tools like SCAP (Security Content Automation Protocol) to identify non-compliant systems.

Network Audits:

- Use Case: Examine network traffic, firewall rules, and endpoint communications to identify unauthorized or insecure connections. - Implementation: Utilize tools such as Wireshark, or Zeek to monitor and log suspicious network behavior.

Mitigation Enterprise

M1030: Network Segmentation

Network segmentation involves dividing a network into smaller, isolated segments to control and limit the flow of traffic between devices, systems, and applications. By segmenting networks, organizations can reduce the attack surface, restrict lateral movement by adversaries, and protect critical assets from compromise.

Effective network segmentation leverages a combination of physical boundaries, logical separation through VLANs, and access control policies enforced by network appliances like firewalls, routers, and cloud-based configurations. This mitigation can be implemented through the following measures:

Segment Critical Systems:

- Identify and group systems based on their function, sensitivity, and risk. Examples include payment systems, HR databases, production systems, and internet-facing servers. - Use VLANs, firewalls, or routers to enforce logical separation.

Implement DMZ for Public-Facing Services:

- Host web servers, DNS servers, and email servers in a DMZ to limit their access to internal systems. - Apply strict firewall rules to filter traffic between the DMZ and internal networks.

Use Cloud-Based Segmentation:

- In cloud environments, use VPCs, subnets, and security groups to isolate applications and enforce traffic rules. - Apply AWS Transit Gateway or Azure VNet peering for controlled connectivity between cloud segments.

Apply Microsegmentation for Workloads:

- Use software-defined networking (SDN) tools to implement workload-level segmentation and prevent lateral movement.

Restrict Traffic with ACLs and Firewalls:

- Apply Access Control Lists (ACLs) to network devices to enforce "deny by default" policies. - Use firewalls to restrict both north-south (external-internal) and east-west (internal-internal) traffic.

Monitor and Audit Segmented Networks:

- Regularly review firewall rules, ACLs, and segmentation policies. - Monitor network flows for anomalies to ensure segmentation is effective.

Test Segmentation Effectiveness:

- Perform periodic penetration tests to verify that unauthorized access is blocked between network segments.

Mitigation Enterprise

M1035: Limit Access to Resource Over Network

Restrict access to network resources, such as file shares, remote systems, and services, to only those users, accounts, or systems with a legitimate business requirement. This can include employing technologies like network concentrators, RDP gateways, and zero-trust network access (ZTNA) models, alongside hardening services and protocols. This mitigation can be implemented through the following measures:

Audit and Restrict Access:

- Regularly audit permissions for file shares, network services, and remote access tools. - Remove unnecessary access and enforce least privilege principles for users and services. - Use Active Directory and IAM tools to restrict access based on roles and attributes.

Deploy Secure Remote Access Solutions:

- Use RDP gateways, VPN concentrators, and ZTNA solutions to aggregate and secure remote access connections. - Configure access controls to restrict connections based on time, device, and user identity. - Enforce MFA for all remote access mechanisms.

Disable Unnecessary Services:

- Identify running services using tools like netstat (Windows/Linux) or Nmap. - Disable unused services, such as Telnet, FTP, and legacy SMB, to reduce the attack surface. - Use firewall rules to block traffic on unused ports and protocols.

Network Segmentation and Isolation:

- Use VLANs, firewalls, or micro-segmentation to isolate critical network resources from general access. - Restrict communication between subnets to prevent lateral movement.

Monitor and Log Access:

- Monitor access attempts to file shares, RDP, and remote network resources using SIEM tools. - Enable auditing and logging for successful and failed attempts to access restricted resources.

*Tools for Implementation*

File Share Management:

- Microsoft Active Directory Group Policies - Samba (Linux/Unix file share management) - AccessEnum (Windows access auditing tool)

Secure Remote Access:

- Microsoft Remote Desktop Gateway - Apache Guacamole (open-source RDP/VNC gateway) - Zero Trust solutions: Tailscale, Cloudflare Zero Trust

Service and Protocol Hardening:

- Nmap or Nessus for network service discovery - Windows Group Policy Editor for disabling SMBv1, Telnet, and legacy protocols - iptables or firewalld (Linux) for blocking unnecessary traffic

Network Segmentation:

- pfSense for open-source network isolation

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
2.0
Created
Modified
Raw hash
b11989e0758bfe3d...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 2.0 Current bundle b11989e0758b…
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.

Open mirrored raw JSON Open MITRE-hosted copy
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]
    AppSecco Kubernetes Namespace Breakout 2020

    Abhisek Datta. (2020, March 18). Kubernetes Namespace Breakout using Insecure Host Path Volume — Part 1. Retrieved January 16, 2024.

    Open source URL
  2. [2]
    Docker Container

    DockerDocs. (n.d.). Retrieved December 8, 2025.

    Open source URL
  3. [3]
    Kubernetes Dashboard

    The Kubernetes Authors. (n.d.). Kubernetes Web UI (Dashboard). Retrieved March 29, 2021.

    Open source URL
  4. [4]
    Kubeflow Pipelines

    The Kubeflow Authors. (n.d.). Overview of Kubeflow Pipelines. Retrieved March 29, 2021.

    Open source URL
  5. [5]
    Kubernetes Workload Management

    Kubernetes. (n.d.). Workload Management. Retrieved March 28, 2024.

    Open source URL
  6. [6]
    Aqua Build Images on Hosts

    Assaf Morag. (2020, July 15). Threat Alert: Attackers Building Malicious Images on Your Hosts. Retrieved March 29, 2021.

    Open source URL
  7. [7]
    mitre-attack T1610
    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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use