How do attackers use Build Image on Host?

How attackers use build-on-host workflows

Attackers use build-on-host workflows to assemble a disk, container, or system image locally, then move that image elsewhere or deploy it later. The value is operational: it can package tools, implants, and prebuilt environments with less obvious external transfer activity, while also letting the attacker stage assets before launch.

That pattern is most useful when the host already has build tooling, storage, and network reach that make the image look like ordinary administrative work. On a developer workstation, build server, or container host, the same tooling used for legitimate image creation can also be used to prepare malicious content with a smaller and more discrete footprint.

Because the image is created before it is transferred, the defender often sees the build activity first and the malicious use later. That separation can delay detection, especially when the workflow borrows trusted build utilities and produces large file artifacts that blend with routine packaging, backup, or release processes.

Why build images on a host instead of delivering files directly?

Building locally gives attackers more control over the final artifact. They can include exactly the tools, configs, startup logic, or staged components they want, then export or copy the finished image when timing is favourable. In practice, that can be easier to conceal than repeatedly pushing many individual payloads across the network.

This also helps with environment preparation. A local image can preserve a known runtime, required dependencies, or a ready-to-run filesystem layout so the attacker is not dependent on the target environment at the moment of deployment. That reduces friction and can improve repeatability if the image is reused across multiple systems.

For defenders, the important distinction is not whether image creation is always malicious, but whether it is expected on that host. The same command sequence on a hardened build pipeline is normal, while on an end-user workstation or non-build server it can be a strong sign of staging, persistence preparation, or tool packaging.

When container and image operations are in scope, baseline guidance from NIST SP 800-190 Container Security is useful because it treats image, registry, orchestrator, and runtime risk as separate problems. That separation matters here, since the build step may be the earliest observable phase even when the eventual abuse occurs elsewhere.

What defenders should look for on the host

The most reliable clue is not just “an image was created,” but “an image was created where image creation does not normally happen.” Unexpected use of build tooling, package managers, container engines, compression utilities, or large archival processes on a workstation or server deserves attention, especially when it is followed by staging, transfer, or a new outbound connection pattern.

Other useful indicators include unusual file growth in temporary or working directories, repeated archive or image generation, and commands that prepare a filesystem snapshot or container layer outside the usual software delivery path. Those signals become stronger when the host has no business role in building releases, images, or portable disk artifacts.

Image creation also matters because it can be a precursor to lateral movement or deployment. If the artefact contains remote administration tools, scripts, or preconfigured services, the attacker may be trying to reduce the number of post-exploitation actions needed after it lands somewhere else.

Practitioner Guidance

What to verify: Confirm which hosts are authorised to create images, which tools they are expected to use, and what normal build volume looks like. A build event on a system outside that allowlist is more important than the file type alone.

What to prioritise: Triage the sequence, not just the artifact. Build activity followed by staging, compression, transfer, or new execution paths is more suspicious than an isolated file creation event.

Common mistake: Teams often watch for the final image reaching its destination but miss the local preparation step. That is where the earliest containment opportunity usually exists, especially when the build host is not supposed to handle release artifacts.

Practitioner takeaway: Treat unexpected image build activity as an operational staging signal first and a file artifact second, because the real security value is in the host context, the follow-on transfer, and the trust the attacker is borrowing from legitimate build workflows.

Related resources from NHI Mgmt Group

• Guide: Container Security Guide
• How do attackers turn a supply-chain incident into wider NHI compromise?
• How do attackers operationalise stolen OAuth tokens at scale?
• Why do attackers often check model availability before trying to generate content?
• How do attackers turn stolen npm secrets into broader compromise?