AWS EKS Container Created with Excessive Linux Capabilities

  1[metadata]
  2creation_date = "2026/08/03"
  3integration = ["aws"]
  4maturity = "production"
  5min_stack_comments = "The AWS integration adds the aws.eks_audit data stream in package 8.9.0, which requires Kibana 9.6.0 or later."
  6min_stack_version = "9.6.0"
  7updated_date = "2026/10/21"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12This rule detects a container deployed with one or more dangerously permissive Linux capabilities. An attacker with the
 13ability to deploy a container with added capabilities could use this for further execution, lateral movement, or
 14privilege escalation within a cluster. The capabilities detected in this rule have been used in container escapes to the
 15host machine.
 16"""
 17false_positives = [
 18    """
 19    Some container images require the addition of privileged capabilities. This rule leaves space for the exception of
 20    trusted container images. To add an exception, add the trusted container image name to the query field,
 21    aws.eks.audit.requestObject.spec.containers.image.
 22    """,
 23]
 24from = "now-6m"
 25index = ["logs-aws.eks_audit-*"]
 26language = "kuery"
 27license = "Elastic License v2"
 28name = "AWS EKS Container Created with Excessive Linux Capabilities"
 29note = """## Triage and analysis
 30
 31### Investigating AWS EKS Container Created with Excessive Linux Capabilities
 32Linux capabilities were designed to divide root privileges into smaller units. Each capability grants a thread just enough power to perform specific privileged tasks. In Kubernetes, containers are given a set of default capabilities that can be dropped or added to at the time of creation. Added capabilities entitle containers in a pod with additional privileges that can be used to change
 33core processes, change network settings of a cluster, or directly access the underlying host. The following have been used in container escape techniques:
 34
 35BPF - Allow creating BPF maps, loading BPF Type Format (BTF) data, retrieve JITed code of BPF programs, and more.
 36DAC_READ_SEARCH - Bypass file read permission checks and directory read and execute permission checks.
 37NET_ADMIN - Perform various network-related operations.
 38SYS_ADMIN - Perform a range of system administration operations.
 39SYS_BOOT - Use reboot(2) and kexec_load(2), reboot and load a new kernel for later execution.
 40SYS_MODULE - Load and unload kernel modules.
 41SYS_PTRACE - Trace arbitrary processes using ptrace(2).
 42SYS_RAWIO - Perform I/O port operations (iopl(2) and ioperm(2)).
 43SYSLOG - Perform privileged syslog(2) operations.
 44
 45### Possible investigation steps
 46
 47- Identify the principal that created the pod via user.name, aws.eks.audit.user.groups, source.ip, and user_agent.original, and determine whether it is a human operator, a CI/CD pipeline, or a controller such as a Deployment or DaemonSet acting on behalf of a workload owner.
 48- Review aws.eks.audit.requestObject.spec.containers.image and aws.eks.audit.requestObject.spec.containers.securityContext.capabilities.add to establish which image requested which capabilities, and whether the image comes from a trusted registry and tag.
 49- Inspect the rest of the pod spec in aws.eks.audit.requestObject.spec for other escape primitives that often accompany added capabilities, such as privileged: true, hostPID, hostNetwork, hostIPC, or sensitive hostPath volumes.
 50- Check aws.eks.audit.objectRef.namespace and the owning workload (ownerReferences) to understand whether the pod belongs to an expected security, networking, or storage agent, or was created ad hoc in an application namespace.
 51- Correlate with surrounding audit events from the same identity, such as pod exec, secret reads, TokenRequest, or RBAC changes, and with host telemetry from the node for signs of container breakout.
 52
 53### False positive analysis
 54
 55- While these capabilities are not included by default in containers, some legitimate images may need to add them. This rule leaves space for the exception of trusted container images. To add an exception, add the trusted container image name to the query field, aws.eks.audit.requestObject.spec.containers.image.
 56- Networking, storage, observability, and runtime-security agents (CNI plugins, eBPF-based tooling, CSI drivers, load balancer speakers) commonly require NET_ADMIN, SYS_ADMIN, BPF, or SYS_PTRACE. Confirm the image and namespace match the deployed agent and add a scoped exception on namespace plus image rather than on the capability alone.
 57
 58### Response and remediation
 59
 60- If the pod is not an approved workload, delete it and scale down or delete the owning controller so it is not recreated, then review the node it was scheduled on for signs of container escape or host modification.
 61- Revoke or tighten RBAC that allows the creating identity to create pods with added capabilities, and rotate credentials for that identity if the request looks unauthorized.
 62- Enforce Pod Security Admission (baseline or restricted) or an admission policy that restricts capabilities.add to an allowlist, scoped to namespaces where privileged agents are expected.
 63- If evidence of breakout is found, isolate and rebuild the affected node, rotate node and workload credentials, and engage incident response per policy.
 64- Add any confirmed-legitimate images to the rule exceptions, scoped by namespace and image, to keep the rule high-signal."""
 65references = [
 66    "https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container",
 67    "https://0xn3va.gitbook.io/cheat-sheets/container/escaping/excessive-capabilities",
 68    "https://man7.org/linux/man-pages/man7/capabilities.7.html",
 69    "https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities",
 70]
 71risk_score = 47
 72rule_id = "264a1d7c-be1b-57c2-a9b4-ec90559e2f68"
 73setup = """This rule reads EKS control-plane audit logs collected by the AWS integration
 74into `logs-aws.eks_audit-*`, where the AWS EKS audit ingest
 75pipelines normalize each audit record under `aws.eks.audit.*`.
 76
 77Enable the `audit` control-plane log type on the EKS cluster, send its
 78CloudWatch log group through the AWS integration, and confirm events carry
 79`data_stream.dataset: aws.eks_audit` and
 80`cloud.provider: aws` before enabling this rule.
 81"""
 82severity = "medium"
 83tags = [
 84    "Domain: Cloud",
 85    "Domain: Containers",
 86    "Platform: AWS",
 87    "Platform: Kubernetes",
 88    "Data Source: AWS",
 89    "Data Source: Amazon Web Services",
 90    "Data Source: Kubernetes API Server Audit Logs",
 91    "Service: AWS EKS",
 92    "Use Case: Threat Detection",
 93    "Tactic: Execution",
 94    "Tactic: Privilege Escalation",
 95    "Tactic: Defense Evasion",
 96    "Rule Type: Custom Query (KQL)",
 97    "Threat: Container Escape",
 98    "Resources: Investigation Guide",
 99    "Profile: Beta",
100]
101timestamp_override = "event.ingested"
102type = "query"
103
104query = '''
105data_stream.dataset: aws.eks_audit and aws.eks.audit.annotations.authorization_k8s_io/decision:"allow" and
106aws.eks.audit.verb: create and aws.eks.audit.objectRef.resource: pods and
107aws.eks.audit.requestObject.spec.containers.securityContext.capabilities.add: ("BPF" or "DAC_READ_SEARCH"  or "NET_ADMIN" or "SYS_ADMIN" or "SYS_BOOT" or "SYS_MODULE" or "SYS_PTRACE" or "SYS_RAWIO"  or "SYSLOG") and
108not (
109  aws.eks.audit.requestObject.spec.containers.image : (docker.elastic.co/beats/elastic-agent* or "") or
110  aws.eks.audit.objectRef.namespace:"kube-system" or
111  (aws.eks.audit.objectRef.namespace:datadog and aws.eks.audit.requestObject.spec.containers.image:*datadog-agent*) or
112  (aws.eks.audit.objectRef.namespace:kubearmor and aws.eks.audit.requestObject.spec.containers.image:(*kubearmor\:kubearmor* or kubearmor/kubearmor-snitch*)) or
113  (aws.eks.audit.objectRef.namespace:defender and aws.eks.audit.requestObject.spec.containers.image:*fp-prisma\:defender-defender*) or
114  (aws.eks.audit.objectRef.namespace:metallb-system and aws.eks.audit.requestObject.spec.containers.image:(quay.io/frrouting* or quay.io/metallb/speaker*)) or
115  (aws.eks.audit.objectRef.namespace:longhorn-system and aws.eks.audit.requestObject.spec.containers.image:rancher/mirrored-longhornio*)
116)
117'''
118
119
120[[rule.threat]]
121framework = "MITRE ATT&CK"
122[[rule.threat.technique]]
123id = "T1611"
124name = "Escape to Host"
125reference = "https://attack.mitre.org/techniques/T1611/"
126
127
128[rule.threat.tactic]
129id = "TA0004"
130name = "Privilege Escalation"
131reference = "https://attack.mitre.org/tactics/TA0004/"
132[[rule.threat]]
133framework = "MITRE ATT&CK"
134[[rule.threat.technique]]
135id = "T1610"
136name = "Deploy Container"
137reference = "https://attack.mitre.org/techniques/T1610/"
138
139
140[rule.threat.tactic]
141id = "TA0002"
142name = "Execution"
143reference = "https://attack.mitre.org/tactics/TA0002/"
144[[rule.threat]]
145framework = "MITRE ATT&CK"
146[[rule.threat.technique]]
147id = "T1610"
148name = "Deploy Container"
149reference = "https://attack.mitre.org/techniques/T1610/"
150
151
152[rule.threat.tactic]
153id = "TA0005"
154name = "Defense Evasion"
155reference = "https://attack.mitre.org/tactics/TA0005/"