Skip to content

CHAIN-006 — AKS public endpoint privileged containers to takeover

Summary

Severity: Critical · Likelihood: Medium · Logic: ALL

Why this chain matters

An AKS cluster has its API server reachable over the internet, pods are permitted to run as privileged or with hostPath mounts, and the cluster's managed identity can fetch secrets from a Key Vault whose soft-delete/purge protection is disabled. An attacker who hijacks the kubeconfig (or exploits an unauthenticated API server endpoint) escapes a container, accesses the node filesystem, pulls the cluster identity token, and drains the Key Vault - then purges the vault to destroy forensic evidence.

Component rules

This chain fires when its trigger conditions are met by the following rules. Click any rule to see its detection logic and compliance mappings.

Rule ID Role
zt_wl_003 Trigger
zt_wl_007 Trigger
zt_data_004 Trigger

Attack walkthrough

Step 1 — Reach the AKS API server from the internet and exploit weak authentication or a known CVE.

Actor: External attacker
MITRE ATT&CK: T1190
Enabled by: zt_wl_003

Public FQDN *.hcp.{region}.azmk8s.io reachable from anywhere; combined with aged kubeconfig or misconfigured OIDC, the attacker obtains cluster-admin.

Attacker gain: kubectl access to the cluster.

Step 2 — Deploy a privileged pod with hostPath=/ and run as root to break out to the node.

Actor: Attacker with kubectl
MITRE ATT&CK: T1611
Enabled by: zt_wl_007

kubectl apply of a pod spec with securityContext.privileged=true and volumes[].hostPath.path=/ - PodSecurity admission is set to baseline/privileged.

Attacker gain: Root shell on the underlying AKS node.

Step 3 — Query IMDS from the node and obtain the kubelet's managed identity token.

Actor: Attacker on node
MITRE ATT&CK: T1552.005
Enabled by: zt_wl_007

curl http://169.254.169.254/metadata/identity/oauth2/token?resource=https://vault.azure.net - node identity has Key Vault Reader or Secrets User.

Attacker gain: Bearer token for Azure Key Vault scoped to the cluster identity.

Step 4 — Exfiltrate every secret from the associated Key Vault.

Actor: Attacker with KV token
MITRE ATT&CK: T1555.006
Enabled by: zt_data_004

az keyvault secret list + per-secret show using the managed identity token; database credentials, API keys, signing certs all disclosed.

Attacker gain: Downstream credential reuse across SQL, service principals, and partner APIs.

Step 5 — Purge the Key Vault to destroy forensic evidence.

Actor: Attacker with KV admin
MITRE ATT&CK: T1485
Enabled by: zt_data_004

Because soft-delete / purge protection is disabled, az keyvault delete followed by az keyvault purge succeeds. Secret version history is unrecoverable.

Attacker gain: Destruction of audit trail and rotation baseline, impeding recovery.

Blast radius

Initial access Public AKS API server.
Lateral movement Container → privileged pod → node → Azure IMDS → Key Vault.
Max privilege cluster-admin on AKS + Key Vault secret reader/purger on the associated vault.
Data at risk Cluster workloads, Node filesystems, All Key Vault secrets, Downstream services whose credentials were in the vault
Services at risk AKS, Key Vault, Any service whose credentials were in the vault
Estimated scope Cluster + associated vault + every downstream service whose creds were in the vault

How the logic works

The chain fires only when every rule above has at least one finding in the current scan. Missing any one rule breaks the chain — so remediating any single step disrupts the attack path.