{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/tags/hostnetwork/feed.json","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Kubernetes"],"_cs_severities":["high"],"_cs_tags":["kubernetes","hostnetwork","privilegeescalation"],"_cs_type":"advisory","_cs_vendors":["Kubernetes"],"content_html":"\u003cp\u003eThis 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 \u003ccode\u003ehostNetwork: true\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to the Kubernetes cluster, potentially through compromised credentials, a vulnerable application, or a misconfigured service.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious pod specification that includes the \u003ccode\u003ehostNetwork: true\u003c/code\u003e setting. This setting is included within the \u003ccode\u003erequestObject.metadata.annotations.kubectl.kubernetes.io/last-applied-configuration\u003c/code\u003e field.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to create or update a pod using the crafted specification, submitting the request to the Kubernetes API server.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003cli\u003eThe detection logic identifies the \u003ccode\u003ehostNetwork: true\u003c/code\u003e setting in the audit logs, triggering the alert.\u003c/li\u003e\n\u003cli\u003eAn attacker leverages access to the host network to sniff network traffic, intercepting sensitive data.\u003c/li\u003e\n\u003cli\u003eThe attacker uses captured credentials or other sensitive information to escalate privileges within the cluster.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable 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 \u003ca href=\"https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md\"\u003ehttps://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eKubernetes Pod with Host Network Attachment\u003c/code\u003e to your SIEM to detect the creation or update of pods with the \u003ccode\u003ehostNetwork: true\u003c/code\u003e setting.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by this rule to determine the legitimacy of the pod creation/update and the user who initiated the request.\u003c/li\u003e\n\u003cli\u003eMonitor the users and source IPs identified in the detection (\u003ccode\u003euser\u003c/code\u003e, \u003ccode\u003esrc_ip\u003c/code\u003e) for other suspicious activities within the cluster.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-02-kubernetes-host-network/","summary":"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.","title":"Kubernetes Pod with Host Network Attachment Detected","url":"https://feed.craftedsignal.io/briefs/2024-01-02-kubernetes-host-network/"}],"language":"en","title":"CraftedSignal Threat Feed - Hostnetwork","version":"https://jsonfeed.org/version/1.1"}