GKE CoreDNS or Kube-DNS Configuration Modified
Detects modifications to the CoreDNS or kube-dns ConfigMap in the kube-system namespace on GKE. 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/07/06"
3integration = ["gcp"]
4maturity = "production"
5updated_date = "2026/07/06"
6
7[rule]
8author = ["Elastic"]
9description = """
10Detects modifications to the CoreDNS or kube-dns ConfigMap in the kube-system namespace on GKE. These ConfigMaps control
11cluster DNS resolution for all pods. An attacker who modifies the CoreDNS Corefile can redirect internal service DNS
12names 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 pod
16in every namespace simultaneously and does not require any modification to the victim workloads. CoreDNS configuration
17changes 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-6m"
26index = ["logs-gcp.audit-*"]
27language = "kuery"
28license = "Elastic License v2"
29name = "GKE CoreDNS or Kube-DNS Configuration Modified"
30note = """## Triage and analysis
31
32### Investigating GKE CoreDNS or Kube-DNS Configuration Modified
33
34Identify who performed the change (user.email, 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
50## Setup
51
52The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule."""
53references = [
54 "https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/",
55 "https://coredns.io/plugins/rewrite/",
56]
57risk_score = 73
58rule_id = "80528e81-949f-4d38-b0c7-aef4b160212e"
59severity = "high"
60tags = [
61 "Domain: Cloud",
62 "Domain: Kubernetes",
63 "Data Source: GCP",
64 "Data Source: Google Cloud Platform",
65 "Use Case: Threat Detection",
66 "Tactic: Impact",
67 "Resources: Investigation Guide",
68]
69timestamp_override = "event.ingested"
70type = "query"
71
72query = '''
73data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and
74event.action:("io.k8s.core.v1.configmaps.update" or "io.k8s.core.v1.configmaps.patch" or "io.k8s.core.v1.configmaps.delete") and
75orchestrator.resource.name:("coredns" or "kube-dns" or "coredns-custom") and orchestrator.namespace:"kube-system" and
76gcp.audit.labels.authorization.k8s.io/decision:"allow" and
77not user.email:(
78 "system:serviceaccount:kube-system:coredns" or
79 "system:serviceaccount:kube-system:kube-dns" or
80 system\:node* or system\:serviceaccount\:kube-system*
81)
82'''
83
84
85[[rule.threat]]
86framework = "MITRE ATT&CK"
87[[rule.threat.technique]]
88id = "T1565"
89name = "Data Manipulation"
90reference = "https://attack.mitre.org/techniques/T1565/"
91[[rule.threat.technique.subtechnique]]
92id = "T1565.001"
93name = "Stored Data Manipulation"
94reference = "https://attack.mitre.org/techniques/T1565/001/"
95
96
97
98[rule.threat.tactic]
99id = "TA0040"
100name = "Impact"
101reference = "https://attack.mitre.org/tactics/TA0040/"
Triage and analysis
Investigating GKE CoreDNS or Kube-DNS Configuration Modified
Identify who performed the change (user.email, 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.
Setup
The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule.
References
Related rules
- GKE Rapid Secret GET Activity Against Multiple Objects
- GKE API Request Failure Burst by User
- GKE Admission Webhook Created or Modified
- GKE Container Created with Excessive Linux Capabilities
- GKE Pod Created With HostIPC