ConfigMaps

Elastic #

• Kubernetes Secret or ConfigMap Access via Azure Arc Proxy source medium: Detects when secrets or configmaps are accessed, created, modified, or deleted in a Kubernetes cluster by the Azure Arc AAD proxy service account. When operations are routed through the Azure Arc Cluster Connect proxy, the Kubernetes audit log records the acting user as system:serviceaccount:azure-arc:azure-arc-kube-aad-proxy-sa with the actual caller identity in the impersonatedUser field. This pattern indicates that someone is accessing the cluster through the Azure ARM API rather than directly via kubectl against the API server. While legitimate for Arc-managed workflows, adversaries with stolen service principal credentials can abuse Arc Cluster Connect to read, exfiltrate, or modify secrets and configmaps while appearing as the Arc proxy service account in K8s audit logs.T1213, T1530, T1552, T1552.007, T1565, T1565.001↳ also matches list-configmaps: list configmaps, create-configmaps: create configmaps, update-configmaps: update configmaps, patch-configmaps: patch configmaps, delete-configmaps: delete configmaps
  Investigation guide

  Triage and analysis#

  Investigating Kubernetes Secret or ConfigMap Access via Azure Arc Proxy#

  When Kubernetes operations are performed through Azure Arc Cluster Connect, the K8s audit log shows the Arc AAD proxy service account as the authenticated user, with the actual Azure AD identity in the impersonatedUser field. This rule detects non-system secret and configmap access — including reads, writes, and deletions — routed through this proxy path. Read operations (get, list) are particularly important to detect as they represent the most common adversary action: exfiltrating secrets without leaving obvious modification traces.

  Possible investigation steps#

  • Check the kubernetes.audit.impersonatedUser.username field — this contains the Azure AD object ID of the actual caller. Cross-reference with Azure AD to identify the service principal or user.
  • Review the kubernetes.audit.impersonatedUser.extra.oid field for the Azure AD object ID.
  • Examine the namespace — operations in default or application namespaces are more suspicious than azure-arc or kube-system.
  • Check the kubernetes.audit.objectRef.name — look for suspicious secret/configmap names that don't match known application resources.
  • Correlate with Azure Activity Logs for the same time window to find the LISTCLUSTERUSERCREDENTIAL operation that initiated the Arc proxy session.
  • Review Azure Sign-In Logs for the impersonated identity's authentication source IP and geolocation.

  Response and remediation#

  • If the impersonated identity is not recognized, revoke its Azure AD credentials immediately.
  • Remove the ClusterRoleBinding or RoleBinding that grants the identity access to secrets/configmaps.
  • Rotate any Kubernetes secrets that may have been read or exfiltrated.
  • Review the Arc connection and consider disconnecting it if compromised.
• Direct Interactive Kubernetes API Request by Unusual Utilities source low: This rule leverages a combination of Defend for Containers and Kubernetes audit logs to detect the execution of direct interactive Kubernetes API requests via unusual utilities. An adversary may need to execute direct interactive Kubernetes API requests to gain access to the Kubernetes API server or other resources within the cluster. These requests are often used to enumerate the Kubernetes API server or other resources within the cluster, and may indicate an attempt to move laterally within the cluster.T1059, T1059.004, T1069, T1087, T1609, T1610↳ also matches list-configmaps: list configmaps, watch-configmaps: watch configmaps, create-configmaps: create configmaps, update-configmaps: update configmaps, patch-configmaps: patch configmaps
  Investigation guide

  Triage and analysis#

  Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

  Investigating Direct Interactive Kubernetes API Request by Unusual Utilities#

  This rule detects interactive commands executed inside containers that use atypical utilities to hit the Kubernetes API, paired with near-simultaneous API activity on pods, secrets, service accounts, roles/bindings, or pod exec/attach/log/portforward. It surfaces hands-on-keyboard discovery and lateral movement using custom scripts that evade common tool allowlists; for example, an intruder opens a shell in a pod, uses Python to query the in-cluster API to list secrets, then triggers pods/exec to pivot into another workload.

  Possible investigation steps#

  • Identify the implicated pod, container image, and executing service account, then quickly review its RBAC bindings and effective permissions to determine blast radius.
  • Inspect the container’s interactive session context by pulling recent command lines, shell history, environment variables, and mounted service account tokens, and look for custom scripts or binaries issuing HTTP requests.
  • Correlate nearby Kubernetes audit entries tied to the same principal and pod to map accessed resources and verbs, noting any exec/attach/portforward or sensitive object interactions across namespaces.
  • Review network activity from the pod to the API server and any in-pod proxies, including DNS lookups and outbound connections, to spot nonstandard clients or tunneling behavior.
  • If suspicious, isolate the pod or node, capture runtime artifacts (e.g., process memory or HTTP client traffic), revoke and rotate the service account credentials, and verify image provenance and integrity.

  False positive analysis#

  • An operator interactively attaches to a pod and uses a Python REPL or bash with /dev/tcp to call the in-cluster API for routine troubleshooting (e.g., list pods, read ConfigMaps, or run selfsubjectaccessreviews), producing normal audit entries that match the rule signature.
  • A correlation artifact arises when two namespaces have pods with the same name: one pod starts an interactive shell while another independently performs get/list/watch calls, and the 1-second sequence keyed only on pod-name links the unrelated events.

  Response and remediation#

  • Immediately isolate the implicated pod that issued direct API calls using a nonstandard utility by applying a deny-all egress NetworkPolicy in its namespace (including to kubernetes.default.svc:443), terminating the interactive session, and scaling its owning Deployment/Job/StatefulSet to zero replicas.
  • Before teardown, capture a runtime snapshot of the container and node including the binary or script used to query the API (e.g., files under /tmp or /dev/tcp usage), shell history, environment, and the mounted service account token and CA bundle at /var/run/secrets/kubernetes.io/serviceaccount/.
  • Revoke access by removing the service account’s RoleBindings/ClusterRoleBindings, deleting all pods that mount that service account to force token rotation, rotating any Secrets and ConfigMaps that were read or created during the window, and deleting any unauthorized Jobs, CronJobs, or Deployments created by the same principal.
  • Restore workloads from a known-good image digest, re-enable the Deployment only after image scan and integrity checks pass, and monitor subsequent Kubernetes audit logs for pods/exec, portforward, and access to secrets across the affected namespaces.
  • Escalate to incident response leadership and consider cluster-wide containment if audit logs show create/patch of ClusterRoleBindings, access to secrets outside the workload’s namespace, or use of pods/exec to pivot into other nodes or system namespaces such as kube-system.
  • Harden access by enforcing least-privilege RBAC that denies pods/exec and attach for application service accounts, setting automountServiceAccountToken: false on workloads that do not need it, restricting egress to the API server with NetworkPolicies, and requiring just-in-time break-glass roles for interactive access.
