Challenge 08 • Container Escape Detection

Understanding Container Escapes

Container escapes occur when an attacker breaks out of container isolation to access the host system. This is one of the most critical security threats in containerized environments, potentially compromising entire Kubernetes clusters.

⚠️ Why Container Escapes are Critical

Complete Host Access: Successful escape grants root access to underlying host OS

Cluster Compromise: Access to host allows lateral movement to other containers/nodes

Data Breach: Can access secrets, credentials, and data from all containers on host

Persistence: Attacker can install backdoors on host that survive container restarts

🐳 Container Isolation Mechanisms

Namespaces: Process, network, mount, UTS, IPC, user isolation

Cgroups: Resource limits (CPU, memory, I/O)

Capabilities: Fine-grained privilege control (replaces root/non-root)

Seccomp: System call filtering

AppArmor/SELinux: Mandatory access control

🚨 Privileged Containers

What it means: docker run --privileged or securityContext.privileged: true

Grants: All Linux capabilities, access to all devices, disables AppArmor/SELinux

Risk: Container has same permissions as host root - trivial to escape

Legitimate Uses: Docker-in-Docker, system monitoring tools (very rare)

Common Container Escape Techniques

🚨 Privileged Container Escape

Access /dev/sda1 (host disk)
Mount host filesystem
Chroot into host root
Execute commands on host
Nearly guaranteed escape vector

🔓 Capabilities Abuse

CAP_SYS_ADMIN - mount, kernel module loading
CAP_SYS_PTRACE - process injection
CAP_DAC_OVERRIDE - bypass file permissions
CAP_SYS_MODULE - load malicious kernel modules

📂 Volume Mount Abuse

Mount /var/run/docker.sock
Mount host /etc or /root directories
Access container runtime socket
Start privileged containers from inside

🐛 Kernel Exploits

Dirty Cow (CVE-2016-5195)
runc vulnerabilities (CVE-2019-5736)
Exploit shared kernel from container
Gain root on host via kernel vuln

Investigation Commands

# Check if container is privileged
docker inspect container_id | grep -i privileged

# View container capabilities
docker inspect container_id | grep -i cap

# Check volume mounts
docker inspect container_id | grep -A 10 Mounts

# Kubernetes security context
kubectl get pod pod_name -o jsonpath='{.spec.containers[*].securityContext}'

# Check for host process namespace
docker inspect container_id | grep -i "PidMode"

🚨 Critical Defense: NEVER run containers as privileged unless absolutely necessary. Drop all capabilities by default, use read-only root filesystems, enable seccomp/AppArmor, and implement Pod Security Standards/Policies.

Evidence Review

🐳 docker logs web-app-7f9c4b Click lines to tag as evidence

🔍 docker inspect web-app-7f9c4b

☸️ kubectl describe pod web-app-7f9c4b

📄 /var/log/syslog (Host)

📌 Evidence Locker

No evidence tagged yet. Click log lines to add them.

Interactive Terminal

Run commands to analyze container security. Available: docker, kubectl, cat, grep, clear, help

analyst@blueteam:~$ Terminal ready. Type 'help' for available commands.

analyst@blueteam:~$

Investigation Tasks

Tasks Completed: 0 / 12

Task 1 — Container ID (short form)

✓ Correct Answer:

7f9c4b

The container ID short form is "7f9c4b" as shown in all logs and commands. Full ID: 7f9c4b8a12d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7.

Task 2 — Is Container Privileged? (yes/no)

✓ Correct Answer:

yes

docker inspect shows "Privileged": true - This is CRITICAL. Privileged containers can access all host devices and easily escape to host system.

Task 3 — Host Device Accessed

✓ Correct Answer:

/dev/sda1

Docker logs show: "Accessing /dev/sda1" - The host's root partition device. Privileged containers can access this to mount the entire host filesystem.

Task 4 — Host Mount Point Used

✓ Correct Answer:

/hostfs

Logs show: "mkdir /hostfs && mount /dev/sda1 /hostfs" - Attacker created /hostfs directory inside container and mounted host root partition there.

Task 5 — Dangerous Linux Capability Granted

