Namespace - CraftedSignal Threat Feedhttps://feed.craftedsignal.io/tags/namespace/Trending threats, MITRE ATT&CK coverage, and detection metadata. Fed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioWed, 03 Jan 2024 12:00:00 +0000Kubernetes Pod Created in Default Namespacehttps://feed.craftedsignal.io/briefs/2024-01-03-kubernetes-pod-creation-default-namespace/Wed, 03 Jan 2024 12:00:00 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2024-01-03-kubernetes-pod-creation-default-namespace/Detection of Kubernetes pod creation in default, kube-system, or kube-public namespaces using audit logs, potentially indicating attacker attempts to hide or evade defenses following a cluster breach.This threat brief focuses on the detection of Kubernetes pods being created in the default, kube-system, or kube-public namespaces. This activity is considered anomalous because these namespaces are typically reserved for system functions and explicitly defined applications. The detection leverages Kubernetes audit logs to identify pod creation events within these namespaces. The Splunk ES/CU analytic Kubernetes Pod Created in Default Namespace released on 2026-04-15 flags this specific behavior. An attacker creating pods in these locations might be attempting to hide their presence, escalate privileges, establish persistent access, or execute further malicious activities within the Kubernetes cluster. This is particularly concerning as it may indicate a successful initial breach.

Attack Chain

  1. An attacker gains initial access to a Kubernetes cluster, possibly through exploiting a vulnerability in a container image or a misconfigured service.
  2. The attacker attempts to create a new pod within the default, kube-system, or kube-public namespace using kubectl or the Kubernetes API.
  3. The Kubernetes API server receives the pod creation request.
  4. Kubernetes audit logging records the pod creation event, including the user, timestamp, source IP, and the specifications of the pod.
  5. The pod is successfully created and deployed within the targeted namespace.
  6. The attacker leverages the newly created pod to execute malicious commands, potentially escalating privileges or gaining access to sensitive data.
  7. The attacker uses the compromised pod to move laterally within the cluster, targeting other resources and services.
  8. The final objective may include data exfiltration, deployment of persistent backdoors, or disruption of services within the Kubernetes environment.

Impact

Successful exploitation can lead to a full compromise of the Kubernetes cluster. Attackers could gain complete control over the cluster's resources and data. Depending on the cluster's role, this could result in data breaches, service disruptions, and significant financial losses. The compromise can also lead to persistent backdoors, enabling attackers to maintain long-term access to the environment. This analytic will help detect activity, but will not mitigate the initial compromise.

Recommendation

  • Enable Kubernetes audit logging and configure the audit policy to capture pod creation events to ensure the Kubernetes Audit data source is available.
  • Deploy the Sigma rule provided below to detect pod creation in restricted namespaces and tune the rule for your environment.
  • Investigate any alerts generated by the Sigma rule, focusing on the user, source IP, and the details of the created pod.
  • Review and harden RBAC policies to restrict pod creation in sensitive namespaces.
  • Monitor network connections originating from pods created in these namespaces for suspicious outbound traffic.
]]>highadvisorykubernetespodnamespaceprivilege_escalation