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

T1204.003: Malicious Image

Adversaries may rely on a user running a malicious image to facilitate execution. 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 backdoored. Backdoored images may be uploaded to a public repository via Upload Malware, and users may then download and deploy an instance or container from the image without realizing the image is malicious, thus bypassing techniques that specifically achieve Initial Access. This can lead to the execution of malicious code, such as code that executes cryptocurrency mining, in the instance or container.[1]

Adversaries may also name images a certain way to increase the chance of users mistakenly deploying an instance or container from the image (ex: Match Legitimate Resource Name or Location).[2]

EnterpriseT1204.003Sub-techniqueObject v1.2 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

Malicious Image is an execution risk in cloud and container environments: a user or team may deploy an image that appears useful or legitimate but already contains malicious code. This matters because it can bypass some traditional initial-access assumptions—the organization may effectively start the adversary’s code itself by launching an IaaS image or container image from an untrusted or misleading source.

Executive priority

Prioritize this where teams deploy AWS AMIs, GCP Images, Azure Images, or container images from public or loosely governed repositories. The business question is whether cloud and platform teams can prove which images are trusted, who approved them, where they came from, and what happened immediately after deployment. This technique affects operational resilience, cloud cost exposure, audit evidence, and incident response speed because malicious execution may begin as part of normal provisioning activity.

Technical view

For SOC, cloud security, and IR teams, validate controls and telemetry around the pull/run/start lifecycle for images in IaaS and container environments. ATT&CK does not provide official detection text for this sub-technique, but the related detection strategy DET0248 points to monitoring image pull/run activity, instance or container start events, and anomalous post-start behavior. Detection should focus on untrusted image sources, suspiciously named images that resemble legitimate resources, unexpected image deployments by users or automation, and runtime behavior inconsistent with the declared workload.

Likely telemetry

  • Cloud audit logs for image selection, instance creation, and start events in IaaS environments
  • Container registry and runtime logs showing image pulls, image IDs, tags, and container starts
  • Repository metadata for public or internal images, including publisher/source and naming patterns
  • Identity and access logs showing which user, role, service account, or automation deployed the image
  • Host, container, or workload telemetry for new processes, scheduled activity, and unexpected execution after launch

Detection direction

  • Confirm that image pull/run/start events are captured and correlated to the responsible identity and deployment pipeline.
  • Tune detections for newly launched containers or instances that quickly show anomalous behavior rather than relying only on static image names or tags.
  • Review for image names that mimic legitimate resources, since the ATT&CK description notes adversaries may use naming to increase mistaken deployment.
  • Separate expected developer testing and sanctioned public image use from risky unmanaged pulls to reduce false positives.
  • Use the TeamTNT relationship as threat-intelligence context for cloud/container-focused tradecraft, but do not treat it as attribution without case evidence.

Mitigation priorities

  • Establish an approved-image process for IaaS and container platforms, including provenance review before deployment.
  • Use code signing or equivalent trust validation for images and artifacts where feasible, aligned to M1045.
  • Audit image sources, deployment activity, and runtime behavior on a regular basis, aligned to M1047.
  • Apply user training for engineers and operators who select images so they recognize misleading names and untrusted public sources, aligned to M1017.
  • Use network intrusion prevention or boundary controls to block known malicious traffic where signatures are available, aligned to M1031.
Analyst notes and limits

This is a sub-technique of User Execution focused on IaaS and Containers. The key defensive decision is not only whether malware can be detected after launch, but whether the organization can govern and investigate the human or automation decision that introduced the image.

The supplied ATT&CK object has no official detection text. Recommendations are therefore derived from the official description, platforms, execution tactic, external references, and the provided DET0248 and mitigation relationships. Local architecture, registry practices, CI/CD design, and cloud logging configuration are required to assess actual coverage.

Official MITRE ATT&CK definition

Malicious Image

Adversaries may rely on a user running a malicious image to facilitate execution. 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 backdoored. Backdoored images may be uploaded to a public repository via Upload Malware, and users may then download and deploy an instance or container from the image without realizing the image is malicious, thus bypassing techniques that specifically achieve Initial Access. This can lead to the execution of malicious code, such as code that executes cryptocurrency mining, in the instance or container.[1]

Adversaries may also name images a certain way to increase the chance of users mistakenly deploying an instance or container from the image (ex: Match Legitimate Resource Name or Location).[2]

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.

ATT&CK relationship table

Related techniques

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

1 rows
Domain ID Name Relationship / procedure
Enterprise T1204 User Execution This object subtechnique of User Execution.
Associated objects

Groups, software, and campaigns

Group Enterprise

G0139: TeamTNT

TeamTNT is a threat group that has primarily targeted cloud and containerized environments. The group as been active since at least October 2019 and has mainly focused its efforts on leveraging cloud and container resources to deploy cryptocurrency miners in victim environments.[1][2][3][4][5][6][7][8][9]

Relationship explorer

All related ATT&CK context

mitigates · Mitigation M1045: Code Signing Enterprise detects · Detection Strategy DET0248: User Execution – Malicious Image (containers & IaaS) – pull/run → start → anomalous behavior (T1204.003) Enterprise uses · Group G0139: TeamTNT Enterprise mitigates · Mitigation M1031: Network Intrusion Prevention Enterprise mitigates · Mitigation M1017: User Training Enterprise mitigates · Mitigation M1047: Audit Enterprise subtechnique of · Technique T1204: User Execution 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

M1017: User Training

User Training involves educating employees and contractors on recognizing, reporting, and preventing cyber threats that rely on human interaction, such as phishing, social engineering, and other manipulative techniques. Comprehensive training programs create a human firewall by empowering users to be an active component of the organization's cybersecurity defenses. This mitigation can be implemented through the following measures:

Create Comprehensive Training Programs:

- Design training modules tailored to the organization's risk profile, covering topics such as phishing, password management, and incident reporting. - Provide role-specific training for high-risk employees, such as helpdesk staff or executives.

Use Simulated Exercises:

- Conduct phishing simulations to measure user susceptibility and provide targeted follow-up training. - Run social engineering drills to evaluate employee responses and reinforce protocols.

Leverage Gamification and Engagement:

- Introduce interactive learning methods such as quizzes, gamified challenges, and rewards for successful detection and reporting of threats.

Incorporate Security Policies into Onboarding:

- Include cybersecurity training as part of the onboarding process for new employees. - Provide easy-to-understand materials outlining acceptable use policies and reporting procedures.

Regular Refresher Courses:

- Update training materials to include emerging threats and techniques used by adversaries. - Ensure all employees complete periodic refresher courses to stay informed.

Emphasize Real-World Scenarios:

- Use case studies of recent attacks to demonstrate the consequences of successful phishing or social engineering. - Discuss how specific employee actions can prevent or mitigate such attacks.

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
1.2
Created
Modified
Raw hash
a30b4ea3fddc463f...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.2 Current bundle a30b4ea3fddc…
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]
    Summit Route Malicious AMIs

    Piper, S.. (2018, September 24). Investigating Malicious AMIs. Retrieved March 30, 2021.

    Open source URL
  2. [2]
    Aqua Security Cloud Native Threat Report June 2021

    Team Nautilus. (2021, June). Attacks in the Wild on the Container Supply Chain and Infrastructure. Retrieved August 26, 2021.

    Open source URL
  3. [3]
    mitre-attack T1204.003
    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