T1612

Build Image on Host

Containersnothing on this site yetT1612 on attack.mitre.org

Adversaries may build a container image directly on a host to bypass defenses that monitor for the retrieval of malicious images from a public registry. A remote `build` request may be sent to the Docker API that includes a Dockerfile that pulls a vanilla base image, such as alpine, from a public or local registry and then builds a custom image upon it.
MITRE ATT&CK 19.2, retrieved 2026-09-12

how MITRE says to see it

Detection Strategy for Build Image on Host

Detection of container image build activity directly on the host using Docker or Kubernetes APIs. Defenders may observe Docker build requests, anomalous Dockerfile instructions (such as downloading code from unknown IPs), or creation of new images followed by immediate deployment.

what reduces it

M1035 Limit Access to Resource Over Network. Limit communications with the container service to 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 on port 2375. Instead, communicate with the Docker API over TLS on port 2376.
M1030 Network Segmentation. Deny direct remote access to internal systems through the use of network proxies, gateways, and firewalls.
M1026 Privileged Account Management. Ensure containers are not running as root by default. In Kubernetes environments, consider defining Pod Security Standards that prevent pods from running privileged containers.
M1047 Audit. Audit images deployed within the environment to ensure they do not contain any malicious components.

The description, detection analytics and mitigations are reproduced from MITRE ATT&CK, version 19.2, under its terms of use. The checklists, hunts, labs and everything else linked here are this site’s.