• GKE Multi-Resource Discovery source medium: Adversaries who land credentials in a GKE cluster—or abuse an over-privileged token, often map the environment before exfiltration or privilege escalation. A practical first pass is to learn where workloads run, how the cluster is partitioned, and what RBAC exists at namespace vs cluster scope. Rapid get/list traffic across many distinct API resource kinds that answer those questions (namespaces, workloads, roles, cluster-wide roles) is a common setup and orientation pattern for both interactive attackers and automated recon scripts. This rule highlights that cross-resource burst from a single client fingerprint within a one-minute bucket when both cluster-layout and RBAC resource kinds are touched, so analysts can separate routine automation from potential discovery ahead of follow-on actions.T1613↳ also matches list-configmaps: list configmaps
  Investigation guide

  Triage and analysis#

  Investigating GKE Multi-Resource Discovery#

  The rule groups GKE audit get/list events on namespaces, nodes, pods, configmaps, serviceaccounts, roles, rolebindings, clusterroles, and clusterrolebindings into one-minute windows per client.user.email, source.ip, and user_agent.original. It alerts when five or more distinct resource kinds appear and the burst includes both cluster-layout kinds (namespaces, pods, or nodes) and RBAC kinds. Allowed and denied authorizations are both included: failures still signal probing.

  Possible investigation steps#

  • Review Esql.enumerated_resources, Esql.enumerated_namespaces, and Esql.enumerated_resource_names for ordering and targeted APIs.
  • Confirm whether source.ip and user_agent.original match expected admin or automation clients.
  • Correlate with follow-on secret reads, RoleBinding changes, pod exec, or unusual user agents from the same actor.

  False positive analysis#

  • Documented platform sync jobs that read layout and RBAC together; exclude known service accounts after validation.
  • Upgrade or install windows that briefly query many resource kinds; correlate with change records.

  Response and remediation#

  • If malicious, revoke or rotate the implicated credentials, tighten RBAC, and inspect for data access or persistence established after the burst.

Elastic #

