MITRE ATT&CK T1612 Build Image on Host: Catching Images That Never Came From Your Registry

Registry scanning and image allowlists assume every image arrives by being pulled, so an image built directly on a host can slip past both. MITRE ATT&CK T1612 Build Image on Host covers adversaries sending a build request to the Docker API with a Dockerfile that starts from a vanilla base image, such as alpine, and adds malware fetched from their own infrastructure, then running the result with T1610 Deploy Container. In ATT&CK v20 it sits in the Stealth tactic (TA0005), applies to the Containers platform and has no sub-techniques. This guide is for detection engineers, platform and CI/CD owners and cloud security teams. It explains the technique at the level of the ATT&CK description, then concentrates on detection logic, log sources, controls on who can build where, the build identity angle and response. It contains no attack procedures. For image supply chain controls, see the Container Image Security Guide.

Key takeaways

• It is a stealth technique, not an exploit. ATT&CK classes T1612 under Stealth because the base image is benign and may already be in a local registry, so pull-based defences see nothing unusual.
• Builds belong in pipelines, not on runtime hosts. A production node or Docker host that accepts build requests is the root condition; ATT&CK's mitigations are about limiting who can reach the daemon (M1035, M1030, M1026) and auditing it (M1047).
• Detect build plus egress plus run. ATT&CK detection strategy DET0459 correlates a docker build or POST /build request with outbound connections during the build and immediate deployment of the new image.
• Provenance beats name matching. Aqua's research found host-built images can carry random names per host, so allowlists by name fail; require signed digests from your own pipeline at admission.
• The build identity is an NHI. CI runners and build service accounts that can reach a daemon or push to a registry are privileged non-human identities and need the same governance as admin accounts.

How the attack works

ATT&CK describes a remote build request to the Docker API containing a Dockerfile that pulls a vanilla base image and builds a custom image upon it that "includes malware downloaded from their C2 server". Aqua Security's Team Nautilus reported the approach in the wild in July 2020 against misconfigured Docker API endpoints: an Alpine-based image built on the target host whose build fetched a script that then downloaded a cryptominer. Aqua described it as, to its knowledge, the first time such a build-on-host approach had been seen. The reasons it evades controls are worth stating precisely:

T1612 is normally one link in a chain: initial access through an exposed daemon (T1133 External Remote Services or T1190 Exploit Public-Facing Application), the build, T1610 Deploy Container, then T1496.001 Compute Hijacking or credential theft. In Kubernetes the equivalent risk appears when in-cluster build tools or a node's container runtime can be driven by an untrusted identity.

Where it shows up

• Exposed Docker daemons: the Aqua case and the wider class of cryptomining campaigns that target unauthenticated Docker APIs, such as the TeamTNT worm. See the TeamTNT worm breach analysis.
• Shared CI runners: runners with the host Docker socket mounted, where one malicious job can build and run images on the runner host.
• Developer and build VMs: long-lived build servers with Docker exposed on the network for convenience.
• In-cluster builders: build pods (for example rootless BuildKit or kaniko) whose service accounts or registry credentials are broader than the build needs.

Detection

DET0459 "Detection Strategy for Build Image on Host" has one analytic, AN1261, built on two log sources: Docker daemon records of docker build or a POST /build API request, and network flow data showing outbound connections from the host during or immediately after the build. It suggests watching for anomalous Dockerfile instructions, such as downloads from unknown IP addresses, and for new images that are deployed straight away.

Rules to build first

1. Any image build on a production node or non-build Docker host. On hosts that should never build, this rule has near-zero false positives.
2. Remote Docker API connections from addresses other than approved management systems, and any listener on unauthenticated TCP 2375.
3. Running container whose image has no registry digest or no valid signature from your pipeline.
4. Build host egress to destinations outside the allowlisted mirrors.
5. Socket access by unexpected processes, including containers with /var/run/docker.sock mounted.

Measuring it

