« Azure AKS Secret get or list with Suspicious User Agent Azure AKS Suspicious Self-Subject Review by Service Account or Node Identity »
Elastic Docs ›Elastic Security [8.19] ›Detections and alerts ›Prebuilt rule reference

Azure AKS Service Account Token Created via TokenRequest API

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Azure AKS Service Account Token Created via TokenRequest API

edit

Detects an identity minting a service account token via the AKS (Azure Kubernetes Service) TokenRequest API (serviceaccounts/token), excluding known AKS control-plane and platform identities. Adversaries request service account tokens from a compromised identity to impersonate a workload, move laterally, or escalate privileges within the cluster. Coverage includes workload service accounts (system:serviceaccount:*), so a compromised in-cluster token minting a token for another service account 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:

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

edit

Triage and analysis

Investigating Azure AKS Service Account Token Created via TokenRequest API

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. The TokenRequest API (serviceaccounts/token) mints a bound service account token. The kubelet (system:node:*) and the kube-controller-manager (aksService) mint these tokens continuously for normal pod operation and are excluded; the signal is a non-platform identity minting one. An attacker with rights over a service account can request a token to act as that workload identity, reaching resources the compromised principal cannot.

Possible investigation steps

  • Identify the requesting identity in azure.platformlogs.properties.log.user.username (and its groups in azure.platformlogs.properties.log.user.groups) and whether it should mint tokens. A workload service account (system:serviceaccount:<ns>:<sa>) minting a token, or masterclient (the local cluster-admin cert), is the higher-concern case.
  • Inspect azure.platformlogs.properties.log.userAgent to distinguish interactive/expected tooling (kubectl create token) from custom clients (for example curl), which is a stronger indicator of scripted abuse.
  • Identify the target service account in azure.platformlogs.properties.log.objectRef.name / azure.platformlogs.properties.log.objectRef.namespace and what RBAC that account holds; minting a token for a higher-privileged service account is privilege escalation.
  • Evaluate the source in azure.platformlogs.properties.log.sourceIPs and pivot on it for follow-on API calls made with the minted token, and correlate with recent RBAC changes, secret reads, or exec sessions from the same identity.

False positive analysis

  • Controllers, CI/CD systems, and platform components legitimately request service account tokens (for example the kube-controller-manager as aksService, which is excluded). Additional automation such as GitOps operators or CI running kubectl create token may surface; baseline those identities and exclude the specific validated account rather than re-broadening to all system:*, which would blind the rule to compromised workload service accounts.

Response and remediation

  • If unauthorized, revoke the minted token and the requesting identity’s credentials, and review the RBAC that permitted token creation.
  • Audit actions performed with the target service account’s identity after the request.
  • Collect kube-audit and identity artifacts per incident response procedures.

Setup

edit

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). TokenRequest is a mutating create recorded in both categories with the same auditID, so clusters that enable both categories may generate two alerts per request.

Rule query

edit
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:"serviceaccounts" and
    azure.platformlogs.properties.log.objectRef.subresource:"token" and
    azure.platformlogs.properties.log.verb:"create" and
    azure.platformlogs.properties.log.responseStatus.code:("200" or "201") 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

« Azure AKS Secret get or list with Suspicious User Agent Azure AKS Suspicious Self-Subject Review by Service Account or Node Identity »