AWS EKS Privileged Pod Created

  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 when a user creates a pod/container running in privileged mode. A highly privileged container has
 13access to the node's resources and breaks the isolation between containers. If compromised, an attacker can use the
 14privileged container to gain access to the underlying host. Gaining access to the host may provide the adversary with
 15the opportunity to achieve follow-on objectives, such as establishing persistence, moving laterally within the
 16environment, or setting up a command and control channel on the host.
 17"""
 18false_positives = [
 19    """
 20    By default a container is not allowed to access any devices on the host, but a "privileged" container is given
 21    access to all devices on the host. This allows the container nearly all the same access as processes running on the
 22    host. An administrator may want to run a privileged container to use operating system administrative capabilities
 23    such as manipulating the network stack or accessing hardware devices from within the cluster. Add exceptions for
 24    trusted container images using the query field "aws.eks.audit.requestObject.spec.container.image"
 25    """,
 26]
 27from = "now-6m"
 28index = ["logs-aws.eks_audit-*"]
 29language = "kuery"
 30license = "Elastic License v2"
 31name = "AWS EKS Privileged Pod Created"
 32note = """## Triage and analysis
 33
 34> **Disclaimer**:
 35> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
 36
 37### Investigating AWS EKS Privileged Pod Created
 38Kubernetes allows for the creation of privileged pods, which can access the host's resources, breaking container isolation. Adversaries may exploit this to escalate privileges, access sensitive data, or establish persistence. The detection rule identifies such events by monitoring audit logs for pod creation with privileged settings, excluding known safe images, to flag potential security threats.
 39
 40### Possible investigation steps
 41
 42- Review the Kubernetes audit logs to identify the user or service account responsible for creating the privileged pod by examining the `aws.eks.audit.annotations.authorization_k8s_io/decision` and `aws.eks.audit.verb:create` fields.
 43- Investigate the context of the privileged pod creation by checking the `aws.eks.audit.requestObject.spec.containers.image` field to determine if the image used is known or potentially malicious.
 44- Assess the necessity and legitimacy of the privileged pod by consulting with the relevant development or operations teams to understand if there was a valid reason for its creation.
 45- Examine the `aws.eks.audit.objectRef.resource:pods` field to identify the specific pod and its associated namespace, and verify if it aligns with expected deployment patterns or environments.
 46- Check for any subsequent suspicious activities or anomalies in the Kubernetes environment that may indicate further exploitation attempts, such as lateral movement or data exfiltration, following the creation of the privileged pod.
 47
 48### False positive analysis
 49
 50- Known safe images like "docker.elastic.co/beats/elastic-agent:8.4.0" are already excluded from triggering alerts. Ensure that any additional internal or third-party images that are verified as safe are added to the exclusion list to prevent unnecessary alerts.
 51- Development and testing environments often use privileged pods for legitimate purposes. Consider creating separate rules or exceptions for these environments to avoid false positives while maintaining security in production.
 52- Automated deployment tools or scripts might create privileged pods as part of their normal operation. Review these tools and, if they are deemed safe, add their specific actions or images to the exclusion list.
 53- Regularly review and update the exclusion list to reflect changes in your environment, such as new safe images or changes in deployment practices, to maintain an accurate detection rule.
 54
 55### Response and remediation
 56
 57- Immediately isolate the affected node to prevent further exploitation and lateral movement within the cluster. This can be done by cordoning and draining the node to stop new pods from being scheduled and to safely evict existing pods.
 58- Terminate the privileged pod to stop any ongoing malicious activity. Ensure that the termination is logged for further analysis.
 59- Conduct a thorough review of the audit logs to identify any unauthorized access or actions taken by the privileged pod. Focus on any attempts to access sensitive data or escalate privileges.
 60- Reset credentials and access tokens that may have been exposed or compromised due to the privileged pod's access to the host's resources.
 61- Patch and update the Kubernetes environment and any affected nodes to address vulnerabilities that may have been exploited to create the privileged pod.
 62- Implement network segmentation and firewall rules to limit the communication capabilities of pods, especially those with elevated privileges, to reduce the risk of lateral movement.
 63- Escalate the incident to the security operations team for a comprehensive investigation and to assess the need for further security measures or incident response actions."""
 64references = [
 65    "https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/1/CTR_KUBERNETES%20HARDENING%20GUIDANCE.PDF",
 66    "https://kubernetes.io/docs/tasks/configure-pod-container/security-context/",
 67]
 68risk_score = 47
 69rule_id = "a6451c73-7be4-51ac-a4c7-1acded7a56b2"
 70setup = """This rule reads EKS control-plane audit logs collected by the AWS integration
 71into `logs-aws.eks_audit-*`, where the AWS EKS audit ingest
 72pipelines normalize each audit record under `aws.eks.audit.*`.
 73
 74Enable the `audit` control-plane log type on the EKS cluster, send its
 75CloudWatch log group through the AWS integration, and confirm events carry
 76`data_stream.dataset: aws.eks_audit` and
 77`cloud.provider: aws` before enabling this rule.
 78"""
 79severity = "medium"
 80tags = [
 81    "Domain: Cloud",
 82    "Domain: Containers",
 83    "Platform: AWS",
 84    "Platform: Kubernetes",
 85    "Data Source: AWS",
 86    "Data Source: Amazon Web Services",
 87    "Data Source: Kubernetes API Server Audit Logs",
 88    "Service: AWS EKS",
 89    "Use Case: Threat Detection",
 90    "Tactic: Execution",
 91    "Tactic: Privilege Escalation",
 92    "Rule Type: Custom Query (KQL)",
 93    "Threat: Container Escape",
 94    "Resources: Investigation Guide",
 95    "Profile: Beta",
 96]
 97timestamp_override = "event.ingested"
 98type = "query"
 99
100query = '''
101data_stream.dataset : "aws.eks_audit" and aws.eks.audit.annotations.authorization_k8s_io/decision:"allow" and
102aws.eks.audit.objectRef.resource:pods and aws.eks.audit.verb:create and aws.eks.audit.requestObject.spec.containers.securityContext.privileged:true and
103not aws.eks.audit.requestObject.spec.containers.image: (
104  *amazonaws.com/betsie/pipeline/pipeline-core* or mirror.gcr.io/aquasec/trivy* or rancher/mirrored-longhornio-longhorn-instance-manager* or quay.io/calico* or
105  rancher/system-agent* or openebs/m-exporter* or openebs/cstor-istgt* or ghcr.io/kubereboot/kured* or registry.k8s.io/sig-storage/csi-node-driver-registrar* or
106  registry.k8s.io/csi-secrets-store* or registry.gitlab.com/gitlab-org/gitlab-runner/gitlab-runner-helper* or sonarsource/sonar-scanner-cli* or
107  rancher/mirrored-longhornio-longhorn-engine* or jenkins/inbound-agent* or registry.k8s.io/dns/k8s-dns-node-cache* or
108  *amazonaws.com/eks/kube-proxy* or *amazonaws.com/eks/aws-efs-csi-driver* or *amazonaws.com/eks/livenessprobe* or *amazonaws.com/amazon-k8s-cni* or
109  *amazonaws.com/amazon/aws-network-policy-agent* or openebs/node-disk-manager* or openebs/node-disk-exporter* or
110  public.ecr.aws/eks-distro/kubernetes-csi/livenessprobe* or public.ecr.aws/eks-distro/kubernetes-csi/external-provisioner* or
111  amazon/aws-efs-csi-driver* or registry.k8s.io/kube-proxy* or registry.crowdstrike.com/falcon-sensor* or *octopus-deploy/tentacle* or */sysdig/*
112)
113'''
114
115
116[[rule.threat]]
117framework = "MITRE ATT&CK"
118[[rule.threat.technique]]
119id = "T1611"
120name = "Escape to Host"
121reference = "https://attack.mitre.org/techniques/T1611/"
122
123
124[rule.threat.tactic]
125id = "TA0004"
126name = "Privilege Escalation"
127reference = "https://attack.mitre.org/tactics/TA0004/"
128[[rule.threat]]
129framework = "MITRE ATT&CK"
130[[rule.threat.technique]]
131id = "T1610"
132name = "Deploy Container"
133reference = "https://attack.mitre.org/techniques/T1610/"
134
135
136[rule.threat.tactic]
137id = "TA0002"
138name = "Execution"
139reference = "https://attack.mitre.org/tactics/TA0002/"