T1610
Deploy Container
Containersnothing on this site yetT1610 on attack.mitre.org
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.
If this is happening now
Checklists and playbooks to open while the alert is still live.
Playbook for this stage
Suspicious execution on an endpoint
An EDR alert, an unexplained process, or a user reporting something odd.
how MITRE says to see it
Behavior-chain detection for T1610 Deploy Container across Docker & Kubernetes control/node planes
- 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).
what reduces it
- M1018 User Account Management. 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.
- M1047 Audit. 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.
- M1030 Network Segmentation. Deny direct remote access to internal systems through the use of network proxies, gateways, and firewalls.
- M1035 Limit Access to Resource Over Network. 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.