Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1525: Implant Internal Image

Adversaries may implant cloud or container images with malicious code to establish persistence after gaining access to an environment. Amazon Web Services (AWS) Amazon Machine Images (AMIs), Google Cloud Platform (GCP) Images, and Azure Images as well as popular container runtimes such as Docker can be implanted or backdoored. Unlike Upload Malware, this technique focuses on adversaries implanting an image in a registry within a victim’s environment. Depending on how the infrastructure is provisioned, this could provide persistent access if the infrastructure provisioning tool is instructed to always use the latest image.[1]

A tool has been developed to facilitate planting backdoors in cloud container images.[2] If an adversary has access to a compromised AWS instance, and permissions to list the available container images, they may implant a backdoor such as a Web Shell.[1]

EnterpriseT1525TechniqueObject v2.2 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

T1525 matters because a compromised internal cloud or container image can turn normal infrastructure provisioning into persistence. If teams repeatedly deploy from a backdoored AMI, cloud image, or container image in their own registry, the adversary may regain access whenever new infrastructure is launched. For leaders, the risk is not just malware on one host; it is loss of trust in the build-and-deploy pipeline that supports cloud operations.

Executive priority

Prioritize this where IaaS or container environments rely on reusable images, especially where automation pulls the latest approved image. Executives should ask whether image creation, registry access, image promotion, and deployment are governed by privileged access controls, signing or integrity validation, and auditable change history. This technique has direct relevance to operational resilience, incident scoping, compliance evidence, and cloud security assurance because remediation may require validating or rebuilding trusted images, not only cleaning affected workloads.

Technical view

ATT&CK lists this as a persistence technique for IaaS and Containers. SOC, IR, and cloud security teams should validate whether they can identify unauthorized image creation, modification, replacement, tagging, or promotion inside victim-controlled cloud or container registries. Because the official ATT&CK detection field is not provided, teams should use the related DET0334 detection strategy as a prompt to build local analytics around image registry activity, privileged account use, and deployment events. Investigation should connect image changes to subsequent workload launches and to provisioning tools that automatically consume latest images.

Likely telemetry

  • Cloud provider audit logs for image create, copy, import, modify, tag, share, and delete actions
  • Container registry logs for image push, pull, tag changes, manifest changes, and repository permission changes
  • Identity and privileged access logs showing who or what modified images or registry settings
  • Image metadata, hashes, digests, signatures, tags, and build provenance records
  • Infrastructure-as-code and provisioning tool records showing which images are referenced during deployment

Detection direction

  • Baseline expected image publishers, build systems, service accounts, tags, and promotion paths; alert on image changes outside those norms.
  • Correlate privileged account activity with image registry changes and subsequent workload launches from the changed image.
  • Tune for false positives from legitimate CI/CD image rebuilds, patch cycles, and approved base-image refreshes by requiring change ticket, signer, or pipeline provenance context where available.
  • Look for risk created by automation that always deploys the latest image, since that can turn a single registry compromise into repeated persistence.
  • Account for the ATT&CK limitation that no official detection text is supplied; local cloud, registry, and deployment telemetry will determine practical coverage.

Mitigation priorities

  • Start with privileged account management: restrict who and what can create, modify, tag, promote, or deploy internal images; apply least privilege and monitor privileged use.
  • Use code signing or equivalent integrity validation for images and code artifacts so deployment workflows can reject untrusted or tampered images.
  • Maintain auditing for registry, image, identity, and deployment activity, and review it regularly for unauthorized changes.
  • Require controlled image promotion workflows rather than allowing broad direct writes to production registries or image catalogs.
  • During incident response, treat internal images as potential persistence sources and validate or rebuild trusted images before redeploying affected infrastructure.
Analyst notes and limits

The supplied ATT&CK object specifically covers adversaries implanting cloud or container images inside a victim environment, distinct from externally uploading malware. The relationship set includes DET0334 as a detection strategy and mitigations M1026 Privileged Account Management, M1045 Code Signing, and M1047 Audit. Those relationships support focusing on identity control, artifact integrity, and auditability as the main defensive decision areas.