• Direct Interactive Kubernetes API Request by Unusual Utilities source low: This rule leverages a combination of Defend for Containers and Kubernetes audit logs to detect the execution of direct interactive Kubernetes API requests via unusual utilities. An adversary may need to execute direct interactive Kubernetes API requests to gain access to the Kubernetes API server or other resources within the cluster. These requests are often used to enumerate the Kubernetes API server or other resources within the cluster, and may indicate an attempt to move laterally within the cluster.T1059, T1059.004, T1069, T1087, T1609, T1610↳ also matches get-configmaps: get configmaps, watch-configmaps: watch configmaps, create-configmaps: create configmaps, update-configmaps: update configmaps, patch-configmaps: patch configmaps
  Investigation guide

  Triage and analysis#

  Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

  Investigating Direct Interactive Kubernetes API Request by Unusual Utilities#

  This rule detects interactive commands executed inside containers that use atypical utilities to hit the Kubernetes API, paired with near-simultaneous API activity on pods, secrets, service accounts, roles/bindings, or pod exec/attach/log/portforward. It surfaces hands-on-keyboard discovery and lateral movement using custom scripts that evade common tool allowlists; for example, an intruder opens a shell in a pod, uses Python to query the in-cluster API to list secrets, then triggers pods/exec to pivot into another workload.

  Possible investigation steps#

  • Identify the implicated pod, container image, and executing service account, then quickly review its RBAC bindings and effective permissions to determine blast radius.
  • Inspect the container’s interactive session context by pulling recent command lines, shell history, environment variables, and mounted service account tokens, and look for custom scripts or binaries issuing HTTP requests.
  • Correlate nearby Kubernetes audit entries tied to the same principal and pod to map accessed resources and verbs, noting any exec/attach/portforward or sensitive object interactions across namespaces.
  • Review network activity from the pod to the API server and any in-pod proxies, including DNS lookups and outbound connections, to spot nonstandard clients or tunneling behavior.
  • If suspicious, isolate the pod or node, capture runtime artifacts (e.g., process memory or HTTP client traffic), revoke and rotate the service account credentials, and verify image provenance and integrity.

  False positive analysis#

  • An operator interactively attaches to a pod and uses a Python REPL or bash with /dev/tcp to call the in-cluster API for routine troubleshooting (e.g., list pods, read ConfigMaps, or run selfsubjectaccessreviews), producing normal audit entries that match the rule signature.
  • A correlation artifact arises when two namespaces have pods with the same name: one pod starts an interactive shell while another independently performs get/list/watch calls, and the 1-second sequence keyed only on pod-name links the unrelated events.

  Response and remediation#

  • Immediately isolate the implicated pod that issued direct API calls using a nonstandard utility by applying a deny-all egress NetworkPolicy in its namespace (including to kubernetes.default.svc:443), terminating the interactive session, and scaling its owning Deployment/Job/StatefulSet to zero replicas.
  • Before teardown, capture a runtime snapshot of the container and node including the binary or script used to query the API (e.g., files under /tmp or /dev/tcp usage), shell history, environment, and the mounted service account token and CA bundle at /var/run/secrets/kubernetes.io/serviceaccount/.
  • Revoke access by removing the service account’s RoleBindings/ClusterRoleBindings, deleting all pods that mount that service account to force token rotation, rotating any Secrets and ConfigMaps that were read or created during the window, and deleting any unauthorized Jobs, CronJobs, or Deployments created by the same principal.
  • Restore workloads from a known-good image digest, re-enable the Deployment only after image scan and integrity checks pass, and monitor subsequent Kubernetes audit logs for pods/exec, portforward, and access to secrets across the affected namespaces.
  • Escalate to incident response leadership and consider cluster-wide containment if audit logs show create/patch of ClusterRoleBindings, access to secrets outside the workload’s namespace, or use of pods/exec to pivot into other nodes or system namespaces such as kube-system.
  • Harden access by enforcing least-privilege RBAC that denies pods/exec and attach for application service accounts, setting automountServiceAccountToken: false on workloads that do not need it, restricting egress to the API server with NetworkPolicies, and requiring just-in-time break-glass roles for interactive access.
• GKE Multi-Resource Discovery source medium: Adversaries who land credentials in a GKE cluster—or abuse an over-privileged token, often map the environment before exfiltration or privilege escalation. A practical first pass is to learn where workloads run, how the cluster is partitioned, and what RBAC exists at namespace vs cluster scope. Rapid get/list traffic across many distinct API resource kinds that answer those questions (namespaces, workloads, roles, cluster-wide roles) is a common setup and orientation pattern for both interactive attackers and automated recon scripts. This rule highlights that cross-resource burst from a single client fingerprint within a one-minute bucket when both cluster-layout and RBAC resource kinds are touched, so analysts can separate routine automation from potential discovery ahead of follow-on actions.T1613↳ also matches get-configmaps: get configmaps
  Investigation guide

  Triage and analysis#

  Investigating GKE Multi-Resource Discovery#

  The rule groups GKE audit get/list events on namespaces, nodes, pods, configmaps, serviceaccounts, roles, rolebindings, clusterroles, and clusterrolebindings into one-minute windows per client.user.email, source.ip, and user_agent.original. It alerts when five or more distinct resource kinds appear and the burst includes both cluster-layout kinds (namespaces, pods, or nodes) and RBAC kinds. Allowed and denied authorizations are both included: failures still signal probing.

  Possible investigation steps#

  • Review Esql.enumerated_resources, Esql.enumerated_namespaces, and Esql.enumerated_resource_names for ordering and targeted APIs.
  • Confirm whether source.ip and user_agent.original match expected admin or automation clients.
  • Correlate with follow-on secret reads, RoleBinding changes, pod exec, or unusual user agents from the same actor.

  False positive analysis#

  • Documented platform sync jobs that read layout and RBAC together; exclude known service accounts after validation.
  • Upgrade or install windows that briefly query many resource kinds; correlate with change records.

  Response and remediation#

  • If malicious, revoke or rotate the implicated credentials, tighten RBAC, and inspect for data access or persistence established after the burst.
