Azure AKS CoreDNS or Kube-DNS Configuration Modified

  1[metadata]
  2creation_date = "2026/07/09"
  3integration = ["azure"]
  4maturity = "production"
  5updated_date = "2026/07/09"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects an identity creating or modifying the CoreDNS or kube-dns ConfigMap in the kube-system namespace on AKS (Azure
 11Kubernetes Service), excluding known AKS control-plane and platform identities. Rewriting cluster DNS (by editing
 12coredns/kube-dns or creating and editing coredns-custom) enables cluster-wide adversary-in-the-middle by redirecting
 13internal service resolution to attacker-controlled IPs, allowing credential capture and traffic interception. Coverage
 14includes workload service accounts (system:serviceaccount:*), so a compromised in-cluster token is not excluded.
 15"""
 16false_positives = [
 17    """
 18    Approved automation, platform controllers, or GitOps may update the CoreDNS ConfigMap (for example custom forward
 19    rules). Validate the identity and change window, and add exclusions for verified service accounts.
 20    """,
 21]
 22from = "now-9m"
 23index = ["logs-azure.platformlogs-*"]
 24language = "kuery"
 25license = "Elastic License v2"
 26name = "Azure AKS CoreDNS or Kube-DNS Configuration Modified"
 27note = """## Triage and analysis
 28
 29### Investigating Azure AKS CoreDNS or Kube-DNS Configuration Modified
 30
 31AKS kube-audit events are carried under the flattened `azure.platformlogs.properties.log.*` subtree and share the ARM
 32operation `event.action: Microsoft.ContainerService/managedClusters/diagnosticLogs/Read`. CoreDNS resolves in-cluster
 33service names; an attacker who edits `coredns`/`kube-dns` or creates/edits the user-managed `coredns-custom` ConfigMap
 34can inject forward or rewrite rules that redirect service resolution to attacker-controlled endpoints, enabling
 35cluster-wide interception of credentials and traffic. `coredns-custom` is the supported customization surface, so
 36legitimate DNS tuning also lands here; the acting identity is excluded when it is an AKS platform reconciler
 37(`aksService`), leaving non-platform changes as the signal.
 38
 39### Possible investigation steps
 40
 41- Review the submitted ConfigMap body in `azure.platformlogs.properties.log.requestObject.data` for added forward,
 42  rewrite, or hosts entries pointing at unexpected IPs or domains. This content, not the act of editing, is what
 43  distinguishes malicious DNS redirection from routine customization.
 44- Identify the acting identity in `azure.platformlogs.properties.log.user.username` (and its groups in
 45  `azure.platformlogs.properties.log.user.groups`) and confirm it should manage the CoreDNS configuration; a workload
 46  service account (`system:serviceaccount:<ns>:<sa>`) editing cluster DNS is the higher-concern case.
 47- Confirm the operation and object via `azure.platformlogs.properties.log.verb` (a `create` of `coredns-custom` where it
 48  did not previously exist is notable) and `azure.platformlogs.properties.log.objectRef.name` (`coredns`,
 49  `coredns-custom`, or `kube-dns`), and inspect `azure.platformlogs.properties.log.userAgent`.
 50- Evaluate the source in `azure.platformlogs.properties.log.sourceIPs` and pivot on it for related RBAC changes, secret
 51  reads, or exec sessions.
 52
 53### False positive analysis
 54
 55- `coredns-custom` is the AKS-supported way to add custom forward/stub rules, so approved automation, GitOps, or
 56  administrators editing it are expected. The AKS reconciler (`aksService`) that continuously (re)creates
 57  `coredns-custom` is excluded by identity. Validate the change content and window, then exclude the specific verified
 58  service account rather than re-broadening to all `system:*`.
 59
 60### Response and remediation
 61
 62- If unauthorized, restore the CoreDNS ConfigMap from a known-good source, revoke the acting identity's tokens, and
 63  review the RBAC that permitted the change.
 64- Hunt for credential capture or redirected traffic during the window the malicious configuration was active.
 65- Collect kube-audit and identity artifacts per incident response procedures.
 66"""
 67references = [
 68    "https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/",
 69    "https://microsoft.github.io/Threat-Matrix-for-Kubernetes/",
 70    "https://microsoft.github.io/Threat-Matrix-for-Kubernetes/techniques/CoreDNS%20poisoning/",
 71    "https://learn.microsoft.com/en-us/azure/aks/coredns-custom",
 72    "https://www.aquasec.com/blog/dns-spoofing-kubernetes-clusters/",
 73    "https://hub.armosec.io/docs/c-0037",
 74]
 75risk_score = 47
 76rule_id = "1291513f-02f2-48d6-9f9c-06e5c8f23ecb"
 77setup = """
 78The Azure Fleet integration collecting AKS diagnostic logs forwarded through Event Hub into the `azure.platformlogs`
 79data stream is required for this rule. Enable either the `kube-audit` or the `kube-audit-admin` log category (Microsoft
 80recommends `kube-audit-admin` alone to reduce volume, as it only drops read-only get/list events). ConfigMap writes are
 81mutating operations recorded in both categories with the same `auditID`, so clusters that enable both categories may
 82generate two alerts per change.
 83"""
 84severity = "medium"
 85tags = [
 86    "Domain: Cloud",
 87    "Domain: Kubernetes",
 88    "Data Source: Azure",
 89    "Data Source: Azure Platform Logs",
 90    "Data Source: Kubernetes",
 91    "Use Case: Threat Detection",
 92    "Tactic: Credential Access",
 93    "Resources: Investigation Guide",
 94]
 95timestamp_override = "event.ingested"
 96type = "query"
 97
 98query = '''
 99data_stream.dataset:azure.platformlogs and
100  event.action:"Microsoft.ContainerService/managedClusters/diagnosticLogs/Read" and
101  azure.platformlogs.category:("kube-audit" or "kube-audit-admin") and
102  azure.platformlogs.properties.log.stage:"ResponseComplete" and
103  azure.platformlogs.properties.log.objectRef.resource:"configmaps" and
104  azure.platformlogs.properties.log.objectRef.namespace:"kube-system" and
105  azure.platformlogs.properties.log.objectRef.name:("coredns" or "kube-dns" or "coredns-custom") and
106  azure.platformlogs.properties.log.verb:("create" or "update" or "patch" or "delete") and
107  not azure.platformlogs.properties.log.user.username:(
108    system\:node\:* or "aksService" or "hcpService" or "readinessChecker" or
109    system\:serviceaccount\:kube-system\:*
110  )
111'''
112
113[rule.investigation_fields]
114field_names = [
115    "@timestamp",
116    "event.action",
117    "azure.platformlogs.category",
118    "azure.platformlogs.properties.log.verb",
119    "azure.platformlogs.properties.log.user.username",
120    "azure.platformlogs.properties.log.user.groups",
121    "azure.platformlogs.properties.log.userAgent",
122    "azure.platformlogs.properties.log.sourceIPs",
123    "azure.platformlogs.properties.log.objectRef.namespace",
124    "azure.platformlogs.properties.log.objectRef.name",
125    "azure.platformlogs.properties.log.responseStatus.code",
126]
127
128[[rule.threat]]
129framework = "MITRE ATT&CK"
130
131[[rule.threat.technique]]
132id = "T1557"
133name = "Adversary-in-the-Middle"
134reference = "https://attack.mitre.org/techniques/T1557/"
135
136[rule.threat.tactic]
137id = "TA0006"
138name = "Credential Access"
139reference = "https://attack.mitre.org/tactics/TA0006/"