heroui logo

Kubernetes Ephemeral Container Added to Pod

Elastic Detection Rules

View Source
Summary
This rule detects when an ephemeral container is added to an existing Kubernetes pod by a non-system identity, using the Kubernetes audit logs as the data source. Ephemeral containers are intended for debugging (e.g., kubectl debug), but can be abused to gain interactive access, read sensitive files, or run tools inside a running pod. Abuse can enable privilege escalation, lateral movement, or persistence without deploying a new workload. The detection looks for updates or patches to the pods/ephemeralcontainers subresource in the Kubernetes audit stream (logs-kubernetes.audit_logs-*) where the authorization decision is allowed, and excludes system accounts (e.g., system:node:*, system:serviceaccount:kube-system:*). The rule’s query targets non-system actors, signaling potential misuse of RBAC to inject tooling or exfiltrate data. A complementary investigation should verify the actor identity (user.name, groups), source IP, and user_agent, and inspect kubernetes.audit.objectRef (namespace, name) to identify the pod and owner. If request bodies are captured, examine the ephemeral container image, command, and securityContext for privilege indicators. Correlate with follow-on activity such as pod exec, secret reads, TokenRequest, or RBAC modifications to confirm malicious behavior. Remediation involves trimming RBAC to restrict update/patch on pods/ephemeralcontainers, rotating exposed credentials, quarantining or redeploying affected workloads, and hunting for additional compromised pods or identities. The rule maps to MITRE ATT&CK techniques T1611 (Escape to Host) and T1609 (Container Administration Command).
Categories
  • Kubernetes
  • Containers
Data Sources
  • Pod
  • Container
ATT&CK Techniques
  • T1611
  • T1609
Created: 2026-05-07