Kubernetes Pod Created With HostNetwork

This rules detects an attempt to create or modify a pod attached to the host network. HostNetwork allows a pod to use the node network namespace. Doing so gives the pod access to any service running on localhost of the host. An attacker could use this access to snoop on network activity of other pods on the same node or bypass restrictive network policies applied to its given namespace.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2022/07/05"
  3integration = ["kubernetes"]
  4maturity = "production"
  5updated_date = "2025/01/15"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10This rules detects an attempt to create or modify a pod attached to the host network. HostNetwork allows a pod to use
 11the node network namespace. Doing so gives the pod access to any service running on localhost of the host. An attacker
 12could use this access to snoop on network activity of other pods on the same node or bypass restrictive network policies
 13applied to its given namespace.
 14"""
 15false_positives = [
 16    """
 17    An administrator or developer may want to use a pod that runs as root and shares the hosts IPC, Network, and PID
 18    namespaces for debugging purposes. If something is going wrong in the cluster and there is no easy way to SSH onto
 19    the host nodes directly, a privileged pod of this nature can be useful for viewing things like iptable rules and
 20    network namespaces from the host's perspective. Add exceptions for trusted container images using the query field
 21    "kubernetes.audit.requestObject.spec.container.image"
 22    """,
 23]
 24index = ["logs-kubernetes.*"]
 25language = "kuery"
 26license = "Elastic License v2"
 27name = "Kubernetes Pod Created With HostNetwork"
 28note = """## Triage and analysis
 29
 30> **Disclaimer**:
 31> 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.
 32
 33### Investigating Kubernetes Pod Created With HostNetwork
 34
 35Kubernetes 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.
 36
 37### Possible investigation steps
 38
 39- 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.
 40- 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".
 41- Investigate the network activity of the node where the pod is running to identify any unusual traffic patterns or potential data exfiltration attempts.
 42- 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.
 43- 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.
 44
 45### False positive analysis
 46
 47- 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.
 48- 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.
 49- 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.
 50- 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.
 51
 52### Response and remediation
 53
 54- 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.
 55- Terminate the suspicious pod to stop any potential malicious activity and prevent further network access.
 56- Review and revoke any unnecessary permissions or roles associated with the service account used by the pod to limit privilege escalation opportunities.
 57- Conduct a thorough audit of network policies to ensure they are correctly configured to prevent unauthorized access to the host network.
 58- Escalate the incident to the security operations team for further investigation and to determine if any data was accessed or exfiltrated.
 59- Implement additional monitoring and alerting for any future pod creations with HostNetwork enabled to quickly detect similar threats.
 60- Review and update Kubernetes RBAC policies to enforce the principle of least privilege, ensuring only trusted entities can create pods with HostNetwork enabled.
 61
 62## Setup
 63
 64The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
 65references = [
 66    "https://research.nccgroup.com/2021/11/10/detection-engineering-for-kubernetes-clusters/#part3-kubernetes-detections",
 67    "https://kubernetes.io/docs/concepts/security/pod-security-policy/#host-namespaces",
 68    "https://bishopfox.com/blog/kubernetes-pod-privilege-escalation",
 69]
 70risk_score = 47
 71rule_id = "12cbf709-69e8-4055-94f9-24314385c27e"
 72severity = "medium"
 73tags = ["Data Source: Kubernetes", "Tactic: Execution", "Tactic: Privilege Escalation", "Resources: Investigation Guide"]
 74timestamp_override = "event.ingested"
 75type = "query"
 76
 77query = '''
 78event.dataset : "kubernetes.audit_logs"
 79  and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow"
 80  and kubernetes.audit.objectRef.resource:"pods"
 81  and kubernetes.audit.verb:("create" or "update" or "patch")
 82  and kubernetes.audit.requestObject.spec.hostNetwork:true
 83  and not kubernetes.audit.requestObject.spec.containers.image: ("docker.elastic.co/beats/elastic-agent:8.4.0")
 84'''
 85
 86
 87[[rule.threat]]
 88framework = "MITRE ATT&CK"
 89[[rule.threat.technique]]
 90id = "T1611"
 91name = "Escape to Host"
 92reference = "https://attack.mitre.org/techniques/T1611/"
 93
 94
 95[rule.threat.tactic]
 96id = "TA0004"
 97name = "Privilege Escalation"
 98reference = "https://attack.mitre.org/tactics/TA0004/"
 99[[rule.threat]]
100framework = "MITRE ATT&CK"
101[[rule.threat.technique]]
102id = "T1610"
103name = "Deploy Container"
104reference = "https://attack.mitre.org/techniques/T1610/"
105
106
107[rule.threat.tactic]
108id = "TA0002"
109name = "Execution"
110reference = "https://attack.mitre.org/tactics/TA0002/"

Triage and analysis

Disclaimer: 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.

Investigating Kubernetes Pod Created With HostNetwork

Kubernetes 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.

Possible investigation steps

  • 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.
  • 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".
  • Investigate the network activity of the node where the pod is running to identify any unusual traffic patterns or potential data exfiltration attempts.
  • 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.
  • 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.

False positive analysis

  • 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.
  • 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.
  • 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.
  • 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.

Response and remediation

  • 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.
  • Terminate the suspicious pod to stop any potential malicious activity and prevent further network access.
  • Review and revoke any unnecessary permissions or roles associated with the service account used by the pod to limit privilege escalation opportunities.
  • Conduct a thorough audit of network policies to ensure they are correctly configured to prevent unauthorized access to the host network.
  • Escalate the incident to the security operations team for further investigation and to determine if any data was accessed or exfiltrated.
  • Implement additional monitoring and alerting for any future pod creations with HostNetwork enabled to quickly detect similar threats.
  • Review and update Kubernetes RBAC policies to enforce the principle of least privilege, ensuring only trusted entities can create pods with HostNetwork enabled.

Setup

The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.

References

Related rules

to-top