{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/products/kube-dns/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","coredns","kube-dns"],"_cs_severities":["high"],"_cs_tags":["kubernetes","dns","man-in-the-middle","impact"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThe rule detects modifications to the CoreDNS or kube-dns ConfigMap within the kube-system namespace. These ConfigMaps are crucial for managing cluster DNS resolution, affecting all pods within the Kubernetes environment. An attacker compromising this configuration can redirect internal service DNS names to attacker-controlled IP addresses. This manipulation facilitates man-in-the-middle (MitM) attacks targeting sensitive internal endpoints such as the Kubernetes API server and database services. DNS poisoning at the cluster level is particularly impactful as it affects every pod across all namespaces without requiring modifications to individual workloads. CoreDNS configuration changes are typically infrequent, making any unexpected modifications a critical indicator of potential compromise.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains unauthorized access to a Kubernetes cluster, possibly through compromised credentials or a software vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies the CoreDNS or kube-dns ConfigMap within the kube-system namespace as a target for manipulation.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the Corefile content within the ConfigMap to redirect DNS queries for internal services to attacker-controlled IPs. This can be done using \u003ccode\u003ekubectl edit configmap coredns -n kube-system\u003c/code\u003e or similar commands.\u003c/li\u003e\n\u003cli\u003eWhen pods within the cluster attempt to resolve internal service names, the poisoned DNS server returns the attacker\u0026rsquo;s IP address.\u003c/li\u003e\n\u003cli\u003eThe victim pod connects to the attacker-controlled IP, believing it to be the legitimate service endpoint.\u003c/li\u003e\n\u003cli\u003eThe attacker intercepts traffic, potentially capturing sensitive data such as service account tokens, database credentials, and API communications.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages stolen credentials and intercepted API traffic to further compromise the Kubernetes cluster and access sensitive resources.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistence by ensuring the modified CoreDNS configuration remains in place, affecting all new pods that resolve DNS via the cluster DNS.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack can compromise the entire Kubernetes cluster by redirecting traffic intended for critical internal services to malicious endpoints. This allows attackers to steal sensitive data such as service account tokens and database credentials, potentially leading to full control of the cluster. The attack affects all pods in all namespaces, creating a widespread security incident. Successful exploitation can also disrupt services that rely on DNS resolution, leading to denial of service conditions.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImplement the Sigma rule \u003ccode\u003eDetect Kubernetes CoreDNS ConfigMap Modification\u003c/code\u003e to detect unauthorized modifications to the CoreDNS or kube-dns ConfigMap.\u003c/li\u003e\n\u003cli\u003eRestrict RBAC permissions to prevent unauthorized users from modifying DNS ConfigMaps in the kube-system namespace, as mentioned in the rule documentation.\u003c/li\u003e\n\u003cli\u003eRegularly audit ConfigMap changes in the kube-system namespace, as described in the rule\u0026rsquo;s triage and analysis section.\u003c/li\u003e\n\u003cli\u003eMonitor Kubernetes audit logs for suspicious activity related to DNS configuration changes using the provided query in the rule definition.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-14T16:49:15Z","date_published":"2026-05-14T16:49:15Z","id":"https://feed.craftedsignal.io/briefs/2026-05-kubernetes-coredns-config-modified/","summary":"Modification of the CoreDNS or kube-dns ConfigMap in the kube-system namespace can lead to cluster-wide DNS poisoning, enabling man-in-the-middle attacks against internal services and the Kubernetes API server.","title":"Kubernetes CoreDNS or Kube-DNS Configuration Modified","url":"https://feed.craftedsignal.io/briefs/2026-05-kubernetes-coredns-config-modified/"}],"language":"en","title":"CraftedSignal Threat Feed — Kube-Dns","version":"https://jsonfeed.org/version/1.1"}