Container security exploit chaining guide covering real-world Docker and Kubernetes attack paths. Explains how attackers chain container misconfigurations, ServiceAccount token theft, RBAC privilege escalation, privileged pods, hostPath mounts, Docker socket abuse, kubelet exposure, supply-chain attacks, and Linux kernel privilege-escalation bug…

container_security_exploit_chaining.md

Attack Chains: Step-by-Step Exploits (Containers + Kubernetes)

“In theory, theory and practice are the same. In production, attackers get a vote.”
These chains are realistic sequences attackers use. They’re written from a defender’s perspective: entry → escalation → persistence → impact → detection points.

---

Chain 1 — “The Docker Socket Is My Root Shell”

Theme: Mounting docker.sock (or other runtime socket) turns a container into a host admin.

Preconditions

• A container has access to /var/run/docker.sock (or a Docker TCP API), or similar privileged runtime API exposure.

Steps

1. Initial foothold in container

   • Attacker gets code execution (RCE), or shells in via weak creds, SSRF-to-metadata, leaked token, etc.

2. Discover the socket

   • Check for /var/run/docker.sock or environment hints.
   • If present, attacker can talk to Docker daemon.

3. Query Docker daemon

   • Enumerate images/containers/volumes.
   • Identify host mounts, privileged containers, secrets in env vars.

4. Start a new privileged container

   • Run a container with:
     • --privileged OR added capabilities
     • host mounts like -v /:/host
     • host PID/network if needed

5. Host takeover

   • chroot /host → attacker is effectively on the host filesystem.
   • Add SSH keys, modify systemd units, drop persistence.

6. Pivot

   • Harvest kubelet creds, cloud credentials, registry tokens from host.
   • Move laterally to other nodes / control plane.

Impact

• Full node compromise → cluster compromise → cloud account compromise (depending on IAM).

Detection signals (high value)

• Any container mounting runtime sockets
• Container spawning containers / creating privileged workloads
• Unexpected access to /var/run/docker.sock
• New container with host mounts or privileged flags

Prevent/mitigate

• Never mount runtime sockets into workloads
• Use admission policies to block hostPath on runtime sockets
• Least-priv runtime and separate build infrastructure

---

Chain 2 — “Privileged Pod + hostPath = Node Escape (No Kernel 0-day Needed)”

Theme: Kubernetes misconfig gives attacker node-level control without exploiting a CVE.

Preconditions

• Attacker can create pods (or modify workloads) with:
  • privileged: true OR dangerous caps
  • hostPath mounts OR host namespaces

Steps

1. Get a Kubernetes credential

   • Steal ServiceAccount token from a pod (/var/run/secrets/...).
   • Or find token in logs / env / CI artifacts.

2. Enumerate RBAC permissions

   • Identify ability to create pods / exec / patch deployments.

3. Create an “escape pod”

   • Pod spec includes:
     • securityContext.privileged: true
     • hostPath: / mounted at /host
     • (optional) hostPID: true to see host processes

4. Break out via host filesystem

   • chroot /host
   • Modify host binaries, cron jobs, systemd services.

5. Establish persistence

   • Drop a systemd unit or cron job on the node.
   • Add SSH keys if sshd exists.

6. Cluster expansion

   • Read kubelet config/kubeconfig on host.
   • Access container runtime and extract other pods’ secrets.

Impact

• Node compromise → secret harvesting → potential cluster-admin → cloud creds.

Detection signals

• Pod creation with privileged, hostPath, hostPID, hostNetwork
• Writes to /etc/systemd, /etc/cron*, /root/.ssh
• New DaemonSet with suspicious mounts

Prevent/mitigate

• Admission controls (OPA/Gatekeeper/Kyverno): block privileged + hostPath
• Pod Security Standards “restricted” baseline
• Minimize who can create/patch workloads

---

Chain 3 — “ServiceAccount Token Theft → RBAC Escalation → Cluster Admin”

Theme: Most real compromises are identity abuse, not container escapes.

Preconditions

• Tokens auto-mounted widely
• Workloads with over-permissive RBAC exist

Steps

1. Initial foothold

   • Attacker compromises one pod via app vuln or exposed endpoint.

2. Steal ServiceAccount token

   • Read token from the standard mount path.
   • Query API server using that token.

3. RBAC reconnaissance

   • List permissions: can it list secrets? create pods? patch roles?

4. Privilege escalation Common paths:

   • Secrets read → grab higher-priv tokens
   • Patch deployment in a privileged namespace → inject malicious container
   • Create RoleBinding/ClusterRoleBinding if allowed → self-grant admin
   • Impersonate if impersonate permissions exist

5. Establish control

   • Create a “controller” Deployment/DaemonSet for persistence.
   • Add backdoor RBAC binding.

6. Harvest everything

   • Cluster secrets, registry creds, cloud IAM creds, TLS keys.

Impact

• Total cluster compromise.

Detection signals

• Unusual API calls from a workload identity (especially listing secrets)
• New RoleBinding/ClusterRoleBinding events
• Deployment patches adding host mounts/privileged containers
• New service accounts created in system namespaces

Prevent/mitigate

• Disable auto-mount tokens by default; mount only where needed
• Use short-lived projected tokens + audience restrictions
• RBAC least privilege + continuous review
• API audit + alerting on RoleBinding/ClusterRoleBinding changes

