DET0083: Container CLI and API Abuse via Docker/Kubernetes (T1059.013)
This detection strategy matters because it is tied to abuse of Docker or Kubernetes-style command-line and API interfaces to execute commands in containeri...
Analyst context for executives and security teams
This detection strategy matters because it is tied to abuse of Docker or Kubernetes-style command-line and API interfaces to execute commands in containerized environments. For leaders, the practical question is whether container administration paths are observable and governed well enough that suspicious execution through built-in tooling would be noticed before it affects workloads or incident response confidence.
Executive priority
Prioritize this as a container execution visibility and control issue. If the business depends on containerized services, security leaders should confirm who can use container CLIs or APIs, whether that activity is logged, and whether SOC/IR teams can distinguish expected administration from suspicious command execution. It is also relevant for audit evidence around privileged access, change control, and operational resilience in container environments.
Technical view
This object is a MITRE detection strategy for T1059.013, Container CLI/API, under the execution tactic with Containers as the related platform. Because the official detection and description fields are not provided for DET0083, teams should validate coverage against the related technique behavior: command execution through built-in container management CLIs, SDKs, or API calls such as Docker-related interfaces. Detection engineering should focus on administrative command/API activity, execution within containers, and access to exposed container daemon/API endpoints, while accounting for legitimate DevOps and platform operations.
Likely telemetry
- Container runtime and daemon logs, where available
- Docker CLI, Docker Compose, Docker Desktop CLI, or SDK/API usage records where collected
- Kubernetes or container orchestration API audit logs if present in the environment
- Host process execution logs showing container management tools or clients
- Authentication and authorization logs for users, service accounts, or automation interacting with container APIs
Detection direction
- Inventory where Docker or Kubernetes-style CLIs, SDKs, and APIs are used legitimately, then baseline expected administrative patterns.
- Validate that SOC tooling receives logs for container management activity, not only workload application logs.
- Tune detections around unusual command execution through container management interfaces, especially outside expected users, service accounts, hosts, pipelines, or maintenance windows.
- Account for false positives from CI/CD systems, platform engineering automation, break-glass administration, and routine troubleshooting.
- Look for blind spots where local Docker daemon access, exposed API endpoints, developer workstations, or unmanaged container hosts are not centrally logged.
Mitigation priorities
- Restrict access to container management CLIs and APIs to approved administrators, service accounts, and automation paths.
- Ensure container API endpoints and daemon interfaces are not broadly exposed and require appropriate authentication and authorization.
- Centralize audit logging for container runtime and orchestration activity so IR teams can reconstruct command execution paths.
- Separate routine DevOps automation from privileged break-glass access to make anomalous use easier to identify.
- Review compliance evidence for privileged container administration, logging retention, and change accountability.
Analyst notes and limits
The strongest relationship-driven context is that DET0083 detects ATT&CK technique T1059.013, Container CLI/API, associated with execution in container environments. The supplied MITRE fields do not include an official detection narrative, so this take emphasizes validation questions and evidence classes rather than a specific analytic rule.
Official description, official detection text, object-level platforms, and object-level tactics are not provided for DET0083. Conclusions should be validated against local container architecture, logging configuration, identity model, and normal DevOps workflows.
Container CLI and API Abuse via Docker/Kubernetes (T1059.013)
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 | T1059.013 | Container CLI/API Sub-technique | This object detects Container CLI/API. |
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 | 402ab6f74566… |
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 DET0083Open 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.