Kubernetes Pod Created With HostPID

  1[metadata]
  2creation_date = "2022/07/05"
  3integration = ["kubernetes"]
  4maturity = "production"
  5updated_date = "2025/06/18"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10This rule detects an attempt to create or modify a pod attached to the host PID namespace. HostPID allows a pod to
 11access all the processes running on the host and could allow an attacker to take malicious action. When paired with
 12ptrace this can be used to escalate privileges outside of the container. When paired with a privileged container, the
 13pod can see all of the processes on the host. An attacker can enter the init system (PID 1) on the host. From there,
 14they could execute a shell and continue to escalate privileges to root.
 15"""
 16false_positives = [
 17    """
 18    An administrator or developer may want to use a pod that runs as root and shares the hosts IPC, Network, and PID
 19    namespaces for debugging purposes. If something is going wrong in the cluster and there is no easy way to SSH onto
 20    the host nodes directly, a privileged pod of this nature can be useful for viewing things like iptable rules and
 21    network namespaces from the host's perspective. Add exceptions for trusted container images using the query field
 22    "kubernetes.audit.requestObject.spec.container.image"
 23    """,
 24]
 25index = ["logs-kubernetes.audit_logs-*"]
 26language = "kuery"
 27license = "Elastic License v2"
 28name = "Kubernetes Pod Created With HostPID"
 29note = """## Triage and analysis
 30
 31> **Disclaimer**:
 32> 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.
 33
 34### Investigating Kubernetes Pod Created With HostPID
 35
 36Kubernetes allows pods to share the host's process ID (PID) namespace, enabling visibility into host processes. While useful for debugging, this can be exploited by attackers to escalate privileges, especially when combined with privileged containers. The detection rule identifies attempts to create or modify pods with HostPID enabled, excluding known safe images, to flag potential privilege escalation activities.
 37
 38### Possible investigation steps
 39
 40- Review the Kubernetes audit logs to identify the user or service account responsible for the pod creation or modification attempt. Look for the `kubernetes.audit.user.username` field to determine who initiated the action.
 41- Examine the `kubernetes.audit.requestObject.spec.containers.image` field to identify the container images used in the pod. Verify if any unknown or suspicious images are being deployed.
 42- Check the `kubernetes.audit.annotations.authorization_k8s_io/decision` field to confirm that the action was allowed and investigate the context or reason for this decision.
 43- Investigate the `kubernetes.audit.objectRef.resource` and `kubernetes.audit.verb` fields to understand the specific action taken (create, update, or patch) and the resource involved.
 44- Assess the necessity and legitimacy of using HostPID in the pod's configuration by consulting with the relevant development or operations teams. Determine if there is a valid use case or if it was potentially misconfigured or maliciously set.
 45- Review any recent changes in the Kubernetes environment or related configurations that might have led to this alert, focusing on changes around the time the alert was triggered.
 46
 47### False positive analysis
 48
 49- Known safe images like "docker.elastic.co/beats/elastic-agent:8.4.0" are already excluded, but other internal tools or monitoring agents that require HostPID for legitimate reasons might trigger false positives. Review and identify such images and add them to the exclusion list.
 50- Development or testing environments often use HostPID for debugging purposes. Consider creating a separate rule or exception for these environments to prevent unnecessary alerts.
 51- Some system maintenance tasks might require temporary use of HostPID. Document these tasks and schedule them during known maintenance windows, then adjust the rule to exclude these specific time frames.
 52- Regularly review audit logs to identify patterns of benign HostPID usage. Use this information to refine the rule and reduce false positives by updating the exclusion criteria.
 53- Collaborate with development and operations teams to understand legitimate use cases for HostPID in your environment, and adjust the rule to accommodate these scenarios without compromising security.
 54
 55### Response and remediation
 56
 57- Immediately isolate the affected pod to prevent further interaction with the host processes. This can be done by cordoning the node or deleting the pod if necessary.
 58- Review and revoke any unnecessary permissions or roles that may have allowed the creation of pods with HostPID enabled. Ensure that only trusted users and service accounts have the ability to create such pods.
 59- Conduct a thorough investigation of the container images used in the pod to ensure they are from trusted sources and have not been tampered with. Remove any untrusted or suspicious images from the registry.
 60- Check for any unauthorized access or changes to the host system's processes and files. If any malicious activity is detected, take steps to restore affected systems from backups and patch any vulnerabilities.
 61- Implement network segmentation to limit the communication between pods and the host system, reducing the risk of lateral movement by an attacker.
 62- Enhance monitoring and logging to capture detailed audit logs of Kubernetes API activities, focusing on changes to pod specifications and the use of HostPID. This will aid in detecting similar threats in the future.
 63- Escalate the incident to the security operations team for further analysis and to determine if additional security measures or incident response actions are required.
 64
 65## Setup
 66
 67The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
 68references = [
 69    "https://research.nccgroup.com/2021/11/10/detection-engineering-for-kubernetes-clusters/#part3-kubernetes-detections",
 70    "https://kubernetes.io/docs/concepts/security/pod-security-policy/#host-namespaces",
 71    "https://bishopfox.com/blog/kubernetes-pod-privilege-escalation",
 72]
 73risk_score = 47
 74rule_id = "df7fda76-c92b-4943-bc68-04460a5ea5ba"
 75severity = "medium"
 76tags = ["Data Source: Kubernetes", "Tactic: Execution", "Tactic: Privilege Escalation", "Resources: Investigation Guide"]
 77timestamp_override = "event.ingested"
 78type = "query"
 79
 80query = '''
 81event.dataset : "kubernetes.audit_logs"
 82  and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow"
 83  and kubernetes.audit.objectRef.resource:"pods"
 84  and kubernetes.audit.verb:("create" or "update" or "patch")
 85  and kubernetes.audit.requestObject.spec.hostPID:true
 86  and not kubernetes.audit.requestObject.spec.containers.image: ("docker.elastic.co/beats/elastic-agent:8.4.0")
 87'''
 88
 89
 90[[rule.threat]]
 91framework = "MITRE ATT&CK"
 92[[rule.threat.technique]]
 93id = "T1611"
 94name = "Escape to Host"
 95reference = "https://attack.mitre.org/techniques/T1611/"
 96
 97
 98[rule.threat.tactic]
 99id = "TA0004"
100name = "Privilege Escalation"
101reference = "https://attack.mitre.org/tactics/TA0004/"
102[[rule.threat]]
103framework = "MITRE ATT&CK"
104[[rule.threat.technique]]
105id = "T1610"
106name = "Deploy Container"
107reference = "https://attack.mitre.org/techniques/T1610/"
108
109
110[rule.threat.tactic]
111id = "TA0002"
112name = "Execution"
113reference = "https://attack.mitre.org/tactics/TA0002/"