Detecting Implanted Cloud and Container Images (T1525)

Implant Internal Image (T1525) is a Persistence technique for IaaS and container environments. The adversary plants malicious code into cloud or container images that already live inside the victim's environment, then waits for the infrastructure to use them.

MITRE names Amazon Machine Images, Google Cloud Platform images, Azure images, and container runtimes such as Docker as examples that can be implanted or backdoored.

How attackers use it

MITRE separates this from Upload Malware: here the adversary modifies an image in a registry inside the victim's environment. How useful that is depends on provisioning. If your infrastructure tool is told to always take the latest image, a backdoored image can give persistent access, because every new instance or container starts with it.

MITRE also mentions a tool built to ease planting backdoors in cloud container images. If an adversary controls a compromised AWS instance and may list the available container images, they can implant a backdoor such as a Web Shell.

The reason this works is trust. An image from your own registry is assumed good. Deployments pull it, orchestration restarts it, and the implant returns each time.

How to detect it

MITRE's detection strategy has two patterns:

• Malicious code placed into container images, followed by a registry push and use in new deployments.
• Creation or modification of cloud virtual machine images, such as AMIs and custom images, with persistence mechanisms, followed by provisioning that uses the implanted image.

Practical signals:

1. Registry push events from an identity that does not normally push, or at unusual times.
2. A new image digest under an existing tag that no build pipeline run explains.
3. New or modified machine images created outside your image build process.
4. Containers that start processes or open connections their image never did before.
5. Images pulled into production that fail signature verification, if you require signing.

Log registry and image API activity, such as audit trails for your cloud provider's registry and image services, and keep those logs outside the account that could be compromised.

How to reduce the risk

MITRE lists three mitigations:

1. Code Signing. Several cloud providers support content trust models that require container images to be signed by trusted sources. Turn that on and make deployment refuse unsigned images.
2. Privileged Account Management. Limit permissions to create and modify platform images or containers, following least privilege.
3. Audit. Periodically check the integrity of images and containers used in cloud deployments to be sure they have not been changed to include malicious software.

Also helpful in practice:

• Pin deployments to image digests rather than a moving latest tag, so a swap does not roll out by itself.
• Build images only in a controlled pipeline, and record where each image came from.
• Scan images for known vulnerable components and unexpected files before they are allowed to deploy.

Safeguard offers a Gold directory and a free in-browser dependency scan at gold.safeguard.sh/scan that needs no login and keeps the file on your machine, useful for checking the packages that go into an image.

Check your own environment

Read only examples. List images in an AWS container registry and the digest behind each tag (replace the repository name):

aws ecr describe-images --repository-name my-repo

Check whether an image has signatures with Docker Content Trust (replace the image name):

docker trust inspect my-registry/my-image:tag

Then ask:

• Who can push to each registry and who can create machine images?
• Do any deployments reference latest instead of a digest?
• Is signature verification enforced or only available?
• When did you last compare running images with what your build pipeline produced?

Try it yourself

Click through it at your own pace, or open it full screen.

Quick check

Sources

• MITRE ATT&CK T1525, Implant Internal Image