✓ Correct Answer:

CAP_SYS_ADMIN

docker inspect shows CAP_SYS_ADMIN in CapAdd. This capability allows mounting filesystems, loading kernel modules, and performing privileged operations - major escape vector.

Task 6 — Host File Accessed

✓ Correct Answer:

/etc/shadow

Docker logs show: "cat /hostfs/etc/shadow" - After mounting host FS, attacker read host's password hash file. Proof of successful container escape.

Task 7 — Cron Job Installed On Host

✓ Correct Answer:

persistence

Syslog shows: "New file: /etc/cron.d/persistence" - Attacker installed cron job on HOST for persistence. This survives container restarts and provides ongoing access.

Task 8 — Namespace Escape Technique

✓ Correct Answer:

chroot

Docker logs show: "chroot /hostfs /bin/bash" - After mounting host FS, attacker used chroot to change root directory to host filesystem, effectively escaping container.

Task 9 — Kubernetes Namespace

✓ Correct Answer:

production

kubectl describe shows Namespace: production - The container was running in production namespace, making this breach even more critical.

Task 10 — Security Context runAsUser

✓ Correct Answer:

kubectl shows runAsUser: 0 - Container runs as UID 0 (root). Combined with privileged mode, this is extremely dangerous configuration.

Task 11 — Backdoor Port Opened on Host

✓ Correct Answer:

4444

Syslog shows: "nc -lvp 4444" executed on host - Netcat listener on port 4444 providing backdoor shell access to host system from outside container.

Task 12 — MITRE ATT&CK Technique ID

✓ Correct Answer:

T1611

T1611 = Escape to Host. This technique involves breaking out of container isolation to gain access to the underlying host operating system, exactly what occurred here.

XP: 0 / 1200

Attack Analysis & Incident Summary

This section auto-fills once all tasks are completed correctly.

Container Escape Chain

Complete all tasks to reveal the container escape chain.

Incident Summary

Threat type: —
Container ID: —
Privileged mode: —
Capability exploited: —
Host device accessed: —
Escape technique: —
Host file compromised: —
Persistence mechanism: —
Backdoor port: —
K8s namespace: —
Run as user: — (root)
MITRE ATT&CK: —

Recommended Remediation

Immediate: TERMINATE CONTAINER, isolate host node, kill backdoor processes (nc on port 4444), remove cron job
Forensics: Full host compromise - treat as breached, audit all containers on node, check for lateral movement
Recovery: Rebuild host from known good state, rotate ALL credentials/secrets, review container images for backdoors
Prevention: NEVER use privileged: true, implement Pod Security Standards, drop all capabilities, use read-only root FS, enable seccomp strict

Why This Attack Succeeded

The container escape succeeded because:
1. Container ran in privileged mode (privileged: true) - grants all host capabilities
2. CAP_SYS_ADMIN capability allowed mounting host filesystem
3. Running as UID 0 (root) instead of non-root user
4. No Pod Security Policy/Standards enforcement
5. No runtime security monitoring (Falco, Sysdig)
6. No read-only root filesystem restriction

Container Security Best Practices Violated

❌ Privileged mode enabled
❌ Dangerous capabilities added (CAP_SYS_ADMIN)
❌ Running as root (UID 0)
❌ No seccomp profile applied
❌ No AppArmor/SELinux enforcement
❌ Writable root filesystem
❌ No resource limits set
❌ Production namespace without proper PSP/PSS

🛡️ Challenge 08 • Container Escape Detection

Mission Brief

Available Artifacts

Learning Objectives

Understanding Container Escapes

⚠️ Why Container Escapes are Critical

🐳 Container Isolation Mechanisms

🚨 Privileged Containers

Common Container Escape Techniques

🚨 Privileged Container Escape

🔓 Capabilities Abuse

📂 Volume Mount Abuse

🐛 Kernel Exploits

Investigation Commands

Evidence Review

Interactive Terminal

Investigation Tasks

Attack Analysis & Incident Summary

Container Escape Chain

Incident Summary

Recommended Remediation

Why This Attack Succeeded

Container Security Best Practices Violated