DET0249: Behavior-chain detection for T1610 Deploy Container across Docker & Kubernetes control/node planes
MITRE ATT&CK DET0249: Behavior-chain detection for T1610 Deploy Container across Docker & Kubernetes control/node planes Detection Strategy details, with detection…
Security context for executives and security teams
DET0249 is about detecting the behavior chain around adversaries deploying containers for execution, specifically in Docker and Kubernetes-oriented environments. For leaders, the significance is that container deployment is a normal business operation, so the risk is not just “a container was created,” but whether deployment activity can be tied back to an authorized pipeline, identity, namespace, node, image, and policy posture.
Executive priority
Prioritize this as a control-validation topic for containerized environments: can the organization prove who or what is allowed to deploy containers, whether deployments bypass expected network or user limitations, and whether SOC/IR teams can reconstruct the control-plane-to-node-plane sequence during an incident. This supports resilience, audit evidence, and cloud/container security governance without assuming exploitation is occurring.
Technical view
The related ATT&CK technique is T1610 Deploy Container under Execution for Containers. Because the official detection text is not provided, teams should treat DET0249 as a validation prompt: correlate Kubernetes or Docker deployment intent with runtime evidence on nodes. Focus on whether container creation/start events, image use, service account or user identity, namespace/project context, admission decisions, and runtime process/network behavior line up with approved deployment paths.
Likely telemetry
- Kubernetes API audit logs for pod, deployment, job, or related workload creation and modification
- Docker daemon or container runtime events for image pull, container create, start, exec, and stop activity
- Container orchestration control-plane logs, including admission, authorization, and scheduler-related records where available
- Node-level process, command, and container runtime logs linking workload creation to execution
- Identity and access logs for users, service accounts, tokens, and automation accounts that request deployments
Detection direction
- Validate behavior-chain correlation rather than relying on a single container-created event.
- Baseline approved deployment mechanisms such as CI/CD systems, controllers, service accounts, namespaces, and expected image sources.
- Tune for suspicious mismatches: unusual identity deploying workloads, unexpected namespace or node placement, unapproved image source, anomalous container configuration, or deployment followed by unusual process or network activity.
- Account for high false-positive potential because container deployment is routine in DevOps environments.
- Check blind spots between control plane and node plane: Kubernetes audit visibility may show intent, while node/runtime telemetry confirms execution.
Mitigation priorities
- Enforce least-privilege deployment rights for users, service accounts, and automation identities.
- Require approved deployment paths and change-controlled workload definitions for production environments.
- Use admission or policy controls to restrict risky container settings such as excessive privileges, weak user constraints, or missing network limitations.
- Maintain trusted image source and image governance controls so deployed containers can be tied to approved registries and build processes.
- Ensure runtime monitoring and incident response procedures can connect control-plane requests to node-level execution evidence.
Additional notes and limits
The supplied ATT&CK object is a detection strategy with no official description or detection text, but its name and relationship to T1610 provide useful scope: behavior-chain detection for Deploy Container across Docker and Kubernetes control/node planes. Local architecture matters heavily; the right logic depends on whether Docker, Kubernetes, managed orchestration, CI/CD automation, or other container platforms are present.
Platforms and tactics are not specified on the detection strategy itself, and no official detection analytics are supplied. The related technique lists Containers and Execution, and the strategy name references Docker and Kubernetes, but coverage, exploit activity, attribution, and business exposure cannot be inferred from the provided fields alone.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Behavior-chain detection for T1610 Deploy Container across Docker & Kubernetes control/node planes
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1610 | Deploy Container | This object detects Deploy Container. |
All related ATT&CK context
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 | f700488cdf63… |
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-attackDET0249Open source URL
- [2]mitre-attackDET0249Open source URL
- [3]mitre-attackDET0249Open 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.