DC0077: Container Start
"Container Start" data component captures events related to the activation or invocation of a container within a containerized environment. This includes starting a previously stopped container, restarting an existing container, or initializing a container for runtime. Monitoring these activities is critical for identifying unauthorized or unexpected container activations, which may indicate potential adversarial activity or misconfigurations. Examples:
- Docker Example: `docker start
This data component can be collected through the following measures:
- Docker Audit Logging: Enable Docker logging to capture start and restart events. Use tools like auditd to monitor terminal activity involving container lifecycle commands. - Kubernetes Audit Logs: Enable Kubernetes API server audit logging. - Cloud Provider Logs - AWS CloudTrail: Capture StartTask or related API calls for ECS. - Azure Monitor: Track activity in container groups that indicate start or restart events. - GCP Cloud Logging: Record logs related to pod restarts or scaling events in Kubernetes Engine. - SIEM Integration: Collect logs from Docker, Kubernetes, and cloud services to correlate container start events.
Analyst context for executives and security teams
Container Start is the evidence trail for when a container is started, restarted, or initialized for runtime. For leaders, its value is not just technical visibility: unexpected container activation can indicate unauthorized activity, misconfiguration, or operational drift in containerized environments. If the organization relies on Docker, Kubernetes, or cloud container services, this telemetry helps answer whether runtime changes are expected, approved, and explainable during an incident or audit.
Executive priority
Prioritize this data component where containers support business-critical applications or regulated workloads. The key management question is whether security and operations teams can reconstruct who or what caused a container to start or restart, especially across Kubernetes and cloud-provider control planes. This supports incident response, change validation, compliance evidence, and resilience reviews by distinguishing normal lifecycle automation from suspicious or unauthorized activation.
Technical view
SOC and IR teams should validate collection of container lifecycle events from the relevant control plane and runtime sources identified by ATT&CK: Docker logging and auditd-style command monitoring, Kubernetes API server audit logs, AWS CloudTrail events such as ECS StartTask, Azure Monitor activity for container groups, GCP Cloud Logging for GKE-related restarts or scaling, and SIEM correlation across these sources. Because no ATT&CK detection analytic is provided for this component, teams should build local baselines for expected restarts, health-check-driven restarts, configuration changes, scaling events, and operator-initiated starts.
Likely telemetry
- Docker start and restart events from Docker logging
- Terminal or process/audit records showing container lifecycle commands such as docker start or docker restart
- Kubernetes API server audit logs for pod/container lifecycle activity
- Cloud provider control-plane logs, including AWS CloudTrail ECS StartTask or related calls
- Azure Monitor activity for container group start or restart events
Detection direction
- Confirm that container start and restart events are collected from both runtime and orchestration layers; relying on only one layer can miss context.
- Baseline expected restarts from Kubernetes lifecycle management, health checks, configuration changes, scaling, and node/pod management to reduce false positives.
- Correlate start events with identity, API caller, source, workload, namespace/project/account, and recent configuration changes where those fields are available locally.
- Alert on unexpected activation of stopped containers, restarts outside normal deployment windows, or starts lacking an approved operational explanation, using local change-management context.
- Validate SIEM normalization so Docker, Kubernetes, and cloud-provider events are searchable as comparable container lifecycle activity.
Mitigation priorities
- Enable and retain audit logging for the container runtimes, orchestration platforms, and cloud services in use.
- Integrate Docker, Kubernetes, and cloud provider logs into the SIEM for correlation rather than reviewing each source in isolation.
- Define expected container lifecycle patterns for critical workloads, including legitimate automated restarts and scaling behavior.
- Tie container start monitoring to change management and incident response procedures so unexpected activations can be triaged quickly.
- Review access controls around container lifecycle operations so only authorized identities and services can start or restart workloads.
Analyst notes and limits
This ATT&CK object is a data component, not a technique. Its defensive value is evidentiary: it helps teams observe container activation and support investigation of unexpected runtime changes. The official description provides collection examples across Docker, Kubernetes, AWS ECS, Azure Container Instances, and GCP Kubernetes Engine, but no specific detection analytic or relationship context is supplied.
Platforms and tactics are not specified for this object, and no relationships or official detection logic were supplied. Local environment details are required to determine which container technologies are in scope, what constitutes normal restart behavior, and what alert thresholds are appropriate.
Container Start
"Container Start" data component captures events related to the activation or invocation of a container within a containerized environment. This includes starting a previously stopped container, restarting an existing container, or initializing a container for runtime. Monitoring these activities is critical for identifying unauthorized or unexpected container activations, which may indicate potential adversarial activity or misconfigurations. Examples:
- Docker Example: `docker start
This data component can be collected through the following measures:
- Docker Audit Logging: Enable Docker logging to capture start and restart events. Use tools like auditd to monitor terminal activity involving container lifecycle commands. - Kubernetes Audit Logs: Enable Kubernetes API server audit logging. - Cloud Provider Logs - AWS CloudTrail: Capture StartTask or related API calls for ECS. - Azure Monitor: Track activity in container groups that indicate start or restart events. - GCP Cloud Logging: Record logs related to pod restarts or scaling events in Kubernetes Engine. - SIEM Integration: Collect logs from Docker, Kubernetes, and cloud services to correlate container start events.
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 | 34a41929fe7a… |
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 DC0077Open 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.