AWS EKS Pod Created With HostNetwork

  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 rules detects an attempt to create or modify a pod attached to the host network. HostNetwork allows a pod to use
 13the node network namespace. Doing so gives the pod access to any service running on localhost of the host. An attacker
 14could use this access to snoop on network activity of other pods on the same node or bypass restrictive network policies
 15applied to its given namespace.
 16"""
 17false_positives = [
 18    """
 19    An administrator or developer may want to use a pod that runs as root and shares the hosts IPC, Network, and PID
 20    namespaces for debugging purposes. If something is going wrong in the cluster and there is no easy way to SSH onto
 21    the host nodes directly, a privileged pod of this nature can be useful for viewing things like iptable rules and
 22    network namespaces from the host's perspective. Add exceptions for trusted container images using the query field
 23    "aws.eks.audit.requestObject.spec.container.image"
 24    """,
 25]
 26from = "now-6m"
 27index = ["logs-aws.eks_audit-*"]
 28language = "kuery"
 29license = "Elastic License v2"
 30name = "AWS EKS Pod Created With HostNetwork"
 31note = """## Triage and analysis
 32
 33> **Disclaimer**:
 34> 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.
 35
 36### Investigating AWS EKS Pod Created With HostNetwork
 37Kubernetes allows pods to connect to the host's network namespace using HostNetwork, granting them direct access to the node's network interfaces. This capability can be exploited by attackers to monitor or intercept network traffic, potentially bypassing network policies. The detection rule identifies suspicious pod creation or modification events with HostNetwork enabled, excluding known benign images, to flag potential privilege escalation attempts.
 38
 39### Possible investigation steps
 40
 41- Review the Kubernetes audit logs to identify the source of the pod creation or modification event, focusing on the user or service account associated with the action.
 42- Examine the pod's configuration details, especially the containers' images, to determine if any unauthorized or suspicious images are being used, excluding known benign images like "docker.elastic.co/beats/elastic-agent:8.4.0".
 43- Investigate the network activity of the node where the pod is running to identify any unusual traffic patterns or potential data exfiltration attempts.
 44- Check the Kubernetes RBAC (Role-Based Access Control) settings to ensure that the user or service account has appropriate permissions and is not overly privileged.
 45- Assess the necessity of using HostNetwork for the pod in question and determine if it can be reconfigured to operate without this setting to reduce potential security risks.
 46
 47### False positive analysis
 48
 49- Pods used for monitoring or logging may require HostNetwork access to gather network data across nodes. Users can exclude these by adding their specific container images to the exception list in the detection rule.
 50- Certain system-level services or infrastructure components might need HostNetwork for legitimate reasons, such as network plugins or ingress controllers. Identify these services and update the rule to exclude their specific images or namespaces.
 51- Development or testing environments might frequently create pods with HostNetwork for debugging purposes. Consider creating a separate rule or environment-specific exceptions to avoid alert fatigue in these scenarios.
 52- Pods that are part of a known and trusted deployment process, which require HostNetwork for valid operational reasons, should be documented and excluded from the rule to prevent unnecessary alerts.
 53
 54### Response and remediation
 55
 56- Immediately isolate the affected pod by cordoning the node to prevent new pods from being scheduled and draining existing pods to other nodes, except the suspicious one.
 57- Terminate the suspicious pod to stop any potential malicious activity and prevent further network access.
 58- Review and revoke any unnecessary permissions or roles associated with the service account used by the pod to limit privilege escalation opportunities.
 59- Conduct a thorough audit of network policies to ensure they are correctly configured to prevent unauthorized access to the host network.
 60- Escalate the incident to the security operations team for further investigation and to determine if any data was accessed or exfiltrated.
 61- Implement additional monitoring and alerting for any future pod creations with HostNetwork enabled to quickly detect similar threats.
 62- Review and update Kubernetes RBAC policies to enforce the principle of least privilege, ensuring only trusted entities can create pods with HostNetwork enabled."""
 63references = [
 64    "https://research.nccgroup.com/2021/11/10/detection-engineering-for-kubernetes-clusters/#part3-kubernetes-detections",
 65    "https://kubernetes.io/docs/concepts/security/pod-security-policy/#host-namespaces",
 66    "https://bishopfox.com/blog/kubernetes-pod-privilege-escalation",
 67]
 68risk_score = 47
 69rule_id = "28913636-ff63-5d1c-812f-4730a9ff8118"
 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 or patch or update) and
103aws.eks.audit.requestObject.spec.hostNetwork:true and
104not (
105  aws.eks.audit.requestObject.spec.containers.image:(
106    *eks/observability/aws-for-fluent-bit* or *eks/observability/cloudwatch-agent* or *elastic-agent* or *quay/tigera* or *tigera/operator* or
107    docker.io/bitnami/node-exporter* or docker.io/rancher/mirrored-calico-operator* or quay.io/calico/node* or quay.io/cephcsi/cephcsi* or
108    quay.io/frrouting/frr* or quay.io/metallb/speaker* or quay.io/prometheus/node-exporter* or rancher/system-agent* or
109    registry.crowdstrike.com/falcon-sensor* or registry.k8s.io/sig-storage/csi-node-driver-registrar*
110  ) or
111  aws.eks.audit.objectRef.namespace:(
112    calico or calico-system or cilium or elastic or ingress-nginx or kube-system or noname-security-posture or openebs or sysdig-agent
113  )
114)
115'''
116
117
118[[rule.threat]]
119framework = "MITRE ATT&CK"
120[[rule.threat.technique]]
121id = "T1611"
122name = "Escape to Host"
123reference = "https://attack.mitre.org/techniques/T1611/"
124
125
126[rule.threat.tactic]
127id = "TA0004"
128name = "Privilege Escalation"
129reference = "https://attack.mitre.org/tactics/TA0004/"
130[[rule.threat]]
131framework = "MITRE ATT&CK"
132[[rule.threat.technique]]
133id = "T1610"
134name = "Deploy Container"
135reference = "https://attack.mitre.org/techniques/T1610/"
136
137
138[rule.threat.tactic]
139id = "TA0002"
140name = "Execution"
141reference = "https://attack.mitre.org/tactics/TA0002/"