Azure AKS Attempted User Exec into Pod

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

Azure AKS Attempted User Exec into Pod

edit

Detects an AKS (Azure Kubernetes Service) identity establishing an exec session into a pod. Interactive command execution inside a workload via kubectl exec is a common post-compromise technique used to access secrets, run tooling, and expand access from a foothold container. Node, control-plane, and kube-system service account identities are excluded, so workload service accounts and users, the identities an adversary is most likely to abuse, remain in scope.

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

Version: 1

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Azure AKS Attempted User Exec into Pod

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 alerts on a pods/exec request by an identity that is not node, control-plane, or kube-system infrastructure. Exec into a pod grants an interactive shell inside the workload, which adversaries use to read mounted secrets, pivot, and stage tooling.

Possible investigation steps

  • Review the acting identity in azure.platformlogs.properties.log.user.username and its groups in azure.platformlogs.properties.log.user.groups, and the target pod in azure.platformlogs.properties.log.objectRef.name / azure.platformlogs.properties.log.objectRef.namespace.
  • Determine whether the target pod holds sensitive data, cluster credentials, or a mounted service account token.
  • Inspect the exec request path and command context in azure.platformlogs.properties.log.requestURI and the client in azure.platformlogs.properties.log.userAgent (interactive kubectl vs a scripted client).
  • Evaluate the source in azure.platformlogs.properties.log.sourceIPs. Pivot on it for related API activity, secret reads, or RBAC changes from the same identity.

False positive analysis

  • Approved admin debugging; exclude stable operator or break-glass identities after review.
  • CI/CD or platform tooling that execs into workloads may match; exclude verified service accounts and namespaces.

Response and remediation

  • If unauthorized, revoke the identity’s tokens and kubeconfig and terminate the exec session.
  • Inspect the target pod for tampering, dropped tooling, or accessed secrets, and rotate any credentials it exposed.
  • 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:"pods" and azure.platformlogs.properties.log.objectRef.subresource:"exec" and
  azure.platformlogs.properties.log.verb:("create" or "get") 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