• Exposed daemons: count of Docker API endpoints reachable from outside the host without TLS client authentication (target zero).
• Provenance coverage: percentage of running containers with a signed digest from an approved pipeline.
• Build host inventory: number of hosts allowed to build, and how many builds occurred elsewhere.
• Socket mounts: number of workloads mounting the container runtime socket; trend to zero.
• Egress exceptions: build hosts with unrestricted internet egress.

Prevention and hardening

• Close the API (M1035, M1030): keep Docker on its local UNIX socket. Where remote access is needed, Docker documents SSH or TLS with tlsverify and a trusted CA. Aqua recommends never exposing the API on an unauthenticated port, using mutual TLS with IP restriction, and firewalling and segmenting Docker hosts. See the Container Runtime Security Guide.
• Separate build from run: build only on dedicated, ephemeral CI runners; runtime nodes should have no build tooling and no exposed daemon.
• Restrict daemon access (M1026): membership of the docker group is effectively root on the host; keep it to named administrators and automation.
• Admission by provenance: require images from your registry with verified signatures and attestations, rejecting local-only images. See the Kubernetes Admission Control Guide.
• Egress control: build hosts reach only package mirrors and registries; runtime nodes deny by default. Aqua highlights egress restriction as the control that blocks payload download.
• Audit (M1047): regularly scan for exposed daemon ports, unexpected images and running containers, as Aqua recommends.

Rollout

1. Scan internal and external ranges for Docker API listeners and close or put TLS on each.
2. Inventory hosts with build tooling; remove it from runtime nodes.
3. Turn on provenance admission in audit mode and list unsigned images.
4. Fix pipelines to sign every image, then enforce in a pilot namespace and widen.
5. Keep a documented, time-limited exception path; roll back by switching the policy to audit mode.

Where identity fits

Builds run as someone. On a Docker host that is whoever can reach the socket; in a pipeline it is the CI runner's identity, its registry push credential and any cloud role it assumes. These non-human identities decide whether a host-built image can run and whether it can reach production. Give each pipeline its own short-lived registry credential through workload identity federation rather than a shared static token, limit push rights to the repositories that pipeline owns, and keep signing keys out of reach of build jobs. See the CI/CD Pipeline Identity Security Guide and the Docker Hub Tokens Security Guide.

Responding to a host-built image

1. Preserve: save the image and its build history, and capture the daemon logs and network flow for the build window before cleaning up. See the Container and Kubernetes Forensics Guide.
2. Contain: stop containers using the image, close the daemon endpoint and isolate the host.
3. Trace the requester: the remote address or local process that called the build API, and the identity behind it.
4. Rotate: any credential on the host, including cloud keys, registry tokens and SSH keys.
5. Hunt across the estate for the same Dockerfile steps, destinations and image IDs; follow the Kubernetes Cluster Compromise Playbook where clusters are affected.

Common failure patterns

• Daemon on TCP for convenience: a build VM or lab host exposes the API without TLS and later joins a production network.
• Name-based allowlists: policies that trust alpine or a local tag rather than a signed digest.
• Socket mounted in CI: shared runners mount the host socket, so any job can build and run on the host.
• Scan once, trust forever: images are scanned only in the registry, never at runtime.
• Unlimited build egress: build hosts can reach any internet destination.

Framework mapping

Practitioner checklist

• Confirm no Docker API is reachable over the network without TLS client authentication.
• Remove build tooling and runtime socket mounts from production nodes and shared runners.
• Designate build hosts and alert on any build anywhere else.
• Enforce signed-digest admission from your own registry.
• Restrict build host egress to approved mirrors and registries.
• Give each pipeline a scoped, short-lived registry identity.
• Collect Docker daemon logs and network flows from container hosts in the SIEM.

Standards and references

• MITRE ATT&CK: Build Image on Host (T1612)
• MITRE ATT&CK: Deploy Container (T1610)
• Docker: Protect the Docker daemon socket
• Aqua Security: Malicious container images built directly on Docker hosts
• Kubernetes: Auditing
• AWS: Send control plane logs to CloudWatch Logs (Amazon EKS)
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Container Image Security Guide · Container Registry Security Guide · Container Runtime Security Guide · CI/CD Pipeline Identity Security Guide · Container Security Guide