« Kubernetes Container Created with Excessive Linux Capabilities Kubernetes Creation of a RoleBinding Referencing a ServiceAccount »
Elastic Docs ›Elastic Security [8.19] ›Detections and alerts ›Prebuilt rule reference

Kubernetes CoreDNS or Kube-DNS Configuration Modified

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Kubernetes CoreDNS or Kube-DNS Configuration Modified

edit

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.

Rule type: query

Rule indices:

  • logs-kubernetes.audit_logs-*

Severity: high

Risk score: 73

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Data Source: Kubernetes
  • Domain: Kubernetes
  • Use Case: Threat Detection
  • Tactic: Impact
  • Resources: Investigation Guide

Version: 1

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

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.

Rule query

edit
data_stream.dataset:"kubernetes.audit_logs" and
kubernetes.audit.objectRef.resource:"configmaps" and
kubernetes.audit.objectRef.name:("coredns" or "kube-dns" or "coredns-custom") and
kubernetes.audit.objectRef.namespace:"kube-system" and
kubernetes.audit.verb:("update" or "patch" or "delete") and
kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and
not user.name:(
  system\:serviceaccount\:kube-system\:coredns or
  system\:serviceaccount\:kube-system\:kube-dns or
  system\:node\:* or
  eks\:* or aksService or acsService
)

Framework: MITRE ATT&CKTM

« Kubernetes Container Created with Excessive Linux Capabilities Kubernetes Creation of a RoleBinding Referencing a ServiceAccount »