AN1578: Analytic 1578
Detects creation of new container system processes via `docker run --restart`, `kubectl exec` to init containers, or modification of container init specs. Flags container images that override entrypoints to embed persistence behaviors.
Analyst context for executives and security teams
This analytic is about spotting container persistence behavior: new system-level container processes, restart-based execution, exec activity into init containers, init specification changes, or images that override entrypoints to embed persistent behavior. For leaders, the decision value is whether container operations are observable enough to prove that workloads start only as intended and that unauthorized persistence would be investigated quickly.
Executive priority
Prioritize this where containerized services support business-critical applications. The risk is not limited to a single host event; persistence in container startup behavior can survive workload restarts and complicate incident response. Security leaders should ask whether container runtime and orchestration activity is logged, retained, and reviewable as compliance and incident evidence, and whether teams can distinguish approved deployment changes from suspicious persistence patterns.
Technical view
Validate coverage for the Containers platform. SOC and detection teams should focus on events around creation of new container system processes, use of restart behavior such as docker run --restart, kubectl exec activity involving init containers, changes to container init specifications, and container images that override entrypoints in ways that could embed persistent execution. Because no ATT&CK detection logic is supplied, local implementation must define baselines for normal deployment, administration, and image build patterns before alerting.
Likely telemetry
- Container runtime events for container creation, process start, restart policy use, and entrypoint configuration
- Kubernetes or orchestration audit logs for kubectl exec activity and workload/init container changes
- Container image metadata and build/deployment records showing entrypoint or command overrides
- Configuration change records for container init specifications and workload manifests
- CI/CD, registry, or deployment pipeline logs that identify who changed images or runtime parameters
Detection direction
- Confirm that container runtime and orchestration logs capture the specific behaviors named in the analytic: restart-based container execution, exec into init containers, init spec modification, and entrypoint overrides.
- Tune detections against approved operational patterns, since legitimate administrators and deployment pipelines may use exec, restart policies, or entrypoint changes during maintenance and releases.
- Correlate suspicious container startup changes with identity, change-management, and deployment context to separate expected rollout activity from unexplained persistence behavior.
- Review blind spots in ephemeral workloads, short log retention, unmanaged container hosts, and image metadata that is not collected after deployment.
- Because no relationship context or official detection query is provided, treat this as a detection design objective rather than a ready-to-run rule.
Mitigation priorities
- Establish approved baselines for container restart policies, init container behavior, and image entrypoint usage.
- Restrict and monitor administrative actions that modify running containers, init specs, or workload definitions.
- Require deployment and image changes to flow through controlled CI/CD or change-management paths where feasible.
- Retain container runtime, orchestration, and image metadata long enough to support incident response and audit review.
- Periodically test whether SOC and IR teams can reconstruct who changed container startup behavior and when.
Analyst notes and limits
This object is a MITRE ATT&CK detection analytic, AN1578, for the Containers platform. The supplied description provides behavior to monitor, but tactics are not specified, no official detection logic is included, and no relationships are supplied. The strongest use is as a validation target for container visibility, change control, and persistence-oriented detection engineering.
Assessment is limited to the supplied ATT&CK fields and external reference. It does not establish active exploitation, actor attribution, prevalence, impact, or guaranteed detection coverage. Local container architecture, orchestrator logging, CI/CD process, and administrative practices are required to decide alert logic and priority.
Analytic 1578
Detects creation of new container system processes via `docker run --restart`, `kubectl exec` to init containers, or modification of container init specs. Flags container images that override entrypoints to embed persistence behaviors.
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 | 5d5e579c3ce9… |
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 AN1578Open 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.