• Kubernetes Secret or ConfigMap Access via Azure Arc Proxy source medium: Detects when secrets or configmaps are accessed, created, modified, or deleted in a Kubernetes cluster by the Azure Arc AAD proxy service account. When operations are routed through the Azure Arc Cluster Connect proxy, the Kubernetes audit log records the acting user as system:serviceaccount:azure-arc:azure-arc-kube-aad-proxy-sa with the actual caller identity in the impersonatedUser field. This pattern indicates that someone is accessing the cluster through the Azure ARM API rather than directly via kubectl against the API server. While legitimate for Arc-managed workflows, adversaries with stolen service principal credentials can abuse Arc Cluster Connect to read, exfiltrate, or modify secrets and configmaps while appearing as the Arc proxy service account in K8s audit logs.T1213, T1530, T1552, T1552.007, T1565, T1565.001↳ also matches get-configmaps: get configmaps, create-configmaps: create configmaps, update-configmaps: update configmaps, patch-configmaps: patch configmaps, delete-configmaps: delete configmaps
  Investigation guide

  Triage and analysis#

  Investigating Kubernetes Secret or ConfigMap Access via Azure Arc Proxy#

  When Kubernetes operations are performed through Azure Arc Cluster Connect, the K8s audit log shows the Arc AAD proxy service account as the authenticated user, with the actual Azure AD identity in the impersonatedUser field. This rule detects non-system secret and configmap access — including reads, writes, and deletions — routed through this proxy path. Read operations (get, list) are particularly important to detect as they represent the most common adversary action: exfiltrating secrets without leaving obvious modification traces.

  Possible investigation steps#

  • Check the kubernetes.audit.impersonatedUser.username field — this contains the Azure AD object ID of the actual caller. Cross-reference with Azure AD to identify the service principal or user.
  • Review the kubernetes.audit.impersonatedUser.extra.oid field for the Azure AD object ID.
  • Examine the namespace — operations in default or application namespaces are more suspicious than azure-arc or kube-system.
  • Check the kubernetes.audit.objectRef.name — look for suspicious secret/configmap names that don't match known application resources.
  • Correlate with Azure Activity Logs for the same time window to find the LISTCLUSTERUSERCREDENTIAL operation that initiated the Arc proxy session.
  • Review Azure Sign-In Logs for the impersonated identity's authentication source IP and geolocation.

  Response and remediation#

  • If the impersonated identity is not recognized, revoke its Azure AD credentials immediately.
  • Remove the ClusterRoleBinding or RoleBinding that grants the identity access to secrets/configmaps.
  • Rotate any Kubernetes secrets that may have been read or exfiltrated.
  • Review the Arc connection and consider disconnecting it if compromised.

Elastic #

• Direct Interactive Kubernetes API Request by Unusual Utilities source low: This rule leverages a combination of Defend for Containers and Kubernetes audit logs to detect the execution of direct interactive Kubernetes API requests via unusual utilities. An adversary may need to execute direct interactive Kubernetes API requests to gain access to the Kubernetes API server or other resources within the cluster. These requests are often used to enumerate the Kubernetes API server or other resources within the cluster, and may indicate an attempt to move laterally within the cluster.T1059, T1059.004, T1069, T1087, T1609, T1610↳ also matches get-configmaps: get configmaps, list-configmaps: list configmaps, create-configmaps: create configmaps, update-configmaps: update configmaps, patch-configmaps: patch configmaps
  Investigation guide

  Triage and analysis#

  Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

  Investigating Direct Interactive Kubernetes API Request by Unusual Utilities#

  This rule detects interactive commands executed inside containers that use atypical utilities to hit the Kubernetes API, paired with near-simultaneous API activity on pods, secrets, service accounts, roles/bindings, or pod exec/attach/log/portforward. It surfaces hands-on-keyboard discovery and lateral movement using custom scripts that evade common tool allowlists; for example, an intruder opens a shell in a pod, uses Python to query the in-cluster API to list secrets, then triggers pods/exec to pivot into another workload.

  Possible investigation steps#

  • Identify the implicated pod, container image, and executing service account, then quickly review its RBAC bindings and effective permissions to determine blast radius.
  • Inspect the container’s interactive session context by pulling recent command lines, shell history, environment variables, and mounted service account tokens, and look for custom scripts or binaries issuing HTTP requests.
  • Correlate nearby Kubernetes audit entries tied to the same principal and pod to map accessed resources and verbs, noting any exec/attach/portforward or sensitive object interactions across namespaces.
  • Review network activity from the pod to the API server and any in-pod proxies, including DNS lookups and outbound connections, to spot nonstandard clients or tunneling behavior.
  • If suspicious, isolate the pod or node, capture runtime artifacts (e.g., process memory or HTTP client traffic), revoke and rotate the service account credentials, and verify image provenance and integrity.

  False positive analysis#

  • An operator interactively attaches to a pod and uses a Python REPL or bash with /dev/tcp to call the in-cluster API for routine troubleshooting (e.g., list pods, read ConfigMaps, or run selfsubjectaccessreviews), producing normal audit entries that match the rule signature.
  • A correlation artifact arises when two namespaces have pods with the same name: one pod starts an interactive shell while another independently performs get/list/watch calls, and the 1-second sequence keyed only on pod-name links the unrelated events.

  Response and remediation#

  • Immediately isolate the implicated pod that issued direct API calls using a nonstandard utility by applying a deny-all egress NetworkPolicy in its namespace (including to kubernetes.default.svc:443), terminating the interactive session, and scaling its owning Deployment/Job/StatefulSet to zero replicas.
  • Before teardown, capture a runtime snapshot of the container and node including the binary or script used to query the API (e.g., files under /tmp or /dev/tcp usage), shell history, environment, and the mounted service account token and CA bundle at /var/run/secrets/kubernetes.io/serviceaccount/.
  • Revoke access by removing the service account’s RoleBindings/ClusterRoleBindings, deleting all pods that mount that service account to force token rotation, rotating any Secrets and ConfigMaps that were read or created during the window, and deleting any unauthorized Jobs, CronJobs, or Deployments created by the same principal.
  • Restore workloads from a known-good image digest, re-enable the Deployment only after image scan and integrity checks pass, and monitor subsequent Kubernetes audit logs for pods/exec, portforward, and access to secrets across the affected namespaces.
  • Escalate to incident response leadership and consider cluster-wide containment if audit logs show create/patch of ClusterRoleBindings, access to secrets outside the workload’s namespace, or use of pods/exec to pivot into other nodes or system namespaces such as kube-system.
  • Harden access by enforcing least-privilege RBAC that denies pods/exec and attach for application service accounts, setting automountServiceAccountToken: false on workloads that do not need it, restricting egress to the API server with NetworkPolicies, and requiring just-in-time break-glass roles for interactive access.

