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

to-top