AWS EKS Pod Created With HostIPC

  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 an attempt to create or modify a pod using the host IPC namespace. This gives access to data used by
 13any pod that also use the hosts IPC namespace. If any process on the host or any processes in a pod uses the hosts
 14inter-process communication mechanisms (shared memory, semaphore arrays, message queues, etc.), an attacker can
 15read/write to those same mechanisms. They may look for files in /dev/shm or use ipcs to check for any IPC facilities
 16being used.
 17"""
 18false_positives = [
 19    """
 20    An administrator or developer may want to use a pod that runs as root and shares the host's IPC, Network, and PID
 21    namespaces for debugging purposes. If something is going wrong in the cluster and there is no easy way to SSH onto
 22    the host nodes directly, a privileged pod of this nature can be useful for viewing things like iptable rules and
 23    network namespaces from the host's perspective. Add exceptions for trusted container images using the query field
 24    "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 Pod Created With HostIPC"
 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 Pod Created With HostIPC
 38Kubernetes allows pods to share the host's IPC namespace, enabling inter-process communication. While useful for legitimate applications, adversaries can exploit this to access shared memory and IPC mechanisms, potentially leading to data exposure or privilege escalation. The detection rule identifies suspicious pod creation or modification events that enable host IPC, excluding known benign images, to flag potential security threats.
 39
 40### Possible investigation steps
 41
 42- Review the Kubernetes audit logs to identify the specific pod creation or modification event that triggered the alert, focusing on the event.dataset field with the value "aws.eks_audit".
 43- Examine the aws.eks.audit.annotations.authorization_k8s_io/decision field to confirm that the action was allowed, and verify the identity of the user or service account that initiated the request.
 44- Investigate the aws.eks.audit.objectRef.resource field to ensure the resource involved is indeed a pod, and check the aws.eks.audit.verb field to determine if the action was a create, update, or patch operation.
 45- Analyze the aws.eks.audit.requestObject.spec.hostIPC field to confirm that host IPC was enabled, and cross-reference with the aws.eks.audit.requestObject.spec.containers.image field to ensure the image is not part of the known benign list.
 46- Check for any other pods or processes on the host that might be using the host's IPC namespace, and assess if there is any unauthorized access or data exposure risk.
 47- Look for any suspicious activity or anomalies in the /dev/shm directory or use the ipcs command to identify any IPC facilities that might be exploited.
 48
 49### False positive analysis
 50
 51- Pods using hostIPC for legitimate inter-process communication may trigger alerts. Review the pod's purpose and verify if hostIPC is necessary for its function.
 52- Known benign images, such as monitoring or logging agents, might use hostIPC. Update the exclusion list to include these images if they are verified as non-threatening.
 53- Development or testing environments often use hostIPC for debugging purposes. Consider excluding these environments from the rule or creating a separate rule with a higher threshold for alerts.
 54- Automated deployment tools might temporarily use hostIPC during setup. Ensure these tools are recognized and excluded if they are part of a controlled and secure process.
 55- Regularly review and update the exclusion list to reflect changes in your environment, ensuring that only verified and necessary uses of hostIPC are excluded.
 56
 57### Response and remediation
 58
 59- Immediately isolate the affected pod to prevent further access to the host's IPC namespace. This can be done by cordoning the node or deleting the pod if necessary.
 60- Review and revoke any unnecessary permissions or roles that allowed the pod to be created or modified with hostIPC enabled. Ensure that only trusted entities have the capability to modify pod specifications.
 61- Conduct a thorough audit of other pods and configurations in the cluster to identify any additional instances where hostIPC is enabled without a valid justification.
 62- Implement network policies to restrict communication between pods and the host, limiting the potential impact of any unauthorized access to the host's IPC mechanisms.
 63- Escalate the incident to the security operations team for further investigation and to determine if any data exposure or privilege escalation occurred.
 64- Update security policies and configurations to prevent the use of hostIPC in future pod deployments unless explicitly required and approved.
 65- Enhance monitoring and alerting to detect similar attempts in the future, ensuring that any unauthorized use of hostIPC is promptly flagged and addressed."""
 66references = [
 67    "https://research.nccgroup.com/2021/11/10/detection-engineering-for-kubernetes-clusters/#part3-kubernetes-detections",
 68    "https://kubernetes.io/docs/concepts/security/pod-security-policy/#host-namespaces",
 69    "https://bishopfox.com/blog/kubernetes-pod-privilege-escalation",
 70]
 71risk_score = 47
 72rule_id = "415483cd-2938-5260-a5e6-be3da8a19d8c"
 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    "Rule Type: Custom Query (KQL)",
 96    "Threat: Container Escape",
 97    "Resources: Investigation Guide",
 98    "Profile: Beta",
 99]
100timestamp_override = "event.ingested"
101type = "query"
102
103query = '''
104data_stream.dataset : "aws.eks_audit" and aws.eks.audit.annotations.authorization_k8s_io/decision:"allow" and
105aws.eks.audit.objectRef.resource:"pods" and aws.eks.audit.verb:("create" or "update" or "patch") and
106aws.eks.audit.requestObject.spec.hostIPC:true and
107not aws.eks.audit.requestObject.spec.containers.image: (
108  docker.elastic.co/beats/elastic-agent* or rancher/system-agent* or registry.crowdstrike.com/falcon-sensor*
109)
110'''
111
112
113[[rule.threat]]
114framework = "MITRE ATT&CK"
115[[rule.threat.technique]]
116id = "T1611"
117name = "Escape to Host"
118reference = "https://attack.mitre.org/techniques/T1611/"
119
120
121[rule.threat.tactic]
122id = "TA0004"
123name = "Privilege Escalation"
124reference = "https://attack.mitre.org/tactics/TA0004/"
125[[rule.threat]]
126framework = "MITRE ATT&CK"
127[[rule.threat.technique]]
128id = "T1610"
129name = "Deploy Container"
130reference = "https://attack.mitre.org/techniques/T1610/"
131
132
133[rule.threat.tactic]
134id = "TA0002"
135name = "Execution"
136reference = "https://attack.mitre.org/tactics/TA0002/"