Hostnetwork - CraftedSignal Threat Feedhttps://feed.craftedsignal.io/tags/hostnetwork/Trending threats, MITRE ATT&CK coverage, and detection metadata. Fed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioTue, 02 Jan 2024 12:00:00 +0000Kubernetes Pod with Host Network Attachment Detectedhttps://feed.craftedsignal.io/briefs/2024-01-02-kubernetes-host-network/Tue, 02 Jan 2024 12:00:00 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2024-01-02-kubernetes-host-network/Detection of Kubernetes pods configured to use the host network namespace via audit logs, potentially allowing attackers to monitor all node network traffic for sensitive data and privilege escalation.This alert identifies the creation or update of a Kubernetes pod configured to use the host network namespace. Kubernetes audit logs are analyzed to detect pods with the hostNetwork: true setting. This configuration allows a pod to share the network stack of the host node, effectively granting it access to all network interfaces and traffic. This presents a significant security risk, especially if the pod is compromised. An attacker can then monitor all network traffic on the node, potentially capturing sensitive information such as credentials or API keys, and potentially escalating privileges to gain control over the node and the entire cluster. This detection is critical for SOC teams to identify and investigate potentially malicious activity within their Kubernetes environments.

Attack Chain

  1. An attacker gains initial access to the Kubernetes cluster, potentially through compromised credentials, a vulnerable application, or a misconfigured service.
  2. The attacker crafts a malicious pod specification that includes the hostNetwork: true setting. This setting is included within the requestObject.metadata.annotations.kubectl.kubernetes.io/last-applied-configuration field.
  3. The attacker attempts to create or update a pod using the crafted specification, submitting the request to the Kubernetes API server.
  4. The Kubernetes API server logs the pod creation or update request in the audit logs, including details about the pod's configuration and the user who initiated the request.
  5. The detection logic identifies the hostNetwork: true setting in the audit logs, triggering the alert.
  6. An attacker leverages access to the host network to sniff network traffic, intercepting sensitive data.
  7. The attacker uses captured credentials or other sensitive information to escalate privileges within the cluster.

Impact

A successful attack leveraging a pod with host network attachment can have severe consequences. An attacker could gain complete control over the compromised node, potentially leading to data breaches, service disruptions, and unauthorized access to sensitive resources. Furthermore, the attacker could use the compromised node as a launchpad for further attacks within the cluster, compromising other pods and services. This can lead to a full cluster compromise with significant damage and data loss.

Recommendation

  • Enable Kubernetes audit logging and configure the audit policy to capture pod creation and update events. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs as described in the documentation https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md.
  • Deploy the Sigma rule Kubernetes Pod with Host Network Attachment to your SIEM to detect the creation or update of pods with the hostNetwork: true setting.
  • Investigate any alerts generated by this rule to determine the legitimacy of the pod creation/update and the user who initiated the request.
  • Monitor the users and source IPs identified in the detection (user, src_ip) for other suspicious activities within the cluster.
]]>highadvisorykuberneteshostnetworkprivilegeescalation