This rule detects modifications to the CoreDNS or kube-dns ConfigMap in the kube-system namespace within GKE by analyzing Google Cloud Platform (GCP) audit logs (index: logs-gcp.audit-*). It triggers on updates, patches, or deletions of ConfigMaps with names such as coredns, kube-dns, or coredns-custom, where the Kubernetes orchestrator indicates a change to configmaps in the kube-system namespace and the GCP audit authorization decision is 'allow'. The intent is to identify DNS configuration changes that could redirect internal service DNS to attacker-controlled IPs, enabling man-in-the-middle activity against the Kubernetes API server, databases, and other internal endpoints. Since cluster DNS affects all pods across namespaces, DNS poisoning at the cluster level can occur without modifying workload assets. CoreDNS configuration changes are uncommon in normal operations, so unexpected modifications should prompt investigation. The rule maps to MITRE ATT&CK techniques in the Impact tactic, including Data Manipulation (Stored Data Manipulation as a subtechnique), reflecting the potential to alter critical DNS routing information. The detection relies on the GCP audit trail, and the accompanying investigation guidance emphasizes identifying who performed the change, the source, and which ConfigMap was modified, plus examining Corefile differences for redirection or anomalous forward/proxy targets. Correlation with follow-on suspicious activity (secret reads, token minting, RBAC changes) and cluster-wide symptoms (service connectivity issues, TLS errors, sudden endpoint changes) is recommended. Setup requires enabling the GCP Fleet integration with GKE audit logs. While the rule aims to be precise, legitimate administrative changes to DNS configuration may occur; maintain exclusions for known change pipelines and approved operators. The rule is designed to prompt rapid containment and remediation when unexpected CoreDNS/Kube-DNS changes are detected.