Adversaries 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.(Citation: Docker Build Image)
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.(Citation: Aqua Build Images on Hosts)(Citation: Aqua Security Cloud Native Threat Report June 2021) 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.
View in MITRE ATT&CK®| Capability ID | Capability Description | Mapping Type | ATT&CK ID | ATT&CK Name | Notes |
|---|---|---|---|---|---|
| CIS-4.6 | Securely Manage Enterprise Assets and Software | mitigates | T1612 | Build Image on Host |
Comments
Securing container-management APIs and restricting builds to controlled Infrastructure-as-Code or pipeline processes reduces unauthorized image construction on managed hosts. It does not prevent misuse by a compromised authorized build identity.
References
|
| CIS-16.8 | Separate Production and Non-Production Systems | mitigates | T1612 | Build Image on Host |
Comments
Production and non-production container or virtualization infrastructure can be placed behind separate gateways, firewalls, or control-plane boundaries so a compromised non-production system cannot directly reach production hosts used to build images.
References
|
| Capability ID | Capability Description | Mapping Type | ATT&CK ID | ATT&CK Name | Notes |
|---|---|---|---|---|---|
| action.malware.variety.In-memory | (malware never stored to persistent storage) | related-to | T1612 | Build Image on Host | |
| action.malware.variety.Unknown | Unknown | related-to | T1612 | Build Image on Host |
| Capability ID | Capability Description | Mapping Type | ATT&CK ID | ATT&CK Name | Notes |
|---|---|---|---|---|---|
| binary_authorization | Binary Authorization | technique_scores | T1612 | Build Image on Host |
Comments
Each container image generated has a signer digitally sign using a private key to generate the attestation report. At deploy time, the enforcer uses the attester's public key to verify the signature or will block this process.
References
|