DET0065: Detection Strategy for Container Administration Command Abuse
DET0065 is a MITRE ATT&CK detection strategy object for identifying abuse of container administration capabilities to run commands inside containers. Its b...
Analyst context for executives and security teams
DET0065 is a MITRE ATT&CK detection strategy object for identifying abuse of container administration capabilities to run commands inside containers. Its business value is in forcing teams to validate whether container control-plane activity is observable enough to distinguish normal operations from unauthorized execution behavior. Because the object has no official detection text or platform list of its own, coverage decisions should be driven by the related ATT&CK technique, T1609 Container Administration Command, which is associated with Execution on Containers.
Executive priority
Treat this as a container operations resilience and incident-readiness question: if an attacker or unauthorized insider can use Docker, Kubernetes API server, kubelet, or similar administration services to execute commands, can the organization prove who did it, from where, against which workload, and whether it was approved? Leaders should prioritize auditability of container administration paths, identity governance for container control planes, and response procedures for suspicious administrative execution in production workloads.
Technical view
SOC, detection engineering, and IR teams should validate monitoring around container administration services rather than assume endpoint-style telemetry is enough. The related technique describes abuse of Docker daemon, Kubernetes API server, kubelet, or similar services to execute commands within containers. Detection work should therefore focus on administrative API activity, container runtime events, workload changes, and identity context tied to command execution or altered container start behavior. Because the ATT&CK detection strategy record does not provide official analytic logic, thresholds, or data sources, local baselining of normal platform administration is required.
Likely telemetry
- Kubernetes API server audit logs, where Kubernetes is in use
- Kubelet logs or node-level container administration activity, where available
- Docker daemon or container runtime logs, where Docker or similar runtimes are used
- Container lifecycle events, including creation, start, exec-like activity, and entrypoint or command changes
- Identity and access logs for users, service accounts, tokens, and administrative clients interacting with container control planes
Detection direction
- Confirm which container administration services exist in the environment and whether their administrative actions are centrally logged.
- Map privileged container administration actions to authenticated identities and source systems; gaps in identity attribution are a major blind spot.
- Baseline expected automation, CI/CD, SRE, and platform-team activity to reduce false positives from legitimate operational troubleshooting.
- Prioritize alerts for unusual administrative execution against production, sensitive, or externally exposed workloads, especially when identity, source, time, or target workload context is abnormal.
- Correlate control-plane activity with container runtime events and workload changes; relying on only one log source may miss context needed for triage.
Mitigation priorities
- Restrict and review permissions for container administration services, especially capabilities that allow command execution inside containers.
- Ensure audit logging is enabled and retained for container control-plane and runtime administration activity.
- Require strong identity controls for administrative access, including service account governance and separation of duties where applicable.
- Limit remote management exposure for container administration services and monitor administrative access paths.
- Maintain incident response procedures for suspicious container administration activity, including workload isolation, credential review, and evidence preservation.
Analyst notes and limits
This take is based on the DET0065 detection strategy metadata and its relationship to ATT&CK technique T1609 Container Administration Command. The detection strategy object does not include an official description, detection logic, tactics, or platforms. The related technique supplies the relevant context: Execution tactic, Containers platform, and container administration services such as Docker daemon, Kubernetes API server, and kubelet.
No active exploitation, attribution, impact, or guaranteed detection coverage is stated by the supplied fields. Specific analytic rules, data-source requirements, and vendor implementations are not provided by the object and must be derived from the local container architecture, logging configuration, and operational baseline.
Detection Strategy for Container Administration Command Abuse
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 | T1609 | Container Administration Command | This object detects Container Administration Command. |
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 | a80f2faa751c… |
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 DET0065Open 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.