Azure AKS CoreDNS or Kube-DNS Configuration Modified
editAzure AKS CoreDNS or Kube-DNS Configuration Modified
editDetects 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.
Rule type: query
Rule indices:
- logs-azure.platformlogs-*
Severity: medium
Risk score: 47
Runs every: 5m
Searches indices from: now-9m (Date Math format, see also Additional look-back time)
Maximum alerts per execution: 100
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
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
Version: 1
Rule authors:
- Elastic
Rule license: Elastic License v2
Investigation guide
editTriage 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.datafor 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 inazure.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(acreateofcoredns-customwhere it did not previously exist is notable) andazure.platformlogs.properties.log.objectRef.name(coredns,coredns-custom, orkube-dns), and inspectazure.platformlogs.properties.log.userAgent. -
Evaluate the source in
azure.platformlogs.properties.log.sourceIPsand pivot on it for related RBAC changes, secret reads, or exec sessions.
False positive analysis
-
coredns-customis 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)createscoredns-customis excluded by identity. Validate the change content and window, then exclude the specific verified service account rather than re-broadening to allsystem:*.
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.
Setup
editThe 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.
Rule query
editdata_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\:*
)
Framework: MITRE ATT&CKTM
-
Tactic:
- Name: Credential Access
- ID: TA0006
- Reference URL: https://attack.mitre.org/tactics/TA0006/
-
Technique:
- Name: Adversary-in-the-Middle
- ID: T1557
- Reference URL: https://attack.mitre.org/techniques/T1557/