AN0691: Analytic 0691
CONTAINERS (Docker/K8s/containerd): A user pulls an untrusted image from a public/unknown registry and then creates/starts a container from that image. Shortly after start, the container spawns unexpected utilities (e.g., curl/wget/bash/python), or makes outbound network connections atypical for the namespace/workload. The analytic correlates Image Creation/Download → Container Creation → Container Start → Command Execution/Network activity within a short window and with a consistent image digest.
Analyst context for executives and security teams
This analytic matters because it focuses on a common container security decision point: whether an image from a public or unknown registry becomes running code in a Linux container environment and then behaves unexpectedly. For leaders, the value is not just spotting a bad container; it is validating that teams can connect image provenance, container startup, runtime process activity, and outbound network behavior quickly enough to support containment decisions.
Executive priority
Prioritize this where Docker, Kubernetes, or containerd workloads are part of production or development operations. The business question is whether the organization can prove which images are allowed, who or what pulled them, when they started, and whether runtime behavior deviated from expected workload patterns. This supports incident response readiness, cloud/container governance, audit evidence around software supply-chain controls, and budget decisions for container runtime telemetry and policy enforcement.
Technical view
For SOC, detection engineering, and IR teams, validate correlation across the full sequence described by AN0691: image creation or download, container creation, container start, then command execution or outbound network activity within a short window and tied to a consistent image digest. The analytic is Linux-focused and applies to Docker, Kubernetes, and containerd environments. Since no official detection logic is supplied, teams should define local baselines for expected registries, namespaces, workloads, container images, utilities, and egress patterns before treating alerts as high confidence.
Likely telemetry
- Container image pull/download events from Docker, Kubernetes, or containerd environments
- Container creation and container start events
- Image registry, repository, tag, and digest metadata
- Process execution telemetry from inside or associated with containers, especially utilities such as curl, wget, bash, or python
- Outbound network connection telemetry by container, namespace, pod, or workload
Detection direction
- Correlate image pull/download, container create, container start, and runtime execution/network activity within a short time window using the same image digest.
- Flag public or unknown registries based on an organization-maintained registry trust policy rather than hard-coded assumptions alone.
- Tune for expected administrative, CI/CD, debugging, and build workloads that may legitimately pull images or run utilities such as shell, curl, wget, or python.
- Validate whether telemetry preserves container-to-process and container-to-network attribution; host-only logs may lose the namespace or workload context needed for confident triage.
- Use workload baselines to distinguish normal egress patterns from outbound connections that are atypical for the namespace or application.
Mitigation priorities
- Establish and enforce trusted registry and approved image source policies for container workloads.
- Require image digest tracking so investigations can tie pulls, starts, and runtime behavior to the same artifact.
- Reduce unnecessary runtime utilities in production containers where operationally feasible, because their unexpected execution is part of the analytic signal.
- Apply egress controls and workload-specific network policy so unusual outbound connections are constrained and visible.
- Ensure incident response playbooks cover container isolation, image provenance review, and collection of container runtime evidence.
Analyst notes and limits
AN0691 is a detection analytic rather than a technique object. Its strongest decision value is in testing whether container security telemetry is joined end-to-end across supply-chain provenance and runtime behavior. Because no tactic, relationship context, or official detection query is provided, local environment baselines are essential.
The supplied ATT&CK fields do not include official detection logic, related techniques, adversary use, mitigations, or tactics. This take is limited to the Linux container behavior explicitly described in the object and should not be interpreted as evidence of active exploitation or guaranteed detection coverage.
Analytic 0691
CONTAINERS (Docker/K8s/containerd): A user pulls an untrusted image from a public/unknown registry and then creates/starts a container from that image. Shortly after start, the container spawns unexpected utilities (e.g., curl/wget/bash/python), or makes outbound network connections atypical for the namespace/workload. The analytic correlates Image Creation/Download → Container Creation → Container Start → Command Execution/Network activity within a short window and with a consistent image digest.
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 | f1945f92774e… |
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 AN0691Open 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.