T1612: Build Image on Host
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.[1]
An adversary may take advantage of that build API to build a custom image on the host that includes malware downloaded from their C2 server, and then they may utilize Deploy Container using that custom image.[2][3] If the base image is pulled from a public registry, defenses will likely not detect the image as malicious since it’s a vanilla image. If the base image already resides in a local registry, the pull may be considered even less suspicious since the image is already in the environment.
Analyst context for executives and security teams
Build Image on Host matters because it can shift container risk from “did we pull a bad image?” to “can someone make a bad image inside our environment?” An attacker with access to the Docker API may request an image build on a container host using a normal-looking base image, then add malicious content during the build. For leaders, the key issue is whether container defenses only trust registry scanning and image pull monitoring, or whether they also govern and audit who can build images on hosts.
Executive priority
Prioritize this where container hosts or Docker APIs are reachable by users, services, or automation. The business risk is a blind spot in supply-chain and runtime controls: a vanilla base image from a public or local registry may appear acceptable, while the dangerous customization happens locally. Executives should ask whether privileged access to container build functions is restricted, whether Docker/API access is segmented, and whether audit evidence exists for remote build requests and subsequent container deployment activity.
Technical view
For SOC, detection engineering, and IR teams, validate visibility around container-host image build activity, especially remote Docker API build requests that include Dockerfiles and pull common base images such as alpine. Because ATT&CK provides no official detection text for T1612, use the related detection strategy DET0459 as the starting point, then test whether telemetry can connect an image build event to later Deploy Container behavior using the newly built custom image. Investigations should distinguish approved CI/CD or administrative builds from unexpected builds initiated through host-exposed APIs or unusual privileged accounts.
Likely telemetry
- Docker Engine API activity, especially image build requests
- Container host audit logs showing image build operations
- Dockerfile or build-context metadata where retained or logged
- Image creation metadata, image tags, and base image references
- Registry access logs for public or local base-image pulls
Detection direction
- Confirm whether container monitoring covers local image builds, not only pulls from public registries.
- Baseline legitimate build sources, such as CI/CD systems and authorized administrators, to reduce false positives.
- Alert on remote build requests to Docker APIs from unexpected users, hosts, or network segments.
- Correlate build events that use benign base images with later deployment of the resulting custom image.
- Review whether locally cached or locally registered base images create monitoring gaps because no suspicious external pull occurs.
Mitigation priorities
- Restrict privileged access to container build capabilities using privileged account management, RBAC, least privilege, and accountability logging.
- Limit network access to Docker APIs and container-host management services to systems with a legitimate business requirement.
- Apply network segmentation so container management interfaces are not broadly reachable across the environment.
- Audit container host configuration, privileged account use, API exposure, and image build activity on a recurring basis.
- Ensure compliance evidence includes who can build images on hosts, where build requests can originate, and whether build activity is reviewed.
Analyst notes and limits
This technique is specific to container environments and is categorized under the stealth tactic. Its practical significance is that malicious customization may occur during host-side image build rather than through retrieval of an obviously malicious image. The supplied relationships identify privileged account management, network segmentation, limiting network access to resources, and auditing as relevant mitigation directions.
The ATT&CK object does not provide official detection text, procedures, affected software, or attribution. This take therefore avoids claims about active exploitation or guaranteed coverage. Local validation is required to determine whether Docker API logs, host audit records, registry logs, and container runtime events are collected and retained.
Build Image on Host
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.[1]
An adversary may take advantage of that build API to build a custom image on the host that includes malware downloaded from their C2 server, and then they may utilize Deploy Container using that custom image.[2][3] If the base image is pulled from a public registry, defenses will likely not detect the image as malicious since it’s a vanilla image. If the base image already resides in a local registry, the pull may be considered even less suspicious since the image is already in the environment.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.0 | Current bundle | 8ffbcbb1cbf4… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Docker Build Image
Docker. ( null). Docker Engine API v1.41 Reference - Build an Image. Retrieved March 30, 2021.
Open source URL -
[2]
Aqua Build Images on Hosts
Assaf Morag. (2020, July 15). Threat Alert: Attackers Building Malicious Images on Your Hosts. Retrieved March 29, 2021.
Open source URL -
[3]
Aqua Security Cloud Native Threat Report June 2021
Team Nautilus. (2021, June). Attacks in the Wild on the Container Supply Chain and Infrastructure. Retrieved August 26, 2021.
Open source URL -
[4]
mitre-attack T1612Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.