DET0459: Detection Strategy for Build Image on Host
DET0459 is a detection strategy entry for ATT&CK technique T1612, Build Image on Host. The practical issue is that a container image can be built directly...
Analyst context for executives and security teams
DET0459 is a detection strategy entry for ATT&CK technique T1612, Build Image on Host. The practical issue is that a container image can be built directly on a host instead of being pulled as a finished image from a registry, which can reduce the value of controls that focus mainly on registry downloads. For leaders, this matters because container security coverage may look stronger on paper than it is if build activity on hosts and Docker API usage are not monitored.
Executive priority
Prioritize validation of container build visibility where containers are used. Ask whether security controls can distinguish normal developer or CI/CD build activity from unexpected image builds on production or sensitive hosts. This is relevant to operational resilience, incident response readiness, and audit evidence because registry scanning alone may not prove that all container image creation paths are governed.
Technical view
The supplied ATT&CK relationship says this detection strategy detects T1612, Build Image on Host, under the stealth tactic for Containers. SOC and detection teams should validate whether they collect evidence of container image build activity on hosts, including Docker API build requests and Dockerfile-driven builds that start from common base images. Because the official detection field for DET0459 is not provided, detection engineering should be based on local container architecture, expected CI/CD patterns, and known authorized build locations rather than assuming a complete ATT&CK-provided analytic.
Likely telemetry
- Container runtime or Docker daemon/API logs showing image build requests
- Host process and command execution telemetry related to container build tooling
- Container image metadata and local image creation events
- CI/CD system logs that show approved build jobs and expected build hosts
- Registry access logs for base image pulls, including public or local registry pulls
Detection direction
- Baseline where container images are normally built, especially separating CI/CD builders from production container hosts.
- Alert or review image builds on hosts that are not expected to perform builds.
- Correlate Docker API build activity with authorized users, service accounts, CI/CD jobs, and change records.
- Tune for legitimate developer and automation workflows to avoid excessive false positives.
- Do not rely only on public registry pull monitoring, because the related technique specifically concerns building a custom image on the host after pulling a base image.
Mitigation priorities
- Define and document which hosts are authorized to build container images.
- Restrict container build capability and Docker API access to approved users, service accounts, and build infrastructure where feasible.
- Use CI/CD governance and change control to make legitimate builds attributable and auditable.
- Maintain visibility into local image creation, not only registry image retrieval.
- Use incident response playbooks that include local container image inventory and build-history review when investigating suspicious container activity.
Analyst notes and limits
This object is a detection strategy with no official description or detection text supplied. The main decision value comes from its relationship to T1612, which describes adversaries building a container image directly on a host to bypass defenses focused on malicious image retrieval from public registries. Local environment context is essential because container build activity may be normal in development and CI/CD environments but unusual on production hosts.
Platforms, tactics, description, and detection are not specified on the DET0459 object itself. Container platform and stealth context come from the related T1612 technique. The supplied related description is truncated, so this take avoids adding unsupported procedural detail, attribution, prevalence, or claims of active exploitation.
Detection Strategy for Build Image on Host
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1612 | Build Image on Host | This object detects Build Image on Host. |
All related ATT&CK context
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 | 1.0 | Current bundle | 53670bad91c3… |
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]
mitre-attack DET0459Open 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.