Kubernetes CoreDNS or Kube-DNS Configuration Modified
Detects modifications to the CoreDNS or kube-dns ConfigMap in the kube-system namespace. These ConfigMaps control cluster DNS resolution for all pods. An attacker who modifies the CoreDNS Corefile can redirect internal service DNS names to attacker-controlled IP addresses, enabling man-in-the-middle attacks against the Kubernetes API server, database services, and other internal endpoints. Pods that resolve service names via cluster DNS will transparently connect to the attacker instead of the legitimate service, allowing interception of service account tokens, database credentials, and API traffic. DNS poisoning at the cluster level is particularly dangerous because it affects every pod in every namespace simultaneously and does not require any modification to the victim workloads. CoreDNS configuration changes are rare in normal operations and any unexpected modification should be investigated immediately.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2026/05/07"
3integration = ["kubernetes"]
4maturity = "production"
5updated_date = "2026/05/07"
6
7[rule]
8author = ["Elastic"]
9description = """
10Detects modifications to the CoreDNS or kube-dns ConfigMap in the kube-system namespace. These ConfigMaps control
11cluster DNS resolution for all pods. An attacker who modifies the CoreDNS Corefile can redirect internal service
12DNS names to attacker-controlled IP addresses, enabling man-in-the-middle attacks against the Kubernetes API server,
13database services, and other internal endpoints. Pods that resolve service names via cluster DNS will transparently
14connect to the attacker instead of the legitimate service, allowing interception of service account tokens, database
15credentials, and API traffic. DNS poisoning at the cluster level is particularly dangerous because it affects every
16pod in every namespace simultaneously and does not require any modification to the victim workloads. CoreDNS
17configuration changes are rare in normal operations and any unexpected modification should be investigated immediately.
18"""
19false_positives = [
20 """
21 Cluster administrators may legitimately update CoreDNS configuration for forwarding, stub domains, or cluster DNS
22 troubleshooting. Baseline approved operators and automation identities; tune exclusions for known change pipelines.
23 """,
24]
25from = "now-9m"
26index = ["logs-kubernetes.audit_logs-*"]
27language = "kuery"
28license = "Elastic License v2"
29name = "Kubernetes CoreDNS or Kube-DNS Configuration Modified"
30note = """## Triage and analysis
31
32### Investigating Kubernetes CoreDNS or Kube-DNS Configuration Modified
33
34Identify who performed the change (user.name, groups), from where (source.ip), and which ConfigMap was modified.
35If request/response capture is available, review the changed Corefile content for upstream redirection, wildcard
36rewrites, or unexpected forward/proxy targets.
37
38### Possible investigation steps
39
40- Confirm the actor is authorized to modify kube-system DNS configuration and whether the change aligns with a change window.
41- Review the ConfigMap diff for added rewrite rules, hosts entries, or forwarding to external or unexpected internal IPs.
42- Correlate with follow-on suspicious activity such as secret reads, token minting, or RBAC modifications.
43- Check for cluster-wide symptoms: service connection failures, TLS errors, or sudden endpoint changes across namespaces.
44
45### Response and remediation
46
47- Revert the ConfigMap to a known-good version and restart DNS pods if required by your deployment.
48- Restrict RBAC permissions that allow update/patch/delete on kube-system DNS ConfigMaps and investigate the source identity.
49"""
50references = [
51 "https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/",
52 "https://coredns.io/plugins/rewrite/",
53 "https://attack.mitre.org/techniques/T1565/001/",
54]
55risk_score = 73
56rule_id = "a643e6b8-ba2a-45f1-8d71-d265bfe2ae43"
57severity = "high"
58tags = [
59 "Data Source: Kubernetes",
60 "Domain: Kubernetes",
61 "Use Case: Threat Detection",
62 "Tactic: Impact",
63 "Resources: Investigation Guide",
64]
65timestamp_override = "event.ingested"
66type = "query"
67query = '''
68data_stream.dataset:"kubernetes.audit_logs" and
69kubernetes.audit.objectRef.resource:"configmaps" and
70kubernetes.audit.objectRef.name:("coredns" or "kube-dns" or "coredns-custom") and
71kubernetes.audit.objectRef.namespace:"kube-system" and
72kubernetes.audit.verb:("update" or "patch" or "delete") and
73kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and
74not user.name:(
75 system\:serviceaccount\:kube-system\:coredns or
76 system\:serviceaccount\:kube-system\:kube-dns or
77 system\:node\:* or
78 eks\:* or aksService or acsService
79)
80'''
81
82[[rule.threat]]
83framework = "MITRE ATT&CK"
84
85[[rule.threat.technique]]
86id = "T1565"
87name = "Data Manipulation"
88reference = "https://attack.mitre.org/techniques/T1565/"
89
90[[rule.threat.technique.subtechnique]]
91id = "T1565.001"
92name = "Stored Data Manipulation"
93reference = "https://attack.mitre.org/techniques/T1565/001/"
94
95[rule.threat.tactic]
96id = "TA0040"
97name = "Impact"
98reference = "https://attack.mitre.org/tactics/TA0040/"
Triage and analysis
Investigating Kubernetes CoreDNS or Kube-DNS Configuration Modified
Identify who performed the change (user.name, groups), from where (source.ip), and which ConfigMap was modified. If request/response capture is available, review the changed Corefile content for upstream redirection, wildcard rewrites, or unexpected forward/proxy targets.
Possible investigation steps
- Confirm the actor is authorized to modify kube-system DNS configuration and whether the change aligns with a change window.
- Review the ConfigMap diff for added rewrite rules, hosts entries, or forwarding to external or unexpected internal IPs.
- Correlate with follow-on suspicious activity such as secret reads, token minting, or RBAC modifications.
- Check for cluster-wide symptoms: service connection failures, TLS errors, or sudden endpoint changes across namespaces.
Response and remediation
- Revert the ConfigMap to a known-good version and restart DNS pods if required by your deployment.
- Restrict RBAC permissions that allow update/patch/delete on kube-system DNS ConfigMaps and investigate the source identity.
References
Related rules
- Kubernetes Ephemeral Container Added to Pod
- EKS Authentication Configuration Modified
- Kubernetes API Server Proxying Request to Kubelet
- Kubernetes Client Certificate Signing Request Created or Approved
- Kubernetes Service Account Token Created via TokenRequest API