AN0693: Analytic 0693
Remote/API driven creation **and** start of a container whose image is not on an allow‑list (or is tagged `latest`), executed by a non-admin principal, and/or started with risky runtime attributes (e.g., `--privileged`, host PID/NET namespaces, sensitive host path mounts, capability adds). Correlates *create* ➜ *start* ➜ first network/process actions from that container within a short time window.
Analyst context for executives and security teams
This analytic is about spotting risky container launches through remote or API-driven workflows: a container is created and started from an unapproved image or a `latest` tag, by a non-admin principal, and/or with dangerous runtime settings such as privileged mode, host namespaces, sensitive host mounts, or added capabilities. For leaders, the practical issue is control over what is allowed to run in container environments and whether risky launches are visible quickly enough for response.
Executive priority
Treat this as a container governance and incident-readiness validation point. Security leaders should ask whether container image allow-listing, runtime policy, identity permissions, and logging can prove who created and started a risky container, what image was used, and what the container did first. This matters for resilience, audit evidence, and response speed because container misuse may not be obvious if teams only monitor host or application logs and not container API activity and runtime attributes.
Technical view
For SOC, detection engineering, and IR teams, the core validation is correlation: container create event, container start event, and the first network or process activity from that container within a short time window. The analytic is scoped to Containers. Key conditions to test include images not on an allow-list, images tagged `latest`, non-admin principals, privileged execution, host PID or network namespace use, sensitive host path mounts, and added Linux capabilities. Because no official detection logic is supplied, teams need to implement environment-specific rules using their container platform telemetry and local policy definitions.
Likely telemetry
- Container API audit logs showing create and start actions
- Principal or service account identity associated with container creation/start
- Container image name, registry, digest, tag, and allow-list status
- Runtime configuration attributes such as privileged mode, namespace settings, mounted host paths, and added capabilities
- Container start timestamps correlated with subsequent process execution telemetry
Detection direction
- Validate that create and start events are both collected and can be joined by container ID or equivalent metadata.
- Tune image allow-list logic to avoid relying only on mutable tags; flag `latest` where local policy treats it as risky.
- Correlate risky runtime attributes with the initiating principal to distinguish approved administrative workflows from unusual non-admin activity.
- Confirm visibility into the first process and network actions after start, because the analytic depends on short-window post-start behavior.
- Document known-good exceptions for build systems, CI/CD runners, and administrative automation to manage false positives.
Mitigation priorities
- Define and maintain approved container image sources, tags, or digests according to local policy.
- Restrict who can create and start containers, especially with privileged mode, host namespaces, sensitive host mounts, or added capabilities.
- Enforce runtime guardrails that prevent or require approval for high-risk container attributes.
- Ensure container audit, identity, runtime, process, and network telemetry are centrally collected for SOC and IR use.
- Create response playbooks for investigating a risky container launch, including image provenance, initiating principal, runtime settings, first actions, and affected host scope.
Analyst notes and limits
This object is a detection analytic, not a full ATT&CK technique entry. The supplied fields identify the platform as Containers and describe the analytic behavior, but do not provide tactics, formal detection pseudocode, mitigations, or relationship context. Local container platform design, policy definitions, and logging architecture will determine how directly this can be implemented.
The official detection field is not provided and no relationships are supplied. This take does not infer active exploitation, adversary attribution, business impact, or guaranteed detection coverage. It is limited to the official description, platform, external reference, and object metadata supplied.
Analytic 0693
Remote/API driven creation **and** start of a container whose image is not on an allow‑list (or is tagged `latest`), executed by a non-admin principal, and/or started with risky runtime attributes (e.g., `--privileged`, host PID/NET namespaces, sensitive host path mounts, capability adds). Correlates *create* ➜ *start* ➜ first network/process actions from that container within a short time window.
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 | d8f1f04d718c… |
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 AN0693Open 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.