Container Service abuse (MITRE ATT&CK T1543.005) targets the tools that run containers on a host. These include Docker and Podman, which create and manage individual containers, and node level agents such as kubelet. Modify those services, or use them to launch workloads that persist, and an adversary can gain persistence or escalate privileges on the host.
The platform listed is Containers. The tactics are persistence and privilege escalation.
How attackers use it
MITRE gives concrete examples. Running docker run or podman run with the restart always policy makes a container restart persistently on the host. A user with access to the rootful docker command may also be able to escalate privileges on the host.
In Kubernetes, DaemonSets let an adversary deploy containers persistently on all nodes, including nodes added to the cluster later. Pods can also be placed on specific nodes with the nodeSelector or nodeName fields in the pod spec. Containers can also be set up to run as systemd services (T1543.002).
How to detect it
MITRE's detection strategy asks you to correlate several signals:
- Containers created or changed with restart policies such as always, or DaemonSets that have elevated host access.
- Service account misuse and privileged container contexts.
- Changes to systemd units that involve containers, or pod scheduling aimed at particular nodes or namespaces.
A DaemonSet that nobody on the platform team can explain is the clearest cluster signal. On a single host, a rootful container with a restart policy that was not part of a deployment is the equivalent.
How to reduce the risk
- Use rootless mode where possible. MITRE recommends enforcing rootless container services to limit privilege escalation and malicious effects on the host.
- Limit access to container tools. Restrict utilities such as docker to people who need them, especially in rootful mode.
- Restrict pod deployment. In Kubernetes, grant the right to deploy pods only to users who require it.
Image content matters too. A container that persists because of a restart policy still runs whatever is in the image, so scanning images for vulnerable or malicious packages shrinks what a persistent container can do.
Check your own environment
Read-only commands for Docker and Kubernetes:
docker ps --format '{{.Names}} {{.Image}}'
docker inspect --format '{{.Name}} {{.HostConfig.RestartPolicy.Name}} {{.HostConfig.Privileged}}' $(docker ps -q)
kubectl get daemonsets --all-namespaces
For each result, confirm there is an owner, a deployment record and a reason for any privileged flag or host access.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Why are Kubernetes DaemonSets attractive for persistence?
They deploy a container on every node, including nodes added to the cluster later, so removing one pod does not remove the foothold.
What does rootless mode change?
A container service running without root limits how far a compromised container can reach into the host, which reduces privilege escalation.
