DC0072: Container Creation
"Container Creation" data component captures details about the initial construction of a container in a containerized environment. This includes events where a new container is instantiated, such as through Docker, Kubernetes, or other container orchestration platforms. Monitoring these events helps detect unauthorized or potentially malicious container creation. Examples:
- Docker Example: `docker create my-container`, `docker run --name=my-container nginx:latest` - Kubernetes Example: `kubectl run my-pod --image=nginx`, `kubectl create deployment my-deployment --image=nginx` - Cloud Container Services Example - AWS ECS: Task or service creation (`RunTask` or `CreateService`). - Azure Container Instances: Deployment of a container group. - Google Kubernetes Engine (GKE): Creation of new pods via GCP APIs.
Analyst context for executives and security teams
Container Creation is a data component for recording when a new container, pod, task, service, deployment, or container group is instantiated in a containerized environment. For security leaders, its value is operational visibility: if the organization cannot reliably see new container creation across Docker, Kubernetes, and cloud container services, it may miss unauthorized workloads, policy bypass, or incident scope expansion in modern application environments.
Executive priority
Prioritize this as a cloud and container visibility control. It supports incident response scoping, audit evidence for workload governance, and SOC readiness by answering a basic business question: who or what is creating runtime workloads, from which control plane, and under what approval path? Because ATT&CK provides no tactics, techniques, or detection logic for this data component, leadership should treat it as foundational telemetry rather than a complete detection outcome.
Technical view
Validate that container creation events are collected from relevant container and orchestration control planes identified in the ATT&CK description, such as Docker commands, Kubernetes pod or deployment creation, and cloud container service APIs including AWS ECS RunTask/CreateService, Azure Container Instances container group deployment, and GKE pod creation via GCP APIs. SOC and IR teams should ensure events preserve creator identity, source, target namespace or service context, image name/tag, runtime parameters, timestamps, and cloud or cluster location where available. Since no ATT&CK detection guidance or relationships are supplied, local baselining and environment-specific policy context are required.
Likely telemetry
- Docker container create/run events where available
- Kubernetes API audit events for pod, deployment, or workload creation
- Cloud provider API or activity logs for container task, service, pod, or container group creation
- Container orchestration control-plane logs
- Identity and access logs tied to the principal or service account that initiated creation
Detection direction
- Confirm telemetry coverage for all container creation paths, not only interactive CLI activity.
- Tune alerts around unauthorized creators, unexpected namespaces or projects, unusual image sources, and creation outside approved deployment workflows.
- Account for legitimate automation noise from CI/CD systems, orchestration controllers, and cloud services to reduce false positives.
- Validate whether events retain enough identity and workload metadata to support incident scoping and compliance evidence.
- Because no official detection text or relationship context is supplied, avoid assuming this data component maps to a specific ATT&CK technique without local or additional ATT&CK context.
Mitigation priorities
- Establish centralized collection of container creation events from container engines, orchestration platforms, and cloud container APIs in use.
- Require strong identity, role, and service-account governance for workload creation permissions.
- Define approved deployment paths and compare creation events against those expected workflows.
- Retain container creation telemetry long enough to support incident response, audit, and post-incident reconstruction.
- Review gaps where ephemeral workloads, managed container services, or separate cloud accounts/projects may not feed the SOC pipeline.
Analyst notes and limits
This object is a data component, not a technique. Its main defensive value is proving whether the organization can observe new containerized workloads at creation time. The supplied ATT&CK object includes examples for Docker, Kubernetes, AWS ECS, Azure Container Instances, and GKE, but does not specify platforms, tactics, relationships, or detection logic.
No official detection guidance, ATT&CK relationships, tactics, or platforms were supplied. Recommendations therefore focus on telemetry validation and control questions derived from the official description and must be adapted to the organization’s actual container platforms, cloud services, logging architecture, and deployment workflows.
Container Creation
"Container Creation" data component captures details about the initial construction of a container in a containerized environment. This includes events where a new container is instantiated, such as through Docker, Kubernetes, or other container orchestration platforms. Monitoring these events helps detect unauthorized or potentially malicious container creation. Examples:
- Docker Example: `docker create my-container`, `docker run --name=my-container nginx:latest` - Kubernetes Example: `kubectl run my-pod --image=nginx`, `kubectl create deployment my-deployment --image=nginx` - Cloud Container Services Example - AWS ECS: Task or service creation (`RunTask` or `CreateService`). - Azure Container Instances: Deployment of a container group. - Google Kubernetes Engine (GKE): Creation of new pods via GCP APIs.
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 | 2.0 | Current bundle | 11804eb6b04d… |
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 DC0072Open 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.