Privileged pod escape → cluster admin
GenericWrite on a Deployment in the kube-system namespace lets you launch a privileged pod; the pod mounts the host filesystem and steals the kubeconfig of cluster-admin.
§ Context
Assumed environment: attacker has create/update Deployment rights in kube-system (or any namespace whose pods get scheduled onto a control-plane node).
§ Steps
- 01kubectl with cluster-adminInitial AccessT1078— Valid Accounts
- 02Compromised K8s principalInitial AccessT1078— Valid Accounts
- 03Read /etc/kubernetes/admin.conf from hostCredential AccessT1552— Unsecured Credentials
- 04RBAC audit (kubectl auth can-i)DiscoveryK-RBAC-AUDIT— K8s RBAC Audit (rakkess / kubectl-who-can)
- 05Create privileged pod (host filesystem mount)Privilege EscalationK-PRIV-CONTAINER— Privileged Container Escape
- 06Pod schedules on control-plane nodePrivilege EscalationK-HOSTPATH-MOUNT— hostPath Volume Mount
- 07Backdoor DaemonSet / admission webhookPersistenceK-ADMISSION-WEBHOOK— Malicious Admission Webhook
§ References
- T1078Valid Accounts
- T1552Unsecured Credentials
§ Frequently asked
- What is the "Privileged pod escape → cluster admin" attack path?
- GenericWrite on a Deployment in the kube-system namespace lets you launch a privileged pod; the pod mounts the host filesystem and steals the kubeconfig of cluster-admin. It chains 7 steps drawn from real-world offensive-security techniques.
- What starting position does this attack require?
- The first step is kubectl with cluster-admin (T1078) — a initial access primitive. Assumed environment: attacker has create/update Deployment rights in kube-system (or any namespace whose pods get scheduled onto a control-plane node).
- What is the final impact of this kill-chain?
- The final step lands on Backdoor DaemonSet / admission webhook (K-ADMISSION-WEBHOOK), which falls under Persistence. From here, an operator typically pivots into post-exploitation or maintains persistence.
- How can defenders detect or prevent this attack?
- Detection and prevention vary per step. Refer to each linked MITRE ATT&CK entry under "References" — every technique on that page lists defensive controls, detection telemetry, and known threat-actor usage.
§ Related dossiers
- Shared techniques3
Exposed etcd → cluster-wide secret raid
etcd is reachable without mTLS — read every Secret in the cluster including service-account tokens that grant cluster-admin.
- Shared techniques2
Dev workstation → cloud backup keys → encrypted vault store (LastPass 2022)
Attacker compromised a single LastPass DevOps engineer's home machine via outdated Plex Media Server, harvested AWS keys for the encrypted-vault backup bucket, exfiltrated production vault data.
- Shared techniques2
F5 BIG-IP iControl auth bypass (CVE-2022-1388) → root on LB
Connection-header smuggle bypasses iControl REST auth, command-injection RCE as root. Load balancers see all traffic — recover TLS keys, session cookies, internal SSO config.
- Shared techniques2
Spectre-class side-channel → cross-tenant memory leak
Pre-mitigation cloud VM lets a co-tenant trigger speculative loads from kernel / sibling-VM memory. Cache-side-channel measurements recover sensitive data, including TLS keys + cloud creds.
- Shared techniques2
Exported ContentProvider → private data leak
App exports a ContentProvider for legitimate inter-app integration but forgets to enforce grantUri / signature permissions — a rogue installed app reads private auth tokens.
- Shared techniques2
TCC bypass → access Photos / Camera without consent
Inject into a process that already has Full Disk Access (e.g. backup utility, Terminal). Inherited TCC entitlement lets the attacker code read TCC-gated data — Photos, iMessage DB, Documents.