Azure AKS CoreDNS or Kube-DNS Configuration Modified

[metadata]
creation_date = "2026/07/09"
integration = ["azure"]
maturity = "production"
updated_date = "2026/07/09"

[rule]
author = ["Elastic"]
description = """
Detects an identity creating or modifying the CoreDNS or kube-dns ConfigMap in the kube-system namespace on AKS (Azure
Kubernetes Service), excluding known AKS control-plane and platform identities. Rewriting cluster DNS (by editing
coredns/kube-dns or creating and editing coredns-custom) enables cluster-wide adversary-in-the-middle by redirecting
internal service resolution to attacker-controlled IPs, allowing credential capture and traffic interception. Coverage
includes workload service accounts (system:serviceaccount:*), so a compromised in-cluster token is not excluded.
"""
false_positives = [
    """
    Approved automation, platform controllers, or GitOps may update the CoreDNS ConfigMap (for example custom forward
    rules). Validate the identity and change window, and add exclusions for verified service accounts.
    """,
]
from = "now-9m"
index = ["logs-azure.platformlogs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Azure AKS CoreDNS or Kube-DNS Configuration Modified"
note = """## Triage and analysis

### Investigating Azure AKS CoreDNS or Kube-DNS Configuration Modified

AKS kube-audit events are carried under the flattened `azure.platformlogs.properties.log.*` subtree and share the ARM
operation `event.action: Microsoft.ContainerService/managedClusters/diagnosticLogs/Read`. CoreDNS resolves in-cluster
service names; an attacker who edits `coredns`/`kube-dns` or creates/edits the user-managed `coredns-custom` ConfigMap
can inject forward or rewrite rules that redirect service resolution to attacker-controlled endpoints, enabling
cluster-wide interception of credentials and traffic. `coredns-custom` is the supported customization surface, so
legitimate DNS tuning also lands here; the acting identity is excluded when it is an AKS platform reconciler
(`aksService`), leaving non-platform changes as the signal.

### Possible investigation steps

- Review the submitted ConfigMap body in `azure.platformlogs.properties.log.requestObject.data` for added forward,
  rewrite, or hosts entries pointing at unexpected IPs or domains. This content, not the act of editing, is what
  distinguishes malicious DNS redirection from routine customization.
- Identify the acting identity in `azure.platformlogs.properties.log.user.username` (and its groups in
  `azure.platformlogs.properties.log.user.groups`) and confirm it should manage the CoreDNS configuration; a workload
  service account (`system:serviceaccount:<ns>:<sa>`) editing cluster DNS is the higher-concern case.
- Confirm the operation and object via `azure.platformlogs.properties.log.verb` (a `create` of `coredns-custom` where it
  did not previously exist is notable) and `azure.platformlogs.properties.log.objectRef.name` (`coredns`,
  `coredns-custom`, or `kube-dns`), and inspect `azure.platformlogs.properties.log.userAgent`.
- Evaluate the source in `azure.platformlogs.properties.log.sourceIPs` and pivot on it for related RBAC changes, secret
  reads, or exec sessions.

### False positive analysis

- `coredns-custom` is the AKS-supported way to add custom forward/stub rules, so approved automation, GitOps, or
  administrators editing it are expected. The AKS reconciler (`aksService`) that continuously (re)creates
  `coredns-custom` is excluded by identity. Validate the change content and window, then exclude the specific verified
  service account rather than re-broadening to all `system:*`.

### Response and remediation

- If unauthorized, restore the CoreDNS ConfigMap from a known-good source, revoke the acting identity's tokens, and
  review the RBAC that permitted the change.
- Hunt for credential capture or redirected traffic during the window the malicious configuration was active.
- Collect kube-audit and identity artifacts per incident response procedures.
"""
references = [
    "https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/",
    "https://microsoft.github.io/Threat-Matrix-for-Kubernetes/",
    "https://microsoft.github.io/Threat-Matrix-for-Kubernetes/techniques/CoreDNS%20poisoning/",
    "https://learn.microsoft.com/en-us/azure/aks/coredns-custom",
    "https://www.aquasec.com/blog/dns-spoofing-kubernetes-clusters/",
    "https://hub.armosec.io/docs/c-0037",
]
risk_score = 47
rule_id = "1291513f-02f2-48d6-9f9c-06e5c8f23ecb"
setup = """
The Azure Fleet integration collecting AKS diagnostic logs forwarded through Event Hub into the `azure.platformlogs`
data stream is required for this rule. Enable either the `kube-audit` or the `kube-audit-admin` log category (Microsoft
recommends `kube-audit-admin` alone to reduce volume, as it only drops read-only get/list events). ConfigMap writes are
mutating operations recorded in both categories with the same `auditID`, so clusters that enable both categories may
generate two alerts per change.
"""
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Kubernetes",
    "Data Source: Azure",
    "Data Source: Azure Platform Logs",
    "Data Source: Kubernetes",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:azure.platformlogs and
  event.action:"Microsoft.ContainerService/managedClusters/diagnosticLogs/Read" and
  azure.platformlogs.category:("kube-audit" or "kube-audit-admin") and
  azure.platformlogs.properties.log.stage:"ResponseComplete" and
  azure.platformlogs.properties.log.objectRef.resource:"configmaps" and
  azure.platformlogs.properties.log.objectRef.namespace:"kube-system" and
  azure.platformlogs.properties.log.objectRef.name:("coredns" or "kube-dns" or "coredns-custom") and
  azure.platformlogs.properties.log.verb:("create" or "update" or "patch" or "delete") and
  not azure.platformlogs.properties.log.user.username:(
    system\:node\:* or "aksService" or "hcpService" or "readinessChecker" or
    system\:serviceaccount\:kube-system\:*
  )
'''

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "event.action",
    "azure.platformlogs.category",
    "azure.platformlogs.properties.log.verb",
    "azure.platformlogs.properties.log.user.username",
    "azure.platformlogs.properties.log.user.groups",
    "azure.platformlogs.properties.log.userAgent",
    "azure.platformlogs.properties.log.sourceIPs",
    "azure.platformlogs.properties.log.objectRef.namespace",
    "azure.platformlogs.properties.log.objectRef.name",
    "azure.platformlogs.properties.log.responseStatus.code",
]

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1557"
name = "Adversary-in-the-Middle"
reference = "https://attack.mitre.org/techniques/T1557/"

[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"