AN0946: Analytic 0946
Implantation of malicious code into container images followed by registry push and use in new deployments.
Analyst context for executives and security teams
This analytic concerns malicious code being added to container images, pushed to a registry, and then used in new deployments. For leaders, the significance is supply-chain and deployment trust: if image provenance, registry activity, and deployment admission are weak, compromised images can move from build or registry workflows into production containers without looking like a traditional host intrusion.
Executive priority
Prioritize this as a container supply-chain control question: can the organization prove which images are trusted, who or what pushed them, and where they were deployed? The business decision value is in reducing the chance that normal deployment processes become the delivery path for malicious code, and in producing audit-ready evidence around registry governance, CI/CD integrity, and deployment change control.
Technical view
SOC, cloud/container security, and IR teams should validate visibility across the image lifecycle: image creation or update, registry push, and use in new deployments. Because the ATT&CK object provides no official detection logic or related techniques, detection engineering should focus on environment-specific baselines for expected image publishers, repositories, tags, digests, and deployment patterns. Investigations should correlate registry events with CI/CD pipeline activity and container orchestration deployment records rather than treating registry pushes or new deployments in isolation.
Likely telemetry
- Container registry push, update, tag, and delete logs
- Image metadata including repository, tag, digest, creation time, and publisher or service identity
- CI/CD build and release logs associated with image creation and promotion
- Container orchestration deployment events showing image references used in new workloads
- Admission control or policy decision logs for container deployments
Detection direction
- Validate that registry push events can be correlated to approved CI/CD jobs and authorized identities.
- Alert or review when new deployments reference images, tags, repositories, or digests outside approved promotion paths.
- Tune for local false positives such as emergency releases, testing repositories, rebuilt base images, or legitimate tag movement.
- Prefer digest-based correlation where available, since tags alone may not reliably identify the exact image deployed.
- Look for gaps between registry monitoring and orchestration monitoring; this behavior spans both registry activity and deployment use.
Mitigation priorities
- Establish trusted image provenance and promotion controls for container images before production deployment.
- Restrict registry push permissions and deployment permissions to approved users, service accounts, and automation.
- Use policy or admission controls to limit deployments to approved registries, repositories, and image identities.
- Retain registry, CI/CD, identity, and deployment logs long enough to support incident response and compliance evidence.
- Review exception processes for urgent deployments so bypasses are visible and time-bound.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic for Containers with the description: malicious code is implanted into container images, pushed to a registry, and used in new deployments. No tactics, relationships, aliases, labels, or official detection procedure were supplied, so this take emphasizes defensive validation around container image lifecycle evidence rather than a specific ATT&CK technique chain.
This summary is limited by sparse official fields. It does not establish actor attribution, active exploitation, business impact, or guaranteed detection coverage. Local registry architecture, CI/CD design, orchestration platform, IAM model, and logging retention determine practical detection and response quality.
Analytic 0946
Implantation of malicious code into container images followed by registry push and use in new deployments.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 55ac180d380f… |
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.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN0946Open source URL
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.