AN0233: Analytic 0233
Execution of container orchestration commands (e.g., `docker exec`, `kubectl exec`) or API-driven interactions with running containers from unauthorized hosts or non-standard user contexts. Defender sees programmatic or interactive command execution within containers outside expected CI/CD tools or automation frameworks, often followed by file writes, privilege escalation, or lateral discovery.
Analyst context for executives and security teams
AN0233 focuses on command execution inside running containers from places or identities that should not be doing it, such as unauthorized hosts or non-standard user contexts. For leaders, this matters because container exec activity can bypass normal deployment paths and may indicate hands-on activity in production-like workloads outside approved CI/CD or automation controls.
Executive priority
Treat this as a cloud/container operations governance and incident-readiness question: who is allowed to run interactive or API-driven commands inside containers, from where, and with what evidence trail? Priority should be on proving that production container access is limited to approved automation and administrative paths, because gaps can affect business continuity, auditability, and the speed of incident containment.
Technical view
For SOC, detection engineering, and IR teams, validate visibility into container orchestration command execution such as docker exec, kubectl exec, and API-driven exec interactions. Since ATT&CK provides no separate detection logic and no tactic mapping for this analytic, local baselining is essential: compare execution source hosts, user contexts, service accounts, and CI/CD automation identities against expected patterns. Triage should look for follow-on container file writes, privilege escalation indicators, or lateral discovery activity when available.
Likely telemetry
- Container orchestration audit logs, including Kubernetes API audit events where applicable
- Docker or container runtime command and API activity logs
- Host and user identity context for systems initiating container exec actions
- CI/CD and automation framework logs to distinguish approved automation from unusual activity
- Container process execution telemetry
Detection direction
- Build an allowlist of expected CI/CD tools, automation frameworks, administrative hosts, and user or service-account contexts that legitimately execute commands in running containers.
- Alert on container exec activity from unauthorized hosts, unexpected users, non-standard service accounts, or sources outside normal deployment and operations workflows.
- Correlate exec activity with subsequent file writes, privilege escalation behavior, or lateral discovery to raise confidence and reduce noise.
- Tune carefully for legitimate break-glass administration, troubleshooting, and scheduled automation, which can otherwise create false positives.
- Identify blind spots where container runtime logs, Kubernetes audit logging, identity attribution, or CI/CD logs are missing or not centrally retained.
Mitigation priorities
- Define and enforce approved paths for interactive and API-driven access to running containers.
- Restrict container orchestration permissions so only authorized users, service accounts, and automation can execute commands in containers.
- Limit administrative access to approved management hosts or controlled automation environments.
- Ensure container orchestration and runtime audit logging is enabled, centralized, and retained for investigation and compliance evidence.
- Review exceptions such as emergency access and troubleshooting workflows so they are time-bound, attributable, and monitored.
Analyst notes and limits
The supplied object is a detection analytic for the Containers platform with no tactics specified, no relationships supplied, and no official detection logic beyond the behavior description. The most useful implementation work is therefore environment-specific baselining of legitimate container exec activity and correlation with identity, source host, automation, and post-execution behavior.
This take is limited to the provided ATT&CK fields and external reference. It does not establish active exploitation, threat actor use, impact, or guaranteed detection. Coverage depends on local container platform configuration, audit logging, identity integration, and knowledge of expected CI/CD and administrative workflows.
Analytic 0233
Execution of container orchestration commands (e.g., `docker exec`, `kubectl exec`) or API-driven interactions with running containers from unauthorized hosts or non-standard user contexts. Defender sees programmatic or interactive command execution within containers outside expected CI/CD tools or automation frameworks, often followed by file writes, privilege escalation, or lateral discovery.
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 | 9134b8b98917… |
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 AN0233Open 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.