---
{
  "title": "Build Image on Host",
  "summary": "Building an image on a host creates a workload artifact locally rather than retrieving the completed image from a registry.",
  "topic": "soc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    6
  ],
  "aliases": [
    "T1612"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1612: Build Image on Host",
      "url": "https://attack.mitre.org/techniques/T1612"
    }
  ],
  "editorialVersion": 2
}
---

## A workload can be assembled locally

Building an image on a host creates a container workload artifact from a build definition and its inputs. Development and deployment pipelines do this routinely. In an intrusion, an actor may use local building to introduce unwanted content without retrieving an already assembled malicious image from a registry.

This matters because monitoring only registry pulls can miss important parts of the workload's origin. A familiar base image does not establish the trustworthiness of later layers, files, commands, or build inputs added on the host.

## Follow the build rather than the label

In a fictional container environment, a host creates a new image outside the normal pipeline and then starts a workload from it. The analyst examines the build request, initiating identity, build definition, input sources, resulting image identifier, and deployment activity.

A developer might have performed approved troubleshooting. The team checks the service owner's explanation and whether the build was permitted on that host. A harmless base image and a plausible tag are insufficient evidence because tags can be reused and the resulting content can differ.

Where available, preserve the build context and resulting image metadata through controlled handling. Do not execute an unfamiliar image on a production host simply to inspect it. Analysis should use an authorized isolated process appropriate to the potential risk.

## Connect the artifact to execution

Building an image establishes creation, not necessarily execution. Deployment records and runtime telemetry can show whether a container used the resulting image, which configuration it received, and what it did. Record those stages separately.

Review permissions available to the builder and deployed workload. Access to a build service or container-management interface can be powerful, but the actual effects depend on configuration and granted authority. Avoid assuming that all local image builds imply host compromise.

[[deploy-container]] describes workload introduction, while [[container-administration-command]] addresses commands through management interfaces. Together, the notes help distinguish related but different actions.

## Address the unauthorized path

Restrict the affected build or deployment authority as justified, preserve relevant records, and review workloads derived from the image. Removing an image tag may not remove already running containers or other references to the same artifact.

For practice, compare an approved pipeline build with a fictional interactive build on a production node. Identify the provenance, identity, and runtime records needed to determine whether the second action was authorized. Explain why an image name alone cannot establish its contents. [[logs-and-telemetry]] supports the evidence review, and [[incident-response]] coordinates changes affecting running services.

## Related concepts

- [[mitre-attack]]