MITRE ATT&CK T1525 Implant Internal Image: Protecting Your Registries and Golden Images

If an attacker can push to your container registry or register a machine image in your cloud account, every workload you launch from it afterwards runs their code, and rebuilding the server brings the backdoor straight back. MITRE ATT&CK tracks this as T1525 Implant Internal Image, a Persistence (TA0003) technique on the IaaS and Containers platforms. It covers AWS AMIs, Google Cloud and Azure images, and container images in an internal registry. This guide explains the defender view of the technique in ATT&CK v20, why registry and image pipeline credentials are the real control point, which events show an implant, and how immutability, signing and deploy-time policy stop it. It is written for cloud, platform and detection engineering teams.

Key takeaways

• It is persistence through your own supply chain. Unlike uploading malware to a public site, T1525 plants the image inside the victim's registry or account, where provisioning tools already trust it.
• Mutable tags are the amplifier. ATT&CK notes persistence is strongest when provisioning always uses the latest image; a mutable tag such as latest silently swaps every new deployment to the implant.
• Push rights are the attack surface. Whoever can push images or register AMIs, human or pipeline, can implant. Most of those principals are CI/CD service accounts.
• Verify by digest and signature at deploy time. Signing, attestations and admission policy make an implanted image fail to deploy even if it reaches the registry.
• Watch who builds and pushes. Push events from unfamiliar principals, new AMIs from outside the image pipeline and image attribute changes are the detection anchors.

How the technique works

ATT&CK v20 (technique version 2.2, last modified 24 October 2025) describes T1525 as adversaries implanting cloud or container images with malicious code to establish persistence after gaining access to an environment. It names AWS AMIs, Google Cloud images, Azure images and container runtimes such as Docker. The technique has no sub-techniques. ATT&CK distinguishes it from T1608.001 Upload Malware: T1525 is about an image in a registry inside the victim's environment. The example given is an attacker with access to a compromised instance and permission to list container images implanting a backdoor such as a T1505.003 Web Shell.

The defender-relevant chain has three links:

1. Access to a principal with build or push rights: typically a stolen CI/CD token, a compromised build host or an over-privileged instance role (T1078.004 Cloud Accounts).
2. A modified image placed where provisioning will pick it up: a new image version pushed under an existing tag, a new AMI that matches the name pattern a launch template looks for, or an existing image whose sharing attributes were changed.
3. Normal provisioning does the rest: autoscaling, Kubernetes rollouts, CI jobs and golden image refreshes launch the implant with the workload's own identity and network access.

Related techniques

A real tag replacement

The Checkmarx KICS supply chain attack shows the mechanism from the publisher side. On 22 April 2026 attackers, using credentials left over from earlier access, pushed modified images to the official checkmarx/kics repository and replaced the latest, alpine, debian and two versioned tags for about half an hour. A victim's Dependabot pulled the poisoned latest tag and ran it in CI with access to repository secrets. For Checkmarx this was an implant in its own registry; for consumers it was a supply chain compromise. Both sides would have been protected by immutable tags, digest pinning and signature checks.

Where non-human identities fit

• Pipeline push credentials: registry push tokens and cloud roles held by CI/CD systems are usually the only principals that should write images, which makes them the most valuable target. See the CI/CD Pipeline Identity Security Guide.
• Instance and node roles: ATT&CK's example starts on a compromised instance. Node and instance roles that can push to registries or call RegisterImage turn a workload compromise into persistence.
• Image builder service accounts: golden image tools run with rights to create and share AMIs or custom images across accounts; one stolen credential can publish an implant estate-wide. See the Server Build and Golden Image Hardening Guide.
• Registry tokens on developer machines: long-lived registry tokens in local configuration files allow pushes from anywhere. Replace them with short-lived, federated credentials. See the Container Registry Security Guide.
• Secrets inside images: implants often harvest credentials baked into the image itself. See the Secrets in Container Images and Build Artefacts Guide.

Detection

ATT&CK v20 detection strategy DET0334 has two analytics: AN0946 for containers (build or commit followed by a push to an internal registry, and push events from an unrecognised user or context) and AN0947 for IaaS (new or modified machine images followed by provisioning that uses them).

Correlation logic