Elastic #

• Azure AKS CoreDNS or Kube-DNS Configuration Modified source medium: 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.T1557↳ also matches update-configmaps: update configmaps, patch-configmaps: patch configmaps, delete-configmaps: delete configmaps
  Investigation guide

  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.
• Direct Interactive Kubernetes API Request by Unusual Utilities source low: This rule leverages a combination of Defend for Containers and Kubernetes audit logs to detect the execution of direct interactive Kubernetes API requests via unusual utilities. An adversary may need to execute direct interactive Kubernetes API requests to gain access to the Kubernetes API server or other resources within the cluster. These requests are often used to enumerate the Kubernetes API server or other resources within the cluster, and may indicate an attempt to move laterally within the cluster.T1059, T1059.004, T1069, T1087, T1609, T1610↳ also matches get-configmaps: get configmaps, list-configmaps: list configmaps, watch-configmaps: watch configmaps, update-configmaps: update configmaps, patch-configmaps: patch configmaps
  Investigation guide

  Triage and analysis#

  Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

  Investigating Direct Interactive Kubernetes API Request by Unusual Utilities#

  This rule detects interactive commands executed inside containers that use atypical utilities to hit the Kubernetes API, paired with near-simultaneous API activity on pods, secrets, service accounts, roles/bindings, or pod exec/attach/log/portforward. It surfaces hands-on-keyboard discovery and lateral movement using custom scripts that evade common tool allowlists; for example, an intruder opens a shell in a pod, uses Python to query the in-cluster API to list secrets, then triggers pods/exec to pivot into another workload.

  Possible investigation steps#

  • Identify the implicated pod, container image, and executing service account, then quickly review its RBAC bindings and effective permissions to determine blast radius.
  • Inspect the container’s interactive session context by pulling recent command lines, shell history, environment variables, and mounted service account tokens, and look for custom scripts or binaries issuing HTTP requests.
  • Correlate nearby Kubernetes audit entries tied to the same principal and pod to map accessed resources and verbs, noting any exec/attach/portforward or sensitive object interactions across namespaces.
  • Review network activity from the pod to the API server and any in-pod proxies, including DNS lookups and outbound connections, to spot nonstandard clients or tunneling behavior.
  • If suspicious, isolate the pod or node, capture runtime artifacts (e.g., process memory or HTTP client traffic), revoke and rotate the service account credentials, and verify image provenance and integrity.

  False positive analysis#

  • An operator interactively attaches to a pod and uses a Python REPL or bash with /dev/tcp to call the in-cluster API for routine troubleshooting (e.g., list pods, read ConfigMaps, or run selfsubjectaccessreviews), producing normal audit entries that match the rule signature.
  • A correlation artifact arises when two namespaces have pods with the same name: one pod starts an interactive shell while another independently performs get/list/watch calls, and the 1-second sequence keyed only on pod-name links the unrelated events.

  Response and remediation#

  • Immediately isolate the implicated pod that issued direct API calls using a nonstandard utility by applying a deny-all egress NetworkPolicy in its namespace (including to kubernetes.default.svc:443), terminating the interactive session, and scaling its owning Deployment/Job/StatefulSet to zero replicas.
  • Before teardown, capture a runtime snapshot of the container and node including the binary or script used to query the API (e.g., files under /tmp or /dev/tcp usage), shell history, environment, and the mounted service account token and CA bundle at /var/run/secrets/kubernetes.io/serviceaccount/.
  • Revoke access by removing the service account’s RoleBindings/ClusterRoleBindings, deleting all pods that mount that service account to force token rotation, rotating any Secrets and ConfigMaps that were read or created during the window, and deleting any unauthorized Jobs, CronJobs, or Deployments created by the same principal.
  • Restore workloads from a known-good image digest, re-enable the Deployment only after image scan and integrity checks pass, and monitor subsequent Kubernetes audit logs for pods/exec, portforward, and access to secrets across the affected namespaces.
  • Escalate to incident response leadership and consider cluster-wide containment if audit logs show create/patch of ClusterRoleBindings, access to secrets outside the workload’s namespace, or use of pods/exec to pivot into other nodes or system namespaces such as kube-system.
  • Harden access by enforcing least-privilege RBAC that denies pods/exec and attach for application service accounts, setting automountServiceAccountToken: false on workloads that do not need it, restricting egress to the API server with NetworkPolicies, and requiring just-in-time break-glass roles for interactive access.
