Container Administration Command

Exec into a container rarely opens the intrusion. The attacker needs a path in first, most often a misconfigured or internet-exposed Kubernetes API server, a leaked kubeconfig or service-account token, an SSRF against the cloud metadata service that yields cluster credentials, or a vulnerability in an internet-facing workload that hands over a shell inside one pod already. Container Administration Command is how that initial foothold gets turned into arbitrary command execution across the workloads the attacker's stolen identity can reach.

From there it typically feeds discovery and lateral movement: listing other pods and namespaces (T1613), reading mounted service-account tokens and secrets to pivot to new identities, or attempting to break out of the container entirely (T1611 Escape to Host) to reach the underlying node. TeamTNT's Hildegard campaign followed close to this shape, using kubelet-API and container-command execution for cryptomining deployment across a cluster once it had a way in. Siloscape went further, using its exec access specifically to reach Windows containers as a stepping stone toward the host and the wider Azure environment. The pattern to watch for is exec activity that clusters around discovery commands (whoami, cat /var/run/secrets/...) rather than the application-specific debugging a real engineer would run.

Legitimate exec traffic is constant in any active cluster. Developers debug failing pods with kubectl exec -it, CI/CD pipelines exec into containers to run migrations or health checks, and platform tooling such as Trident's storage controller or monitoring agents legitimately opens exec sessions as part of normal operation. A rule that fires on every pods/exec create request, with no other context, generates far more noise than signal in a busy engineering org.

The fix is identity- and namespace-aware tuning, not turning the detection off. Build an allow-list of the service accounts, CI runners, and platform-team human identities that legitimately exec, scoped to the namespaces they actually own, and reserve alerting for exec from anything outside that set, especially production or kube-system namespaces where routine debugging should be rare. Correlate with time of day and deployment schedule: an exec from a deploy bot at 3 AM during a scheduled release is expected, the same account exec'ing at 3 AM with no release in flight is not.

When the alert fires, first establish who did it and why: pull the requesting identity from the audit event's user field, check whether it is a human account or a service account, and confirm whether that identity has a documented reason to touch the target namespace and pod. Read the exec command from the requestURI query string if present, since a debugging session (cat, ls, tail) looks very different from a reverse shell or a package-manager invocation reaching out for tools.

If the identity or command is not accounted for, treat it as active compromise rather than a maintenance false positive. Revoke or rotate the credential (kubeconfig, service-account token, or IAM role) that authorized the exec, apply a network policy to cut the pod off from the rest of the cluster, and capture the container's filesystem and process list before it gets rescheduled or restarted, since a fresh container replacement destroys the evidence. Escalate immediately if the exec touched kube-system, a node with elevated permissions, or any pod holding secrets for other services, because from there the attacker is one T1611 escape or one stolen token away from the whole cluster.