1. Push provenance: every production push should map to a pipeline run. Join registry push events with CI logs on digest and alert on any push without a matching build.
2. Tag drift: track the digest behind each production tag; a change without a release ticket is an incident until proven otherwise.
3. Image lineage for VMs: keep a list of AMI IDs produced by the image pipeline and alert when RunInstances uses anything else.
4. Runtime confirmation: new containers from a recently changed image making outbound connections to new destinations, or spawning shells, raise severity.

For broader rules see the Cloud Detection Engineering Guide.

Prevention

Two documented limits matter. AWS states that Allowed AMIs controls public and shared AMIs only and does not restrict AMIs owned by your own account, so an attacker registering an AMI inside your account is not blocked by it; pair it with tight RegisterImage permissions and launch-template control. Google states that Binary Authorization blocks non-compliant deployments and records the reason in Cloud Audit Logs, which also gives you a detection feed. See the Kubernetes Admission Control Guide and the Code Signing Security Guide.

Implementation sequence

1. Inventory image sources: list every registry, repository and image-producing account, and every principal with push or register rights.
2. Cut push rights: remove push and RegisterImage from humans and node roles in production; move pipeline credentials to short-lived federation.
3. Turn on immutability: set production repositories to immutable tags; fix pipelines that rely on overwriting tags.
4. Pin by digest: change deployment manifests and launch templates to digests and specific AMI IDs.
5. Sign and verify in audit mode first: start Binary Authorization in dry-run, an admission controller in audit mode or Allowed AMIs in audit mode, review what would be blocked for two weeks, then enforce per environment. Roll back by switching the policy to audit.
6. Deploy the detections: push provenance, tag drift and AMI lineage alerts.
7. Plan response: for a confirmed implant, quarantine the image, find every workload launched from it, rotate the push credential and any credentials the image could reach, then rebuild from a verified source.

Decision guidance

• Immutability versus convenience: mutable tags are useful for pull-through caches, as AWS notes. Keep caches in separate repositories and make production repositories immutable.
• Signing first or detection first: small teams get faster value from immutability, push-right reduction and digest pinning; signing enforcement needs key management and pipeline changes, so it suits teams with a mature build system.
• Large estates: enforce at the organisation level (declarative policies, organisation-wide admission policy) so new accounts and clusters inherit the controls.
• Break-glass: keep a documented, logged override for emergency deploys and alert on every use.

Measuring progress

• Push surface: principals able to push to production repositories or register images, target pipeline roles only.
• Immutable coverage: percentage of production repositories with immutable tags.
• Digest pinning: percentage of running workloads referencing images by digest.
• Signature enforcement: clusters and services where unsigned images are blocked, not just logged.
• Unexplained pushes: production pushes without a matching pipeline run per month, target zero.

Common failure patterns

• Floating tags in production: autoscaling pulls latest, so a single overwritten tag reaches every new node.
• Node roles that can push: worker nodes with registry write access, so one compromised pod becomes a persistent implant.
• Signing without enforcement: images are signed, but nothing rejects an unsigned one at deploy time.
• Trusting your own account: assuming Allowed AMIs or similar controls cover images created inside the account, which AWS documents they do not.
• Incomplete cleanup: responders delete the image but leave the stolen push token valid, or miss workloads already running the implant.

Framework mapping

Practitioner checklist

• List every principal that can push images or register machine images; reduce to pipeline roles.
• Make production repositories immutable and remove latest exclusions.
• Reference images by digest and AMIs by pipeline-produced ID.
• Sign images in the pipeline and enforce verification at deploy time, after an audit-mode period.
• Enable EC2 Allowed AMIs and restrict RegisterImage inside your accounts.
• Alert on pushes without a pipeline run, tag digest drift and launches from unknown AMIs.
• Rescan deployed images against build-time digests and SBOMs.
• On an implant, rotate push credentials and find every workload launched from the image.

Standards and references

• MITRE ATT&CK: Implant Internal Image (T1525)
• AWS: Preventing image tags from being overwritten in Amazon ECR
• AWS: Logging Amazon ECR actions with AWS CloudTrail
• AWS: Control the discovery and use of AMIs with Allowed AMIs
• Google Cloud: Binary Authorization overview
• MITRE D3FEND: Container Image Analysis
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Container Image Security Guide · Container Registry Security Guide · CI/CD Pipeline Identity Security Guide · Server Build and Golden Image Hardening Guide · MITRE ATT&CK Guide for Defenders