AN0358: Analytic 0358
Adversary uses renamed container images, injects files into containers with misleading names or metadata (e.g., renamed system binaries), and executes them during startup or scheduled jobs.
Analyst context for executives and security teams
This analytic concerns container environments where an adversary disguises container images or files inside containers with misleading names or metadata, then runs them at startup or through scheduled jobs. For security leaders, the decision value is whether container build, registry, runtime, and job-scheduling visibility can prove that what is running matches what was approved.
Executive priority
Prioritize this as a container governance and operational resilience issue. If teams cannot validate image provenance, file integrity inside containers, and startup or scheduled execution behavior, incident responders may struggle to distinguish legitimate workload changes from disguised unauthorized execution. This also affects audit evidence for change control and cloud/container security controls.
Technical view
SOC, detection engineering, and IR teams should validate telemetry across the container lifecycle: image naming and registry metadata, container filesystem changes, startup commands, entrypoints, and scheduled jobs. Because ATT&CK provides no official detection logic for this analytic, local baselining is important: compare expected image names, approved binaries, file metadata, and startup behavior against what actually runs in container workloads.
Likely telemetry
- Container image registry metadata and image pull events
- Container runtime events for container start, entrypoint, command, and process execution
- Filesystem change or integrity data from container images and running containers
- Scheduled job definitions and execution logs inside containerized workloads
- Build pipeline, deployment, and orchestration change records
Detection direction
- Validate whether renamed images or misleading file names can be correlated with approved build and deployment records.
- Tune detections around unexpected startup commands, entrypoint changes, or scheduled execution in containers rather than relying on file names alone.
- Look for mismatches between expected system binaries or metadata and observed files introduced into containers.
- Account for false positives from legitimate image retagging, base image updates, debugging, or CI/CD automation.
- Document blind spots where runtime process, filesystem, or registry telemetry is not collected.
Mitigation priorities
- Enforce approved image sources, image signing or provenance checks, and controlled deployment paths where available.
- Use container image scanning and integrity validation to compare expected files and metadata with deployed workloads.
- Restrict who can modify images, container startup configuration, and scheduled jobs.
- Maintain auditable CI/CD and orchestration change records for incident response and compliance evidence.
- Improve runtime monitoring for containers that can observe process execution and filesystem changes.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic for Containers with no tactic, no official detection text, and no relationship context. The practical focus should be validating whether the organization can prove container image identity, file integrity, and execution behavior across build, registry, deployment, and runtime stages.
This take is based only on the supplied official description and external reference for AN0358. It does not assert active exploitation, attribution, impact, or guaranteed detection coverage. Local architecture, orchestration platform, logging depth, and CI/CD practices are required to determine actual risk and coverage.
Analytic 0358
Adversary uses renamed container images, injects files into containers with misleading names or metadata (e.g., renamed system binaries), and executes them during startup or scheduled jobs.
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 | 3d70fce9276c… |
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 AN0358Open 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.