Deploy Container (T1610) is an Execution technique on the Containers platform. Adversaries deploy a container into an environment to run their code or to dodge defenses.
A container is a convenient package for an attacker. It can run a specific image, or be started without the network rules and user limits that protect your normal workloads.
How attackers use it
MITRE describes two broad purposes. In some cases the adversary deploys a new container to execute processes tied to an image or deployment, such as ones that run or download malware. In others, the container is configured without network rules, user restrictions and similar controls so that it bypasses defenses already in place. In Kubernetes, an adversary may try to place a privileged or vulnerable container on a specific node in order to Escape to Host and reach other containers on that node.
Deployment can happen through:
- Docker's create and start APIs.
- A web application such as the Kubernetes dashboard or Kubeflow.
- Kubernetes workloads such as ReplicaSets or DaemonSets, which can spread containers across many nodes.
The container may come from a retrieved or built malicious image, or from a benign image that downloads and runs a malicious payload at runtime.
Documented examples on the page: Doki and Kinsing ran through deployed containers. Peirates can deploy a pod that mounts its node's root file system and then run a command to create a reverse shell on the node. Salt Typhoon enabled Linux containers on victim network devices using the guestshell enable command. TeamPCP deployed privileged DaemonSets to delete files on targeted clusters. TeamTNT deployed different container types for execution and moved cryptocurrency mining software to Kubernetes clusters found in local IP ranges.
How to detect it
MITRE's behavior chain describes a remote or API driven creation and start of a container whose image is not on an allow list (or is tagged latest), run by a non-admin principal, and or started with risky runtime attributes such as the privileged flag, host process or network namespaces, sensitive host path mounts or added capabilities. Correlate create, then start, then the container's first network and process actions within a short time window.
Practical signals:
- Container creation by an identity that has never created containers before.
- Images from registries outside your approved list, or images with the latest tag.
- New pods that request privileged mode, host namespaces, host path mounts or extra capabilities.
- DaemonSets created outside change windows. A DaemonSet places a pod on every node.
- Outbound connections from a brand new container within seconds of starting.
How to reduce the risk
MITRE lists these mitigations:
- Least privilege on dashboards and APIs. Limit container dashboard access to the users who need it. Avoid wildcard permissions and the system:masters group, and prefer RoleBindings over ClusterRoleBindings.
- Scan images before deployment and block those that fail policy. In Kubernetes, an admission controller can validate images after a deployment request is authenticated and before the container is deployed.
- Segment the network. Deny direct remote access to internal systems through proxies, gateways and firewalls.
- Secure the container APIs. Use local Unix sockets or SSH, require TLS, and disable unauthenticated access to the Docker API, the Kubernetes API server and orchestration web applications.
The demo below walks through scanning a container image before it is deployed.
Check your own environment
Read-only checks (Docker on Linux, Kubernetes with kubectl):
# Docker: list containers with name, image and whether they run privileged
docker ps --format '{{.Names}} {{.Image}}'
docker ps -q | xargs -r docker inspect --format '{{.Name}} privileged={{.HostConfig.Privileged}}'
# Kubernetes: list DaemonSets across all namespaces
kubectl get daemonsets -A
# Kubernetes: list images in use
kubectl get pods -A -o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' | sort -u
Then ask:
- Is there an allow list of registries, and is it enforced at admission?
- Who is allowed to create pods and DaemonSets in each namespace?
- Is the Kubernetes dashboard exposed, and who can reach it?
- Do any running images use the latest tag?
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Why is a DaemonSet a worrying thing to see created unexpectedly?
A DaemonSet runs a pod on nodes across the cluster, so a malicious one can reach many nodes at once. MITRE lists TeamPCP deploying privileged DaemonSets to delete files.
Where does MITRE suggest checking images?
Before deployment. Scan images and block non-compliant ones, and in Kubernetes use an admission controller to validate images before the container is deployed.
