Loading

Azure AKS Potential API Enumeration by User

Detects a single Kubernetes identity in AKS (Azure Kubernetes Service) that is denied (HTTP 403 Forbidden) across multiple distinct API resource types within a short window. Broad authorization failures spanning many resources are a strong signal of API enumeration (reconnaissance with a stolen service account token), as an actor probes what its credentials can reach before privilege escalation. Detection is based on the breadth of denied resources rather than the raw failure count, so single-resource controller retry loops do not trigger it.

Rule type: threshold
Rule indices:

  • logs-azure.platformlogs-*

Rule Severity: medium
Risk Score: 47
Runs every: 5m
Searches indices from: now-9m
Maximum alerts per execution: 100
References:

Tags:

  • Domain: Cloud
  • Domain: Kubernetes
  • Data Source: Azure
  • Data Source: Azure Platform Logs
  • Data Source: Kubernetes
  • Use Case: Threat Detection
  • Tactic: Discovery
  • Resources: Investigation Guide

Version: 1
Rule authors:

  • Elastic

Rule license: Elastic License v2
The Azure Fleet integration collecting AKS diagnostic logs forwarded through Event Hub into the azure.platformlogs data stream is required for this rule. The kube-audit log category is required specifically: authorization denials during enumeration are predominantly get/list/watch (read) operations, which the kube-audit-admin category excludes. A cluster that ships only kube-audit-admin is effectively blind to this rule, since only write-verb denials remain visible.

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. This rule groups forbidden (HTTP 403) Kubernetes API calls by azure.platformlogs.properties.log.user.username and alerts when one identity is denied across several distinct objectRef.resource types within the interval. Breadth of denied resources (rather than raw failure volume) is the signal: an identity probing many resource types it cannot reach is characteristic of API enumeration with a stolen service account token, whereas a controller stuck retrying one forbidden resource stays on a single resource and does not trigger.

  • Enumerate the distinct azure.platformlogs.properties.log.objectRef.resource and azure.platformlogs.properties.log.verb values denied for the identity, and read the human-readable denial in azure.platformlogs.properties.log.responseStatus.message (for example "secrets is forbidden: User ... cannot list resource"), to see what the actor was mapping out.
  • Identify the acting identity in azure.platformlogs.properties.log.user.username and its groups in azure.platformlogs.properties.log.user.groups. Service account tokens (system:serviceaccount:<ns>:<sa>) probing broadly are the primary concern; confirm whether that identity should be issuing these calls at all.
  • Inspect azure.platformlogs.properties.log.userAgent to distinguish interactive tooling (kubectl) or a known controller from custom recon tooling (for example kubectl-recon, curl, or other enumeration clients).
  • Validate the source in azure.platformlogs.properties.log.sourceIPs. In-cluster agents use loopback (127.0.0.1/::1) or pod-network addresses (e.g. 10.244.0.0/16); an external caller wielding a service account token is more suspicious.
  • Hunt for later successful calls (responseStatus.code:2xx) from the same identity or source that indicate the actor found a permitted action or escalated, and correlate with recent Entra ID sign-ins or role assignments.
  • A workload or observability agent with partial RBAC can be denied across several resource types and resemble enumeration. Baseline such identities, raise the cardinality threshold, or exclude the specific validated service account after review.
  • Single-resource retry loops (one resource denied repeatedly, such as a controller watching a resource it lacks permission for) do not trigger this rule, since detection is based on the count of distinct resources denied.
  • If unauthorized, revoke the identity's tokens and kubeconfig and review the RBAC bindings assigned to it.
  • Determine whether any request from the identity succeeded and scope the impact accordingly.
  • Collect kube-audit and identity artifacts per incident response procedures.
data_stream.dataset:azure.platformlogs and
  event.action:"Microsoft.ContainerService/managedClusters/diagnosticLogs/Read" and
  azure.platformlogs.category:"kube-audit" and
  azure.platformlogs.properties.log.stage:"ResponseComplete" and
  azure.platformlogs.properties.log.responseStatus.code:"403" and
  azure.platformlogs.properties.log.responseStatus.reason:"Forbidden" and
  not azure.platformlogs.properties.log.user.username:(
    system\:node\:* or "aksService" or "hcpService" or "readinessChecker" or
    system\:serviceaccount\:kube-system\:*
  )

Framework: MITRE ATT&CK