Azure AKS Kubelet Proxy to Command Execution Endpoint

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

Azure AKS Kubelet Proxy to Command Execution Endpoint

edit

Detects use of the AKS (Azure Kubernetes Service) API server nodes/proxy subresource to reach a node’s Kubelet command-execution endpoints (run, exec, attach, portforward, cri). Unlike benign monitoring that scrapes /metrics and /stats, a request to these endpoints executes commands inside a pod on the node, the core of the kubeletctl and Peirates lateral-movement technique. Even a GET to /exec is command execution because the Kubelet maps the WebSocket upgrade handshake to the RBAC get verb, so nodes/proxy GET is sufficient for remote code execution.

Rule type: query

Rule indices:

  • logs-azure.platformlogs-*

Severity: high

Risk score: 73

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: Execution
  • Tactic: Lateral Movement
  • Resources: Investigation Guide

Version: 1

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Azure AKS Kubelet Proxy to Command Execution Endpoint

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 keys on the Kubelet endpoint in azure.platformlogs.properties.log.requestURI: /proxy/run, /proxy/exec, /proxy/attach, /proxy/portforward, and /proxy/cri execute commands in a pod on the target node, whereas monitoring uses /metrics and /stats. Any hit here is high-signal command execution regardless of the acting identity, including a stolen monitoring service-account token.

Possible investigation steps

  • Confirm the endpoint and target in azure.platformlogs.properties.log.requestURI (the path encodes /<endpoint>/<namespace>/<pod>/<container>) and the acting identity in azure.platformlogs.properties.log.user.username.
  • Evaluate azure.platformlogs.properties.log.sourceIPs. This is an array; for an externally operated attack the first element is the operator’s real client IP and the trailing entry is the internal API-server/konnectivity hop (172.31.x). A first entry that is not the cluster’s own egress is a strong signal.
  • Determine what the target pod runs and what secrets or tokens it exposes, and whether the identity should reach the Kubelet at all.
  • Correlate with prior recon (/proxy/pods, /proxy/runningpods) and follow-on RBAC changes, secret reads, or token requests from the same identity.

False positive analysis

  • Direct use of Kubelet exec endpoints via nodes/proxy is uncommon; validate any administrative debugging tool that proxies exec and exclude verified operators.

Response and remediation

  • Treat as active command execution on a node. Revoke the acting identity’s tokens, isolate the affected node and pods, and rotate credentials reachable from them.
  • Review the RBAC that granted nodes/proxy and remove it from workload identities that do not require it.
  • Note that direct Kubelet access on port 10250 bypasses the API server and is not in kube-audit; a confirmed proxy exec may indicate broader Kubelet access.
  • Collect kube-audit and identity artifacts per incident response procedures.

Setup

edit

The Azure Fleet integration collecting AKS diagnostic logs with the kube-audit category forwarded through Event Hub into the azure.platformlogs data stream is required for this rule.

Rule query

edit
data_stream.dataset:azure.platformlogs and
  event.action:"Microsoft.ContainerService/managedClusters/diagnosticLogs/Read" and
  azure.platformlogs.category:"kube-audit" and
  azure.platformlogs.properties.log.objectRef.resource:"nodes" and
  azure.platformlogs.properties.log.objectRef.subresource:"proxy" and
  azure.platformlogs.properties.log.requestURI:(
    */proxy/run/* or */proxy/exec* or */proxy/attach* or
    */proxy/portforward* or */proxy/portForward* or */proxy/cri/*
  ) and
  not azure.platformlogs.properties.log.user.username:(
    system\:node\:* or "aksService" or "hcpService" or "readinessChecker"
  )

Framework: MITRE ATT&CKTM