T1612 Build Image on Host
EnterpriseAdversaries 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 <code>build</code> 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. An adversary may take advantage of that <code>build</code> 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. 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.
platforms
Platforms this applies to.
tactics
ATT&CK tactics this technique serves.
mitigations
ATT&CK mitigations that reduce this.
detected by (2)
Data components that detect this.
NIST CSF 2.0 — areas of relevance (Protect / Detect)
NIST CSF 2.0 areas this most relates to (evidence-ranked).
- DE.CMContinuous Monitoringmoderate · backed by 4 of 11 mapped controls
- PR.AAIdentity Management, Authentication, and Access Controlmoderate · backed by 4 of 11 mapped controls
- PR.DSData Securitymoderate · backed by 4 of 11 mapped controls
Derived from MITRE CTID (Apache-2.0) and the NIST 800-53 ↔ CSF crosswalk (public domain). Indicative relevance along the Protect/Detect axis — not a compliance assessment or coverage claim.
mitigating controls (11)
Security controls that mitigate this.
source
Where this definition is published.