How T1612 build image on host shows up on container hosts
For an attacker, T1612 Build image on host, listed under the Stealth tactic (TA0005), means assembling a container image directly on a host instead of moving it through the normal registry path. The payoff is concealment: an image built locally can avoid the checkpoints the organization assumes every image passes, such as registry scanning and admission controls. This section and the rest of the page target ATT&CK v20.0 and cover container hosts only. T1612 has no sub-techniques, so detection logic can be written against the technique as a whole. In intrusions, it often appears after an initial foothold on a build or application host where a container runtime and build tooling are already present.
The difficulty is that legitimate build pipelines produce the same activity. Developers run local builds, CI runners construct images on shared hosts, and platform teams rely on build agents that call the container runtime all day. A SOC analyst looking at one build event on a container host has little to separate a sanctioned engineer from an intruder. Context carries the decision: which account started the build, whether the host is meant to build images at all, whether the base image and build inputs match an approved pipeline, and whether a matching image later appears in a registry. In an illustrative case, a build on a developer workstation that is never pushed anywhere deserves a different response than the same build on a production node. Confirm with your platform team which hosts are approved builders before tuning any alert.
Start with an inventory. Ask your platform team to name the container hosts sanctioned to build images, the service accounts that run builds there, and the registries those builds push to. Then confirm that your telemetry records Network Connection Creation (DC0082) and image creation events on those hosts, and that retention covers enough history to baseline normal build activity. Any build on a host outside that inventory is a question to answer before it becomes an incident. Plan to validate the detection in a private cyber range against your own container runtime and build tooling before it runs in production, and record which findings were expected and which were not.
Telemetry that reveals T1612 and the open-source tools that collect it
This table maps each behavior that can reveal T1612 Build Image on Host to the telemetry source that records it and the open-source collector that gathers it. Read each row as a candidate signal, then check the listed item before writing rules against ATT&CK v20.0. The main takeaway is that no single source is enough: registry contact, build activity and new image records should be correlated on the same container host.
| Signal | Telemetry source | Open-source collector | Confirm before rules ship |
|---|---|---|---|
| Registry contact before a local build | Network Connection Creation (DC0082) | Zeek connection and TLS metadata, Suricata alerts on registry hostnames | Approved registry hostnames for your estate and expected pull paths |
| New image records with no matching registry push | Image Creation (DC ID to confirm) | Wazuh log collection from container runtime logs, Falco runtime events where rules cover image events | That your runtime emits image creation events and which rule names apply |
| Build tool execution on a container host | Process Creation (DC0032) | auditd execution records forwarded to Wazuh, Falco process events | Which build binaries to monitor and how auditd rules are scoped |
| New build context files written to disk | File Creation (DC0039) | Wazuh file integrity monitoring on build directories, Falco file events | Build directory paths and noise from normal CI workspaces |
| Build activity from unexpected or privileged accounts | Runtime API audit logs and host authentication records | Wazuh collection of audit logs, Kubernetes audit logs where the cluster provides them | Account inventory and which roles should never trigger builds |
| Data component IDs for rule mapping | ATT&CK v20.0 STIX bundle for enterprise-attack | attack-stix-data repository used to verify DC IDs and detection mappings | Confirm every DC ID in the v20.0 bundle before writing detection rules |
Detection logic for T1612 on container hosts
T1612 Build Image on Host shows up as image creation that does not match an approved build path. The cards below describe detection logic in words, with the thresholds to tune and the false positives to expect, so each rule can be written in Sigma and tested against ATT&CK v20.0 mappings. Tune every threshold against your own build history before alerting.
Image creation without a pipeline job
Flag image creation events on a container host that cannot be tied to a recorded CI pipeline job or an approved build request within the same time window. Correlate Image Creation records with the build system's job log by host name, image digest and build identifier. The main signal is the unmatched record, so check whether your pipeline stamps a build identifier into image metadata. Expect false positives from CI runners that build outside the tracked system and from developers who run local builds on shared hosts. Allowlist known runner hosts explicitly rather than broadly.
Build activity from unexpected service accounts
Alert when a build or image creation event is initiated by an account that is not in the approved build service account list for that host. Compare the initiating account against directory group membership and against the accounts your pipeline is documented to use. Privileged accounts that can run builds should be rare, so any build from a human administrator account on a production host deserves review. False positives come from platform engineers running manual rebuilds during incidents, so require a change or incident reference for those runs.
Build-related connections to unapproved destinations
Look for Network Connection Creation events from a build process to registries, package sources or endpoints that are not on your approved list. Build jobs normally pull base images and dependencies from known hosts, so a new destination is a useful pivot. Keep the baseline per build runner and review destinations that appear only once. Expect false positives from new upstream package mirrors, vendor-hosted base images and dependency updates, so route first-seen destinations to a review queue before paging anyone.
Image creation bursts outside maintenance windows
Set a threshold on the count of image creation events per host within a rolling window, and alert when the count exceeds the historical maximum for that host outside its scheduled maintenance window. Tune the window length and the count against at least several weeks of baseline data, since scheduled rebuilds and nightly base image refreshes produce regular bursts. Expect false positives from scheduled rebuilds that are moved, from security patch rebuilds triggered by an advisory, and from clock skew between hosts. Confirm the maintenance calendar with the platform team before enabling the rule.
How to validate that the T1612 detection fires
This sequence proves that the T1612 detection fires on a non-production container host, that each expected event reaches the SIEM, and that the results are recorded against a named ATT&CK version so the detection can be re-tested after every rule change.
Define the test scope and boundaries
The detection owner and the platform team agree in writing which non-production container host, namespace and build pipeline the test may touch, and which actions are out of bounds. The scope also names the ATT&CK technique (T1612 Build image on host), the target ATT&CK version and the telemetry sources expected to be in play, such as Network Connection Creation and Image Creation. The step is done when the scope document is signed off by both the owning team and the security lead, and nothing in it touches production images or registries.
Agree the emulated behavior with the owning team
Security engineers and the owners of the container platform agree, in plain language, the behavior the emulation will represent: a build activity on a host that the team would not normally expect to build images there. The owners confirm which alerts they expect to see, which logs they can read, and who watches the lab while it runs. Describe the behavior in words only, without commands or payloads, and keep a written record of the agreed expectations. The step is complete when each expected event has a named owner and a named SIEM location.
Run the emulation inside the cyber range
A tester runs the agreed emulation inside the private cyber range against the non-production container host, following the scope document and within the time window the owners approved. A second person keeps a timestamped log of what was executed and when, so that events in the SIEM can be matched to test actions later. The step is done when the run ends, the test log is saved, and the host is returned to its baseline state for the next run.
Confirm each expected event reaches the SIEM
The analyst checks, event by event, that the telemetry expected for T1612 (such as Network Connection Creation and Image Creation) arrived in the SIEM, for example in Wazuh or Security Onion, with the right host, container and timestamp fields. Missing or malformed events are logged as collection gaps, separate from detection gaps, because they point to agent, log forwarding or parsing problems. The step closes when every expected event is either present or recorded as a gap with a suspected cause.
Measure latency, fidelity and gaps
The analyst compares the time of each test action with the time the detection alert was created, which gives detection latency, and reviews each alert for fidelity: whether it fired on the intended behavior, whether it fired on unrelated activity, and whether it included enough context to triage. Any action that produced no alert is recorded as a detection gap with the telemetry that was available. The step is done when the results are in a table with latency, fidelity and gap entries for every test action.
Re-run the test after rule changes
Each time a detection rule, decoder, threshold or data source changes, the same emulation is repeated on the same non-production host so results can be compared with the previous run. The team compares the new results with the saved baseline and confirms that fixes closed the earlier gaps without creating new false positives. The step is complete when the re-run shows the expected alerts and the comparison is filed with the rule change record.
Log results against the ATT&CK version
The team records each validation run with the ATT&CK version it targeted, the rule identifiers, the technique and sub-technique mapping, the telemetry sources and the outcome. Because ATT&CK releases can rename, deprecate or revoke techniques, the record states the version used, so a later reviewer can tell whether a mapping still applies. The step is done when the record is stored with the detection documentation and linked from the page used for audit evidence.
Preventive controls that limit T1612
Two ATT&CK mitigations shape how hard it is for an adversary to build an image on a container host. Audit gives you the record needed to spot image builds, while Privileged Account Management restricts who can run the build tooling in the first place. Scope both to the hosts that run container workloads and keep the evidence that proves they work.
Audit (M1047) scope for build activity
The Audit mitigation is about making sure the host records the activity that a build generates, so detections have something to read. For T1612, confirm that process creation and network connection events are logged on every container host, and that build tooling invocations are included rather than filtered out as routine. Check that logs are forwarded off the host, since a local log an attacker can edit does not support investigation. Ask your platform team to show a sample build event reaching your SIEM.
Audit evidence to retain
Keep configuration evidence showing which audit rules or logging settings apply to container hosts, who approved them, and when they last changed. Retain a periodic export of sample events from each host class so an assessor can see that logging was working during the review period. Record the retention period you chose and the storage location for those logs. Without this evidence, a claim that audit is in place cannot be verified.
Privileged Account Management (M1026) for build rights
The Privileged Account Management mitigation limits which accounts can run container build or image tooling on a host. Build capability is powerful because it can package and place code on a machine, so treat it as a privileged function. Confirm that only named operators and approved CI service accounts hold it, and that interactive use of those accounts is logged. Review the list on a set schedule and remove accounts that no longer need the role.
Privileged account review evidence
Keep the current list of accounts with build rights, the owner of each entry, and the record of each access review with its reviewer and outcome. Retain approvals for any grant made outside the standard process. Include CI service accounts, since they are often overlooked during reviews. Auditors and internal reviewers will ask for this list alongside a sample of privileged logins, so keep both in the same evidence folder.
Separate build and runtime hosts
Where the design allows, keep image builds on dedicated build hosts or build runners instead of production container hosts. This reduces the number of machines where the build capability exists and makes any unexpected build event on a production host stand out. Confirm with your platform team which hosts are permitted to build, and alert on builds elsewhere. Document this boundary in the architecture record so it survives staff changes.
What the SOC does when a T1612 alert fires
The first decision on a T1612 alert is whether the image build is authorized, so the SOC should start by checking the build against the approved pipeline. Compare the build event with the CI/CD system's run records for the same time window, confirm the pipeline definition and commit that should have produced the image, and check whether the build agent is one your platform team manages. If no approved run explains the build, treat it as a suspicious event immediately. Next, identify the account and host that executed the build: the user or service account in the container runtime or orchestrator audit log, the node where the build ran, and the source of any remote API session. Record the account's recent role changes and whether it is a privileged account, because that determines how far the investigation must widen.
Preserve evidence before anything changes. Export the image creation events, the image digest and manifest, the build log and the Dockerfile or build context referenced by the event, and copy them to write-once storage with hashes recorded. Pull the host's container runtime and orchestrator logs for the same window, and snapshot the node's relevant state where your forensic procedure allows it. Check outbound connections from the build host and any registries it contacted using network connection telemetry, looking for destinations that do not appear in your baseline for build traffic. Confirm which image tags or deployments reference the new digest, so the SOC knows whether anything has already been promoted.
For containment, prefer restricting the account's privileges, blocking the suspect host's outbound egress, and cordoning the node from new scheduling over deleting the container or powering the host off, since termination can destroy memory and runtime evidence. Isolation decisions should weigh whether the host runs production workloads, which the platform owner must confirm before isolation. Escalate to incident response once the build is confirmed unauthorized or the outbound review shows unexplained destinations, and hand over the preserved evidence, the timeline, the affected accounts and the list of images and deployments that reference the suspect digest. Agree in advance with your incident response lead who may approve isolation out of hours.
Rehearsing T1612 detection in a private cyber range
The range should mirror the container hosts your organization operates, but sit fully isolated from production networks, credentials and log pipelines. The goal is to generate realistic telemetry for T1612 Build Image on Host on Containers while keeping every exercise contained. Confirm the range design with your own security and network teams before any build activity runs.
- Container hosts: Provision container hosts that match your production runtime and build tooling, with the same logging agents and audit configuration you intend to deploy.
- SIEM: Run Wazuh as the central collector and rule engine, with agents on each host and a separate index or tenant for range data so exercise events never mix with production records.
- Network sensors: Place Zeek or Suricata on the range segment to record network connection creation, so detections can be compared across host and network telemetry.
- Isolation controls: Confirm that the range has no routes to production, no shared identity sources and no reused secrets, and document these checks in writing.
- Baseline capture: Record a clean baseline of normal build activity before injects begin, so analysts can tell routine pipeline events from exercise activity.
Before the first exercise, ask your platform team to confirm which Wazuh rule sets, decoders and audit settings they plan to use, and which Zeek or Suricata versions they will run.
Injects are scripted events that the blue team does not know in advance. For T1612, the useful injects separate routine builds from activity that should raise questions. Describe each inject as a planned event in the exercise plan, and have the exercise lead record the time and expected result of every inject so the team can score the outcome later. No commands or payloads belong in the exercise plan itself.
- Benign build events: Schedule routine image builds from approved pipelines at normal hours, so analysts learn what expected image creation looks like in the SIEM.
- Unexpected builds: Trigger a build from a host or account that is not part of the approved pipeline, to test whether image creation telemetry is correlated with a known build source.
- Off-hours activity: Run a build outside the normal change window, to test whether timing and context enrich the alert.
- Privileged context: Vary the account that starts the build, including one with elevated rights, to check whether privileged account activity is flagged.
- Ambiguous cases: Include a build that matches the pipeline but uses an unfamiliar base image, so analysts must weigh evidence rather than apply a single rule.
Ask the exercise lead to confirm that every inject has a written owner, a start time and a stop condition before the exercise opens.
A good detection for T1612 gives analysts a clear alert, enough context to decide quickly, and a repeatable path to closure. The alert should combine image creation telemetry with network connection creation and the identity that started the activity. Analyst notes should record what was checked, not only the verdict. Use the ATT&CK version you target when you map rules, because detection strategies and data components can change between releases.
- Alert content: A useful alert names the host, the build source, the account, the image reference and the time, so the analyst does not have to pivot first.
- Timing: Alerts should fire within a window your SOC has agreed on, and the range should measure the delay from inject to alert for each scenario.
- Enrichment: Off-hours and privileged-account context should appear in the alert or in the first analyst note, not only in a later query.
- Analyst notes: Each triage note should state the evidence reviewed, the pipeline or change record checked, and the decision reached.
- Escalation: Mark which alerts go to incident response and which are closed as expected build activity, with the reason written down.
Check that each benign build closes quickly with a documented reason, and that each unexpected build reaches the escalation path your playbook defines.
Every exercise should end with a written record of what the detection missed, what it flagged wrongly and what the team will change. Treat these records as inputs to a tuning cycle, not as a pass or fail score. Map each finding to the ATT&CK mitigations that apply to T1612, namely Audit (M1047) and Privileged Account Management (M1026), so that control owners can see which gaps affect audit coverage and privileged access.
- Missed events: Record each inject that produced no alert, the telemetry source that was absent and the component responsible for collecting it.
- False positives: Record each benign build that alerted, the rule that fired and the field that caused the match.
- Audit coverage: Confirm that audit settings on the container hosts capture build events and account context, and record any gaps.
- Privileged access: Record whether privileged build activity was distinguished from routine activity, and who approves changes to that logic.
- Tuning loop: Assign each change an owner, a rule version and a retest inject, and rerun the affected scenario before closing the item.
Before closing the exercise, confirm that every finding has an owner, a target date agreed with the platform team and a retest scheduled in the range.
Practitioner questions about detecting T1612
How do I separate legitimate build pipelines from attacker-driven image builds?
Start by building an inventory of every process, service account and host that is expected to build container images, then alert on builds that fall outside that baseline. Legitimate pipelines usually run under named service identities, from known runner hosts, and against known repositories and Dockerfile paths. Attacker-driven builds tend to show a different parent process, an unfamiliar user context, a build originating from an interactive session or a base image pulled from an unexpected registry. Treat the baseline as a living artifact: review it whenever a pipeline is added, moved or retired. Expect some noise in the first weeks, and tune by allowlisting specific, documented pipeline identities rather than broad host ranges.
How should detection handle ephemeral CI runners that disappear after each job?
Ephemeral runners make host-based baselines unreliable, so anchor detections to the identity and the build event rather than to a long-lived host name. Forward process and network telemetry from the runner image or its orchestrator in real time, because an ephemeral host may be gone before a periodic agent check-in. Keep runner provisioning logs, image build records and orchestrator audit trails for long enough to correlate after the fact. Confirm with your platform team which of these sources actually exist in your environment, since runner designs vary widely.
Which telemetry should I prioritize first for T1612 on containers?
Prioritize Process Creation and Network Connection Creation, since these are the data components ATT&CK references for this technique and they are the signals most likely to reveal an image build starting outside the expected pipeline. Image Creation events from the container runtime or build tooling add the context of what was built and from which base. Collect these first on the hosts and runners that have build privileges, then extend coverage to the rest of the fleet. Verify each source against the ATT&CK version you target, because data component mappings change between releases.
How do I version detection rules against ATT&CK releases without breaking coverage?
Record the ATT&CK version each rule targets in its metadata, and check that version against the MITRE updates page whenever a new release lands. ATT&CK v18 moved technique detections into detection strategies and analytics and deprecated data sources, and later releases can rename, deprecate or revoke techniques. Maintain a mapping file that links each rule to its technique, detection strategy and data components, and diff that file against the STIX bundle for each new version. Keep rules in version control with tests, so a change in ATT&CK content produces a reviewable pull request instead of a silent gap.
How can I measure detection coverage for T1612 without guessing?
Measure coverage by testing, not by counting rules. For each detection, define a documented test in a private cyber range, run it, and record whether the alert fired, how long it took and which fields were populated. Track the percentage of in-scope build hosts that forward the required telemetry, and track the share of expected pipeline builds that match the baseline. Report these as measured results with dates and the ATT&CK version used. Avoid presenting a rule count as coverage, because a rule without working telemetry proves nothing.
Which ATT&CK mitigations should I document for T1612, and who owns them?
The mitigations ATT&CK maps to this technique are Audit and Privileged Account Management. Audit ownership usually sits with the security engineering team, which defines which build and runtime events are logged and retained. Privileged Account Management usually sits with identity or platform administration, which controls who can run builds, push images and change runner configuration. Document both in a shared control record that names an owner, a review cadence and the evidence that proves the control works. Confirm the ownership split with your own governance model, since responsibility varies by organization.
How DeployOpen builds T1612 detections and range scenarios
DeployOpen starts by mapping where image builds happen in the client's own environment before writing any rule. That means listing the build hosts, CI runners and container platforms that can create images, the service and human identities allowed to start a build, and the log sources that already exist, such as container runtime events, orchestrator audit logs and host audit records. The written scope should name the ATT&CK version the detections target, because the technique mappings and data component names change between releases. Confirm this with the client's security team and record it in the scope document. Teams should also decide early which build activity is expected, such as approved pipelines, so that the detection logic separates routine builds from builds launched outside the pipeline.
Next, DeployOpen rebuilds the relevant part of the client's pipeline inside a private cyber range and runs agreed build scenarios under a labelled test identity. The team checks whether Image Creation and Network Connection Creation events are captured with enough context to link a new image to the host, user or process that produced it, and whether outbound connections made during a build, such as pulls of base images from registries, are visible to the monitoring stack. Illustrative example: if a build starts on a host that is not in the approved list, the rule should raise an alert within the agreed triage window, and the range log shows which fields made that match possible. Gaps found in this step feed back into the rule design.
The handover covers the detection rules in the format the client's SIEM expects, tuning notes that explain expected false positives, validation records showing which scenarios fired and which did not, and triage runbooks for the security operations team. On the mitigation side, DeployOpen maps the work to Audit (M1047), so the client can confirm that build and registry events are retained, and to Privileged Account Management (M1026), so the client can review which accounts can build images on privileged hosts. DeployOpen prepares this evidence under a fixed written scope with agreed timelines. Independent auditors, not DeployOpen, decide whether any control meets a given assessment requirement.