• Kubernetes Secret or ConfigMap Access via Azure Arc Proxy source medium: Detects when secrets or configmaps are accessed, created, modified, or deleted in a Kubernetes cluster by the Azure Arc AAD proxy service account. When operations are routed through the Azure Arc Cluster Connect proxy, the Kubernetes audit log records the acting user as system:serviceaccount:azure-arc:azure-arc-kube-aad-proxy-sa with the actual caller identity in the impersonatedUser field. This pattern indicates that someone is accessing the cluster through the Azure ARM API rather than directly via kubectl against the API server. While legitimate for Arc-managed workflows, adversaries with stolen service principal credentials can abuse Arc Cluster Connect to read, exfiltrate, or modify secrets and configmaps while appearing as the Arc proxy service account in K8s audit logs.T1213, T1530, T1552, T1552.007, T1565, T1565.001↳ also matches get-configmaps: get configmaps, list-configmaps: list configmaps, update-configmaps: update configmaps, patch-configmaps: patch configmaps, delete-configmaps: delete configmaps
  Investigation guide

  Triage and analysis#

  Investigating Kubernetes Secret or ConfigMap Access via Azure Arc Proxy#

  When Kubernetes operations are performed through Azure Arc Cluster Connect, the K8s audit log shows the Arc AAD proxy service account as the authenticated user, with the actual Azure AD identity in the impersonatedUser field. This rule detects non-system secret and configmap access — including reads, writes, and deletions — routed through this proxy path. Read operations (get, list) are particularly important to detect as they represent the most common adversary action: exfiltrating secrets without leaving obvious modification traces.

  Possible investigation steps#

  • Check the kubernetes.audit.impersonatedUser.username field — this contains the Azure AD object ID of the actual caller. Cross-reference with Azure AD to identify the service principal or user.
  • Review the kubernetes.audit.impersonatedUser.extra.oid field for the Azure AD object ID.
  • Examine the namespace — operations in default or application namespaces are more suspicious than azure-arc or kube-system.
  • Check the kubernetes.audit.objectRef.name — look for suspicious secret/configmap names that don't match known application resources.
  • Correlate with Azure Activity Logs for the same time window to find the LISTCLUSTERUSERCREDENTIAL operation that initiated the Arc proxy session.
  • Review Azure Sign-In Logs for the impersonated identity's authentication source IP and geolocation.

  Response and remediation#

  • If the impersonated identity is not recognized, revoke its Azure AD credentials immediately.
  • Remove the ClusterRoleBinding or RoleBinding that grants the identity access to secrets/configmaps.
  • Rotate any Kubernetes secrets that may have been read or exfiltrated.
  • Review the Arc connection and consider disconnecting it if compromised.

Falco #

• Create/Modify Configmap With Private Credentials source WARNING: Detect creating/modifying a configmap containing a private credential (aws key, password, etc.) ↳ also matches update-configmaps: update configmaps, patch-configmaps: patch configmaps
• K8s ConfigMap Created source INFO: Detect any attempt to create a configmap

Elastic #

