Malicious Image (MITRE ATT&CK T1204.003) is a sub-technique of user execution. The adversary relies on a user running a backdoored image. MITRE files it under Execution and lists Containers and IaaS as platforms.
If you run containers or cloud virtual machines from images you did not build, this one applies to you.
How attackers use it
MITRE says images for Amazon Web Services (AMIs), Google Cloud Platform and Azure, and for container runtimes such as Docker, can be backdoored. A backdoored image may be uploaded to a public repository, and users may download it and deploy an instance or container without realizing it is malicious. That bypasses techniques aimed at initial access, because the victim starts the code themselves. The resulting code may do things such as mine cryptocurrency inside the instance or container.
Adversaries may also name images in ways that make users deploy the wrong one by mistake, by matching a legitimate resource name or location.
How to detect it
MITRE's detection strategy treats containers and IaaS separately.
Containers (Docker, Kubernetes, containerd). A user pulls an untrusted image from a public or unknown registry, then creates and starts a container from it. Shortly after start, the container runs unexpected utilities (curl, wget, bash, python) or makes outbound connections that do not fit the namespace or workload. The analytic correlates image download, container creation, container start, and command execution or network activity within a short window and for a consistent image digest.
IaaS. A new instance launches from an image that is not approved or has not been seen before. On first boot, cloud-init or user-data scripts, or embedded agents, download code, run system utilities or open outbound command and control or mining traffic. The analytic correlates image or instance creation, instance start, and in-guest process or network behavior.
What you need in place: logs of image pulls with registry and digest, admission or audit logs from the orchestrator, cloud audit logs for instance and image creation, and egress flow logs.
How to reduce the risk
MITRE's mitigations:
- Audit images deployed in the environment to be sure they hold no malicious components.
- Use code signing. A trust model such as Docker Content Trust uses digital signatures to verify the integrity and publisher of specific image tags at runtime.
- Use network intrusion prevention and systems that scan and remove malicious downloads.
- Train users to know that malicious images exist and how to avoid deploying from them.
Check your own environment
- Which registries can your clusters and developers pull from? Is it limited to approved ones?
- Do you pin images by digest, or by a tag that can change?
- Are cloud accounts limited to a list of approved machine images?
- Do you scan images before they run, and again later as new findings appear?
- Do containers have unrestricted outbound access?
Read-only commands. List local images with their digests (Docker):
docker images --digests
Check whether Docker Content Trust is enforced in the current shell. A value of 1 means enabled:
echo $DOCKER_CONTENT_TRUST
Inspect signature data for an image tag (replace the name with your own image):
docker trust inspect --pretty registry.example.com/team/app:1.0
Try it yourself
This demo shows what scanning a container image looks like and what a finding tells you.
Click through it at your own pace, or open it full screen.
Quick check
Why does a malicious image bypass initial access defenses?
The user pulls and starts the image themselves, so the attacker's code runs inside your environment without a separate break-in.
What is the point of Docker Content Trust in this context?
It uses digital signatures to verify the integrity and publisher of specific image tags at runtime.
What chain does the container detection correlate?
Image pull, container creation, container start, and then unexpected commands or network connections for the same image digest.
