LoFP LoFP / administrators routinely exec into pods for troubleshooting. baseline expected users and target pods, then exclude known break-glass identities.

Sample rules

GKE User Exec into Pod

Description

Detects the first occurrence of a non-system GKE identity establishing an exec session into a pod. kubectl exec enables interactive command execution inside workloads and is a common post-compromise technique to access secrets and expand access.

Detection logic

data_stream.dataset:gcp.audit and event.action:("io.k8s.core.v1.pods.exec.create" or "io.k8s.core.v1.pods.exec.get") and
not user.email:system\:*

Azure AKS Attempted User Exec into Pod

Description

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.

Detection logic

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\:*
  )