This Elastic rule detects modifications to the CoreDNS or kube-dns ConfigMaps in the kube-system namespace, which control DNS resolution for all pods in the cluster. Altering the CoreDNS Corefile can enable an attacker to redirect internal service DNS names to attacker-controlled IPs, enabling man-in-the-middle access to the Kubernetes API server, databases, and other internal endpoints. Because DNS poisoning at the cluster level affects all pods, such changes are high-risk and typically rare outside approved maintenance. The rule uses Kubernetes audit logs to catch configuration changes to CoreDNS/kube-dns ConfigMaps and flags updates, patches, or deletions that were allowed by RBAC (authorization_k8s_io/decision: "allow"), while excluding known legitimate service accounts (e.g., CoreDNS, kube-dns SA, node-scoped or cloud-provider service accounts). This helps surface potentially malicious or misconfigured changes that could redirect traffic and steal credentials, tokens, or API traffic across namespaces. Triage and investigation guidance in the rule emphasizes identifying the actor (user.name, groups), the source (source.ip), and which ConfigMap was modified. If available, review the Corefile changes for upstream redirection, wildcard rewrites, or unexpected forward/proxy targets. Investigations should confirm whether the actor is authorized to modify DNS configuration, review diffs for forwarding entries to external/internal IPs, and correlate with follow-on suspicious activity (e.g., secret reads, token minting, RBAC changes). Look for cluster-wide symptoms such as service connectivity issues or TLS errors. Remediation recommendations include reverting the ConfigMap to a known-good version and restarting DNS pods if necessary, tightening RBAC to restrict updates/patches/deletes on kube-system DNS ConfigMaps, and investigating the source identity. The rule maps to MITRE ATT&CK techniques Data Manipulation (T1565), specifically the subtechnique Stored Data Manipulation (T1565.001), under the Impact tactic (TA0040). While false positives can occur from legitimate maintenance windows or automated pipelines, any unexpected changes warrant immediate review.