AN0177: Analytic 0177
Defenders may detect abuse of container administration commands by observing anomalous use of management utilities (`docker exec`, `kubectl exec`, or API calls to kubelet) correlated with unexpected process creation inside containers. Behavioral chains include unauthorized API requests followed by command execution within running pods or containers, often originating from unusual user accounts, automation scripts, or IP addresses outside the expected cluster management plane.
Analyst context for executives and security teams
This analytic is about spotting suspicious administrative command execution inside containers, such as unexpected use of docker exec, kubectl exec, or kubelet API-driven execution. For leaders, the value is not the command names themselves; it is whether the organization can distinguish normal container operations from unauthorized hands-on activity inside running workloads before it affects application availability, data handling, or incident scope.
Executive priority
Prioritize this where containers support business-critical services. The key executive question is whether container management activity is governed, logged, and reviewable across the expected cluster management plane. This supports operational resilience, incident decision-making, and audit evidence by showing who or what initiated administrative execution, from where, and whether it matched approved automation or support workflows.
Technical view
For SOC, detection engineering, and IR teams, validate visibility into container administration commands and related process creation inside containers. The supplied ATT&CK description highlights correlation: anomalous docker exec, kubectl exec, or kubelet API use should be assessed alongside unexpected process starts in running pods or containers, especially when initiated by unusual users, automation scripts, or IP addresses outside expected management sources. Because no ATT&CK detection logic is provided, local baselining of legitimate cluster operations is required.
Likely telemetry
- Container runtime activity showing administrative exec operations such as docker exec
- Kubernetes audit or control-plane records showing kubectl exec or equivalent API activity
- Kubelet API access logs where available
- Process creation telemetry from inside containers or pods
- Identity/account context for users, service accounts, and automation initiating container administration
Detection direction
- Baseline approved container management paths, administrators, service accounts, automation scripts, and source IP ranges before alerting on anomalies.
- Correlate management utility or API execution with new process creation inside the targeted container or pod.
- Treat activity from users, scripts, or IP addresses outside the expected cluster management plane as higher priority for triage.
- Tune for legitimate operational activity such as break-glass troubleshooting, CI/CD jobs, health checks, and platform maintenance to reduce false positives.
- Validate whether logs cover both the control-plane request and the workload-level process evidence; either source alone may be insufficient for confident triage.
Mitigation priorities
- Restrict container administrative execution to approved identities, roles, automation, and management networks.
- Review Kubernetes and container runtime access controls for least privilege around exec-style operations.
- Ensure audit logging is enabled and retained for container management APIs and workload process activity where supported.
- Document approved operational use cases for exec access so SOC teams can separate maintenance from suspicious behavior.
- Use incident response playbooks that preserve container, pod, identity, source IP, and process evidence when unexpected exec activity is observed.
Analyst notes and limits
This is a detection analytic object for the enterprise ATT&CK domain with Containers as the supported platform. The official description emphasizes behavioral correlation rather than a single indicator: management command or API use plus unexpected in-container process creation and unusual initiator context.
ATT&CK provides no separate official detection text, tactics, relationships, aliases, or labels for this object in the supplied data. Conclusions should therefore be limited to container environments and should not be used to claim existing detection coverage, active exploitation, attribution, or impact without local telemetry and investigation evidence.
Analytic 0177
Defenders may detect abuse of container administration commands by observing anomalous use of management utilities (`docker exec`, `kubectl exec`, or API calls to kubelet) correlated with unexpected process creation inside containers. Behavioral chains include unauthorized API requests followed by command execution within running pods or containers, often originating from unusual user accounts, automation scripts, or IP addresses outside the expected cluster management plane.
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 | 1.0 | Current bundle | 608e40bb0bbc… |
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 AN0177Open 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.