---

Chain 4 — “Kubelet Exposure → Pod Secrets + Exec Everywhere”

Theme: Exposed kubelet APIs have historically been abused; misconfig is common.

Preconditions

• Kubelet read-only port exposed (legacy), or weak kubelet authn/authz settings
• Network access to node kubelet from attacker-controlled workload/network

Steps

1. Network discovery

   • Scan node IP ranges for kubelet ports.

2. Query kubelet endpoints

   • Enumerate running pods, container IDs, sometimes logs/metrics.

3. Extract sensitive data

   • Pull env vars, config, potentially tokens (depends on config/endpoints).

4. Remote exec (worst case)

   • If exec endpoints are reachable and auth is weak, execute commands in pods.

5. Token theft / lateral movement

   • Move to higher privilege pods (CI, ingress, controllers).

Impact

• Broad workload compromise without touching API server RBAC.

Detection signals

• Unexpected kubelet endpoint traffic (east-west)
• Exec activity spikes
• Access to kubelet from non-control-plane sources

Prevent/mitigate

• Lock down kubelet: proper authn/authz, disable insecure endpoints
• Node firewalling / network segmentation
• Restrict who can reach node ports

---

Chain 5 — “Supply Chain: Malicious Image → Cluster-wide Persistence”

Theme: The attacker doesn’t break in — they get deployed.

Preconditions

• Unsigned images allowed
• Mutable tags used (latest)
• Build pipeline or registry access weak

Steps

1. Compromise pipeline or registry

   • Steal registry creds from CI logs/secrets
   • Push a trojan image with same tag

2. Wait for pull

   • Auto-deploy pulls latest or auto-updates.

3. Run malicious init

   • Backdoor starts as PID 1 or sidecar.
   • Exfil tokens, probe metadata endpoints, scan internal network.

4. Escalate

   • Abuse RBAC via stolen token
   • Deploy privileged pods if possible

5. Persistence

   • Create a hidden Deployment/DaemonSet
   • Add cron-like behavior via Kubernetes Jobs

Impact

• Cluster compromise at scale (often silent).

Detection signals

• Image digest drift for same tag
• Workloads pulling unexpected registries
• New outbound connections from base images that shouldn’t talk externally

Prevent/mitigate

• Use pinned digests, not tags
• Enforce signing/provenance (policy + verification)
• SBOM + admission checks
• Lock down registry permissions

---

Chain 6 — “Kernel Priv-Esc (Dirty Pipe / Dirty COW style) → Host Escape”

Theme: Shared-kernel reality: if attacker can run code, kernel LPE can become node takeover.

Preconditions

• Attacker has code execution inside container
• Node kernel vulnerable and not patched
• Container not sufficiently constrained (still often workable)

Steps

1. Initial foothold

   • Obtain shell in container.

2. Kernel version check

   • Determine if vulnerable based on kernel build.

3. Exploit local privilege escalation

   • Gain elevated privileges on the host kernel context (depends on exploit + mitigations).

4. Post-exploit stabilization

   • Ensure persistence (systemd, cron, dropper).
   • Harvest kubelet / runtime access.

5. Cluster expansion

   • Use node position to steal secrets and pivot.

Impact

• Node → cluster compromise.

Detection signals

• Suspicious syscall patterns, exploit-like behavior
• Unexpected writes to sensitive host paths
• New privileged processes on node

Prevent/mitigate

• Patch kernels aggressively
• Strong seccomp profiles (reduce exploit primitives)
• Use user namespaces + drop capabilities
• Runtime detection (syscalls/process/file integrity)

---

Chain 7 — “Network Flatness → Lateral Movement → Crown Jewels”

Theme: Kubernetes networking is “easy mode” for attackers unless you segment.

Preconditions

• No NetworkPolicy
• Broad pod-to-pod reachability

Steps

1. Compromise a low-value pod
2. Scan internal services
   • Databases, metadata endpoints, admin panels, internal APIs
3. Exploit internal-only services
   • Weak auth because “it’s internal”
4. Steal creds / tokens
5. Pivot to high-value namespaces
   • CI/CD, ingress controllers, secrets managers
6. Exfiltrate
   • Data, credentials, signing keys

Impact

• “One pod” becomes “many services.”

Detection signals

• East-west scanning behavior
• Unusual DNS patterns / connection spikes
• New connections to DB/admin ports

Prevent/mitigate

• Default-deny NetworkPolicies + allowlists
• Segmentation by namespace/app identity
• Egress controls where possible

---

Interview-Grade Summary (How to Explain This Fast)

• Most common: token theft + RBAC abuse + privileged pod creation
• Most catastrophic misconfig: runtime socket exposure, privileged + hostPath, wildcard RBAC
• Most overlooked: supply chain (tags, unsigned images), flat networking, kubelet exposure
• Most “CVE-shaped” risk: shared kernel LPE + runtime escape bugs
• Best defenders do: prevention and runtime detection + API audit correlation

“The attacker doesn’t need your zero-day if you give them your ClusterRoleBinding.”

---

If you want, next I can add

• A MITRE ATT&CK mapping for each chain
• A detections checklist (Falco-style rules + API audit rules)
• A defense playbook (admission policies + RBAC guardrails + runtime baseline)