The official ATT&CK detection field is not provided, and the supplied DET0334 relationship does not include detection logic details. This take does not assert active exploitation, attribution, or guaranteed coverage. Exact detections depend on the organization’s cloud provider, registry, container runtime, provisioning tools, and available audit logs.

Official MITRE ATT&CK definition

Implant Internal Image

Adversaries may implant cloud or container images with malicious code to establish persistence after gaining access to an environment. Amazon Web Services (AWS) Amazon Machine Images (AMIs), Google Cloud Platform (GCP) Images, and Azure Images as well as popular container runtimes such as Docker can be implanted or backdoored. Unlike Upload Malware, this technique focuses on adversaries implanting an image in a registry within a victim’s environment. Depending on how the infrastructure is provisioned, this could provide persistent access if the infrastructure provisioning tool is instructed to always use the latest image.[1]

A tool has been developed to facilitate planting backdoors in cloud container images.[2] If an adversary has access to a compromised AWS instance, and permissions to list the available container images, they may implant a backdoor such as a Web Shell.[1]

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

Relationship explorer

All related ATT&CK context

detects · Detection Strategy DET0334: Detection Strategy for T1525 – Implant Internal Image Enterprise mitigates · Mitigation M1045: Code Signing Enterprise mitigates · Mitigation M1026: Privileged Account Management Enterprise mitigates · Mitigation M1047: Audit Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1045: Code Signing

Code Signing is a security process that ensures the authenticity and integrity of software by digitally signing executables, scripts, and other code artifacts. It prevents untrusted or malicious code from executing by verifying the digital signatures against trusted sources. Code signing protects against tampering, impersonation, and distribution of unauthorized or malicious software, forming a critical defense against supply chain and software exploitation attacks. This mitigation can be implemented through the following measures:

Enforce Signed Code Execution:

- Implementation: Configure operating systems (e.g., Windows with AppLocker or Linux with Secure Boot) to allow only signed code to execute. - Use Case: Prevent the execution of malicious PowerShell scripts by requiring all scripts to be signed with a trusted certificate.

Vendor-Signed Driver Enforcement:

- Implementation: Enable kernel-mode code signing to ensure that only drivers signed by trusted vendors can be loaded. - Use Case: A malicious driver attempting to modify system memory fails to load because it lacks a valid signature.

Certificate Revocation Management:

- Implementation: Use Online Certificate Status Protocol (OCSP) or Certificate Revocation Lists (CRLs) to block certificates associated with compromised or deprecated code. - Use Case: A compromised certificate used to sign a malicious update is revoked, preventing further execution of the software.

Third-Party Software Verification:

- Implementation: Require software from external vendors to be signed with valid certificates before deployment. - Use Case: An organization only deploys signed and verified third-party software to prevent supply chain attacks.

Script Integrity in CI/CD Pipelines:

- Implementation: Integrate code signing into CI/CD pipelines to sign and verify code artifacts before production release. - Use Case: A software company ensures that all production builds are signed, preventing tampered builds from reaching customers.

**Key Components of Code Signing**

- Digital Signature Verification: Verifies the authenticity of code by ensuring it was signed by a trusted entity. - Certificate Management: Uses Public Key Infrastructure (PKI) to manage signing certificates and revocation lists. - Enforced Policy for Unsigned Code: Prevents the execution of unsigned or untrusted binaries and scripts. - Hash Integrity Check: Confirms that code has not been altered since signing by comparing cryptographic hashes.

Mitigation Enterprise

M1026: Privileged Account Management

Privileged Account Management focuses on implementing policies, controls, and tools to securely manage privileged accounts (e.g., SYSTEM, root, or administrative accounts). This includes restricting access, limiting the scope of permissions, monitoring privileged account usage, and ensuring accountability through logging and auditing.This mitigation can be implemented through the following measures:

Account Permissions and Roles:

- Implement RBAC and least privilege principles to allocate permissions securely. - Use tools like Active Directory Group Policies to enforce access restrictions.

Credential Security:

- Deploy password vaulting tools like CyberArk, HashiCorp Vault, or KeePass for secure storage and rotation of credentials. - Enforce password policies for complexity, uniqueness, and expiration using tools like Microsoft Group Policy Objects (GPO).

Multi-Factor Authentication (MFA):

- Enforce MFA for all privileged accounts using Duo Security, Okta, or Microsoft Azure AD MFA.

Privileged Access Management (PAM):

- Use PAM solutions like CyberArk, BeyondTrust, or Thycotic to manage, monitor, and audit privileged access.

Auditing and Monitoring:

- Integrate activity monitoring into your SIEM (e.g., Splunk or QRadar) to detect and alert on anomalous privileged account usage.

Just-In-Time Access:

- Deploy JIT solutions like Azure Privileged Identity Management (PIM) or configure ephemeral roles in AWS and GCP to grant time-limited elevated permissions.

*Tools for Implementation*

Privileged Access Management (PAM):

- CyberArk, BeyondTrust, Thycotic, HashiCorp Vault.

Credential Management:

- Microsoft LAPS (Local Admin Password Solution), Password Safe, HashiCorp Vault, KeePass.

Multi-Factor Authentication:

- Duo Security, Okta, Microsoft Azure MFA, Google Authenticator.

Linux Privilege Management:

- sudo configuration, SELinux, AppArmor.

Just-In-Time Access:

- Azure Privileged Identity Management (PIM), AWS IAM Roles with session constraints, GCP Identity-Aware Proxy.

Mitigation Enterprise

M1047: Audit

Auditing is the process of recording activity and systematically reviewing and analyzing the activity and system configurations. The primary purpose of auditing is to detect anomalies and identify potential threats or weaknesses in the environment. Proper auditing configurations can also help to meet compliance requirements. The process of auditing encompasses regular analysis of user behaviors and system logs in support of proactive security measures.

Auditing is applicable to all systems used within an organization, from the front door of a building to accessing a file on a fileserver. It is considered more critical for regulated industries such as, healthcare, finance and government where compliance requirements demand stringent tracking of user and system activates.This mitigation can be implemented through the following measures:

System Audit:

- Use Case: Regularly assess system configurations to ensure compliance with organizational security policies. - Implementation: Use tools to scan for deviations from established benchmarks.

Permission Audits:

- Use Case: Review file and folder permissions to minimize the risk of unauthorized access or privilege escalation. - Implementation: Run access reviews to identify users or groups with excessive permissions.

Software Audits:

- Use Case: Identify outdated, unsupported, or insecure software that could serve as an attack vector. - Implementation: Use inventory and vulnerability scanning tools to detect outdated versions and recommend secure alternatives.

Configuration Audits:

- Use Case: Evaluate system and network configurations to ensure secure settings (e.g., disabled SMBv1, enabled MFA). - Implementation: Implement automated configuration scanning tools like SCAP (Security Content Automation Protocol) to identify non-compliant systems.

Network Audits:

- Use Case: Examine network traffic, firewall rules, and endpoint communications to identify unauthorized or insecure connections. - Implementation: Utilize tools such as Wireshark, or Zeek to monitor and log suspicious network behavior.

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release
19.1
Object version
2.2
Created
Modified
Raw hash
9dafba75ad09eae5...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 2.2 Current bundle 9dafba75ad09…
Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    Rhino Labs Cloud Image Backdoor Technique Sept 2019

    Rhino Labs. (2019, August). Exploiting AWS ECR and ECS with the Cloud Container Attack Tool (CCAT). Retrieved September 12, 2019.

    Open source URL
  2. [2]
    Rhino Labs Cloud Backdoor September 2019

    Rhino Labs. (2019, September). Cloud Container Attack Tool (CCAT). Retrieved September 12, 2019.

    Open source URL
  3. [3]
    mitre-attack T1525
    Open source URL
Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use