• GKE CoreDNS or Kube-DNS Configuration Modified source high: Detects modifications to the CoreDNS or kube-dns ConfigMap in the kube-system namespace on GKE. 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.T1565, T1565.001↳ also matches patch-configmaps: patch configmaps, delete-configmaps: delete configmaps
  Investigation guide

  Triage and analysis#

  Investigating GKE CoreDNS or Kube-DNS Configuration Modified#

  Identify who performed the change (user.email, 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.

  Setup#

  The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule.

• Kubernetes CoreDNS or Kube-DNS Configuration Modified source high: 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.T1565, T1565.001↳ also matches patch-configmaps: patch configmaps, delete-configmaps: delete configmaps
  Investigation guide

  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.
• EKS Authentication Configuration Modified source high: Detects modifications to the aws-auth ConfigMap in Amazon EKS clusters. The aws-auth ConfigMap maps AWS IAM roles and users to Kubernetes RBAC groups, an attacker who modifies it can grant any IAM role cluster-admin access by adding a mapping to the system:masters group. This is a well-documented persistence technique that survives pod restarts, node replacements, and RBAC changes because the authentication mapping exists outside of normal Kubernetes Role objects. Modifications to aws-auth are rare in normal operations, the ConfigMap is typically set during cluster provisioning and updated only during node group or access configuration changes.T1098, T1098.006↳ also matches patch-configmaps: patch configmaps, delete-configmaps: delete configmaps
  Investigation guide

  Triage and analysis#

  Investigating EKS Authentication Configuration Modified#

  Confirm who changed the mapping (user.name, groups, source.ip, user_agent.original) and whether the change aligns with approved cluster or node-group operations. Compare the new aws-auth mapRoles/mapUsers content to the prior revision if request/response capture is available in audit.

  Possible investigation steps#

  • Identify any new IAM role ARNs or users bound to system:masters or other privileged Kubernetes groups.
  • Correlate the timestamp with AWS CloudTrail for related EKS or IAM API activity and with GitOps or pipeline commits.
  • Review subsequent API activity from newly mapped IAM principals for secret access, RBAC changes, or workload deployment.
  • If Access Entries are enabled, also review CloudTrail for eks:CreateAccessEntry, eks:AssociateAccessPolicy, and similar API calls around the same window.

  Response and remediation#

  • If unauthorized, revert aws-auth from a known-good backup, remove rogue map entries, and rotate or restrict IAM that could have performed the change.
  • Audit IAM policies that allow eks:UpdateClusterConfig or broad ConfigMap write access to kube-system.
  • Escalate per incident policy when system:masters mappings appear from unexpected IAM identities.

Show 3 more (6 total) on the rules page

Falco #

• Create/Modify Configmap With Private Credentials source WARNING: Detect creating/modifying a configmap containing a private credential (aws key, password, etc.) ↳ also matches create-configmaps: create configmaps, patch-configmaps: patch configmaps

Elastic #

• Direct Interactive Kubernetes API Request by Unusual Utilities source low: This rule leverages a combination of Defend for Containers and Kubernetes audit logs to detect the execution of direct interactive Kubernetes API requests via unusual utilities. An adversary may need to execute direct interactive Kubernetes API requests to gain access to the Kubernetes API server or other resources within the cluster. These requests are often used to enumerate the Kubernetes API server or other resources within the cluster, and may indicate an attempt to move laterally within the cluster.T1059, T1059.004, T1069, T1087, T1609, T1610↳ also matches get-configmaps: get configmaps, list-configmaps: list configmaps, watch-configmaps: watch configmaps, create-configmaps: create configmaps, update-configmaps: update configmaps
  Investigation guide

  Triage and analysis#

  Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

  Investigating Direct Interactive Kubernetes API Request by Unusual Utilities#

  This rule detects interactive commands executed inside containers that use atypical utilities to hit the Kubernetes API, paired with near-simultaneous API activity on pods, secrets, service accounts, roles/bindings, or pod exec/attach/log/portforward. It surfaces hands-on-keyboard discovery and lateral movement using custom scripts that evade common tool allowlists; for example, an intruder opens a shell in a pod, uses Python to query the in-cluster API to list secrets, then triggers pods/exec to pivot into another workload.

  Possible investigation steps#

  • Identify the implicated pod, container image, and executing service account, then quickly review its RBAC bindings and effective permissions to determine blast radius.
  • Inspect the container’s interactive session context by pulling recent command lines, shell history, environment variables, and mounted service account tokens, and look for custom scripts or binaries issuing HTTP requests.
  • Correlate nearby Kubernetes audit entries tied to the same principal and pod to map accessed resources and verbs, noting any exec/attach/portforward or sensitive object interactions across namespaces.
  • Review network activity from the pod to the API server and any in-pod proxies, including DNS lookups and outbound connections, to spot nonstandard clients or tunneling behavior.
  • If suspicious, isolate the pod or node, capture runtime artifacts (e.g., process memory or HTTP client traffic), revoke and rotate the service account credentials, and verify image provenance and integrity.

  False positive analysis#

  • An operator interactively attaches to a pod and uses a Python REPL or bash with /dev/tcp to call the in-cluster API for routine troubleshooting (e.g., list pods, read ConfigMaps, or run selfsubjectaccessreviews), producing normal audit entries that match the rule signature.
  • A correlation artifact arises when two namespaces have pods with the same name: one pod starts an interactive shell while another independently performs get/list/watch calls, and the 1-second sequence keyed only on pod-name links the unrelated events.

  Response and remediation#

  • Immediately isolate the implicated pod that issued direct API calls using a nonstandard utility by applying a deny-all egress NetworkPolicy in its namespace (including to kubernetes.default.svc:443), terminating the interactive session, and scaling its owning Deployment/Job/StatefulSet to zero replicas.
  • Before teardown, capture a runtime snapshot of the container and node including the binary or script used to query the API (e.g., files under /tmp or /dev/tcp usage), shell history, environment, and the mounted service account token and CA bundle at /var/run/secrets/kubernetes.io/serviceaccount/.
  • Revoke access by removing the service account’s RoleBindings/ClusterRoleBindings, deleting all pods that mount that service account to force token rotation, rotating any Secrets and ConfigMaps that were read or created during the window, and deleting any unauthorized Jobs, CronJobs, or Deployments created by the same principal.
  • Restore workloads from a known-good image digest, re-enable the Deployment only after image scan and integrity checks pass, and monitor subsequent Kubernetes audit logs for pods/exec, portforward, and access to secrets across the affected namespaces.
  • Escalate to incident response leadership and consider cluster-wide containment if audit logs show create/patch of ClusterRoleBindings, access to secrets outside the workload’s namespace, or use of pods/exec to pivot into other nodes or system namespaces such as kube-system.
  • Harden access by enforcing least-privilege RBAC that denies pods/exec and attach for application service accounts, setting automountServiceAccountToken: false on workloads that do not need it, restricting egress to the API server with NetworkPolicies, and requiring just-in-time break-glass roles for interactive access.
• Azure AKS CoreDNS or Kube-DNS Configuration Modified source medium: 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.T1557↳ also matches create-configmaps: create configmaps, update-configmaps: update configmaps, delete-configmaps: delete configmaps
  Investigation guide

  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.
• GKE CoreDNS or Kube-DNS Configuration Modified source high: Detects modifications to the CoreDNS or kube-dns ConfigMap in the kube-system namespace on GKE. 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.T1565, T1565.001↳ also matches update-configmaps: update configmaps, delete-configmaps: delete configmaps
  Investigation guide

  Triage and analysis#

  Investigating GKE CoreDNS or Kube-DNS Configuration Modified#

  Identify who performed the change (user.email, 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.

  Setup#

  The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule.

Show 3 more (6 total) on the rules page

Falco #

• Create/Modify Configmap With Private Credentials source WARNING: Detect creating/modifying a configmap containing a private credential (aws key, password, etc.) ↳ also matches create-configmaps: create configmaps, update-configmaps: update configmaps

Elastic #

• Azure AKS CoreDNS or Kube-DNS Configuration Modified source medium: 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.T1557↳ also matches create-configmaps: create configmaps, update-configmaps: update configmaps, patch-configmaps: patch configmaps
  Investigation guide

  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.
• GKE CoreDNS or Kube-DNS Configuration Modified source high: Detects modifications to the CoreDNS or kube-dns ConfigMap in the kube-system namespace on GKE. 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.T1565, T1565.001↳ also matches update-configmaps: update configmaps, patch-configmaps: patch configmaps
  Investigation guide

  Triage and analysis#

  Investigating GKE CoreDNS or Kube-DNS Configuration Modified#

  Identify who performed the change (user.email, 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.

  Setup#

  The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule.

• Kubernetes Secret or ConfigMap Access via Azure Arc Proxy source medium: Detects when secrets or configmaps are accessed, created, modified, or deleted in a Kubernetes cluster by the Azure Arc AAD proxy service account. When operations are routed through the Azure Arc Cluster Connect proxy, the Kubernetes audit log records the acting user as system:serviceaccount:azure-arc:azure-arc-kube-aad-proxy-sa with the actual caller identity in the impersonatedUser field. This pattern indicates that someone is accessing the cluster through the Azure ARM API rather than directly via kubectl against the API server. While legitimate for Arc-managed workflows, adversaries with stolen service principal credentials can abuse Arc Cluster Connect to read, exfiltrate, or modify secrets and configmaps while appearing as the Arc proxy service account in K8s audit logs.T1213, T1530, T1552, T1552.007, T1565, T1565.001↳ also matches get-configmaps: get configmaps, list-configmaps: list configmaps, create-configmaps: create configmaps, update-configmaps: update configmaps, patch-configmaps: patch configmaps
  Investigation guide

  Triage and analysis#

  Investigating Kubernetes Secret or ConfigMap Access via Azure Arc Proxy#

  When Kubernetes operations are performed through Azure Arc Cluster Connect, the K8s audit log shows the Arc AAD proxy service account as the authenticated user, with the actual Azure AD identity in the impersonatedUser field. This rule detects non-system secret and configmap access — including reads, writes, and deletions — routed through this proxy path. Read operations (get, list) are particularly important to detect as they represent the most common adversary action: exfiltrating secrets without leaving obvious modification traces.

  Possible investigation steps#

  • Check the kubernetes.audit.impersonatedUser.username field — this contains the Azure AD object ID of the actual caller. Cross-reference with Azure AD to identify the service principal or user.
  • Review the kubernetes.audit.impersonatedUser.extra.oid field for the Azure AD object ID.
  • Examine the namespace — operations in default or application namespaces are more suspicious than azure-arc or kube-system.
  • Check the kubernetes.audit.objectRef.name — look for suspicious secret/configmap names that don't match known application resources.
  • Correlate with Azure Activity Logs for the same time window to find the LISTCLUSTERUSERCREDENTIAL operation that initiated the Arc proxy session.
  • Review Azure Sign-In Logs for the impersonated identity's authentication source IP and geolocation.

  Response and remediation#

  • If the impersonated identity is not recognized, revoke its Azure AD credentials immediately.
  • Remove the ClusterRoleBinding or RoleBinding that grants the identity access to secrets/configmaps.
  • Rotate any Kubernetes secrets that may have been read or exfiltrated.
  • Review the Arc connection and consider disconnecting it if compromised.

Show 2 more (5 total) on the rules page

Falco #

• K8s ConfigMap Deleted source INFO: Detect any attempt to delete a configmap

Elastic #

• Kubernetes Unusual Decision by User Agent source low: This rule detects unusual request responses in Kubernetes audit logs through the use of the "new_terms" rule type. In production environments, default API requests are typically made by system components or trusted users, who are expected to have a consistent user agent and allowed response annotations. By monitoring for anomalies in the username and response annotations, this rule helps identify potential unauthorized access or misconfigurations in the Kubernetes environment.T1078
• Kubernetes Multi-Resource Discovery source medium: Adversaries who land credentials in a cluster—or abuse an over-privileged token—often map the environment before exfiltration or privilege escalation. A practical first pass is to learn where workloads run, how the cluster is partitioned, and what RBAC exists at namespace vs cluster scope. Rapid get/list traffic across distinct API resource kinds that answer those questions (namespaces, workloads, roles, cluster-wide roles) is a common setup and orientation pattern for both interactive attackers and automated recon scripts. It is less typical for steady-state controllers, which usually touch a narrow set of resources repeatedly. This rule highlights that cross-resource burst from a single client fingerprint within a one-minute bucket so analysts can separate routine automation from potential discovery and permission reconnaissance ahead of follow-on actions.T1613