Container Escape Happened, Here Is How to Detect It in Falco and Respond
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
A container escape gives an attacker a shell on the underlying Kubernetes node, access to every other container on that node, the node's kubelet credentials, the ability to read the node's service account tokens, and in many clusters, a path to cluster-admin. The escape itself generates specific system call patterns, file access events, and Kubernetes audit entries. Knowing what those signals look like before an incident makes the difference between detecting an escape in minutes and discovering it days later when your cloud provider sends an abuse notice.
Escape Technique 1: Privileged Container Abuse
A container running with securityContext.privileged: true has access to all Linux capabilities and can mount any host filesystem path. The escape is trivially simple: mount the host root filesystem and write a cron job or SSH key.
Falco rule for privileged container filesystem mounts:
- rule: Privileged Container Mounts Host Filesystem
desc: A privileged container is mounting the host root filesystem
condition: >
spawned_process and container and
proc.name in (mount, nsenter) and
container.privileged = true
output: >
Privileged container mounting host filesystem
(user=%user.name command=%proc.cmdline container=%container.name
image=%container.image.repository)
priority: CRITICAL
tags: [container, escape, mitre_privilege_escalation]
What it looks like on the node (EDR): Look for mount syscalls from container processes followed by file writes outside /proc/self/root. In CrowdStrike, a process tree showing runc → sh → mount /dev/sda1 /mnt is a strong indicator.
In the Kubernetes audit log: If an attacker uses kubectl exec to access a privileged container, you will see a create event in the audit log for pods/exec with the target pod name and namespace. Alert on exec into any pod where the pod spec includes privileged: true.
Escape Technique 2: Host Path Volume Mounts
Pods with hostPath volume mounts that include sensitive directories (/etc, /var/run/docker.sock, /proc) have direct access to host resources without requiring privileged mode.
The Docker socket escape: If /var/run/docker.sock is mounted into a container, the container can run Docker commands as root on the host. This is a complete escape: docker run --rm -it -v /:/host ubuntu chroot /host sh gives a root shell on the host.
Falco rule for Docker socket access from containers:
- rule: Container Accessing Docker Socket
desc: A container is accessing the Docker socket
condition: >
open_write and fd.name = /var/run/docker.sock
and container and not proc.name in (dockerd, containerd)
output: >
Container accessing Docker socket
(user=%user.name command=%proc.cmdline
container=%container.name image=%container.image.repository)
priority: CRITICAL
Kubernetes admission controller prevention: Use OPA Gatekeeper or Kyverno to block pods with hostPath volumes pointing to sensitive paths. But for detection when prevention fails:
// Azure Sentinel, pods with sensitive hostPath mounts created recently
AzureDiagnostics
| where Category == "kube-audit"
| where log_s contains "hostPath"
| where log_s contains "/var/run/docker.sock"
or log_s contains "/etc/kubernetes"
or log_s contains "/proc"
| project TimeGenerated, log_s
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Escape Technique 3: procfs and /proc/sysrq-trigger
The /proc filesystem on the host is partially accessible from within containers, depending on the container runtime configuration. Two specific escape paths:
/proc/{PID}/mem scraping: A container with hostPID: true can see and read the memory of all processes on the node, including other containers' processes. This is the exact technique used by the TanStack payload to steal GitHub Actions OIDC tokens from runner memory.
/proc/sysrq-trigger: Writing to this file triggers kernel actions. Writing 'b' to it reboots the host. An attacker who has written to a hostPath-mounted /proc on the host can trigger arbitrary sysrq actions.
Falco rule for /proc/mem access from containers:
- rule: Container Reading Host Process Memory
desc: A container is reading /proc/<pid>/mem of another process
condition: >
open_read and container and
fd.name glob /proc/*/mem and
not proc.name in (ps, top, prometheus)
output: >
Container reading process memory
(user=%user.name command=%proc.cmdline
pid=%proc.pid fd=%fd.name container=%container.name)
priority: CRITICAL
tags: [container, escape, credential_theft]
Detection on the node: In your EDR, alert on open() syscalls to /proc/[0-9]*/mem from processes in the container namespace that are not the container's own PID.
Escape Technique 4: runc Vulnerabilities
CVE-2019-5736 (runc < 1.0-rc6) and CVE-2024-21626 (runc < 1.1.12) both allowed container escape by exploiting the container runtime itself. CVE-2024-21626 was particularly dangerous, it required only a malicious container image to overwrite the runc binary on the host.
Detection signals for runc exploitation:
- The runc binary is modified: its hash changes, or it is replaced with a different binary
- Unexpected writes to /proc/self/exe from within a container process
- A container process successfully executes code outside its namespace
Falco rule for runc binary modification:
- rule: Container Runtime Binary Modified
desc: The runc or containerd-shim binary has been modified
condition: >
(open_write or rename) and
fd.name in (/usr/bin/runc, /usr/local/bin/runc,
/usr/bin/containerd-shim,
/run/containerd/runc)
and not proc.name in (apt, dpkg, rpm, yum, dnf)
output: >
Container runtime binary modified
(user=%user.name command=%proc.cmdline fd=%fd.name)
priority: CRITICAL
Version check: On every node, verify: runc --version. Nodes running runc 1.1.11 or earlier are vulnerable to CVE-2024-21626. Patch via your node image update process.
Incident Response: Confirmed Container Escape
When Falco or your EDR confirms a container escape, execute in this order:
1. Isolate the node immediately. Use kubectl cordon NODE-NAME (prevents new pods from being scheduled) then kubectl drain NODE-NAME --ignore-daemonsets --delete-emptydir-data (evicts existing pods). Do not delete the node yet, you need it for forensics.
2. Isolate the escaping container. Use your CNI plugin to apply a NetworkPolicy that blocks all egress from the pod:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: isolate-compromised-pod
spec:
podSelector:
matchLabels:
app: COMPROMISED-APP
policyTypes: [Egress]
egress: [] # No egress allowed
3. Assess what the escape accessed on the node. Check: /etc/kubernetes/pki (cluster CA and node certificates), /var/lib/kubelet/config.yaml (kubelet credentials), service account tokens at /var/run/secrets/kubernetes.io/serviceaccount/ on any other containers that were running on the node, and /root/.kube/config if the node runs kubectl.
4. Rotate compromised node credentials. Rotate the node's kubelet client certificate by deleting and re-registering the node. Rotate any service account tokens that were accessible on the node.
5. Preserve forensic evidence before node termination. Capture a memory dump if your tooling supports it, archive Falco logs, copy the audit log slice for the incident window, and snapshot the node's EBS volume before terminating it.
The bottom line
Container escapes are detectable in real time with Falco, the system call patterns for each technique are distinct and well-understood. The gap in most environments is not Falco rules, it is the response workflow: who gets paged when Falco fires, what they do in the first 10 minutes, and how they isolate the compromised node without taking down dependent workloads. Build and test that workflow before you need it.
Frequently asked questions
How do I know if a container escape has already occurred in my cluster?
Check your Falco logs (or your node's syslog if Falco was not running) for the event patterns described above. Check the Kubernetes audit log for exec events into privileged pods and for unexpected service account token usage. Check CloudTrail or your cloud provider's audit log for API calls made from node instance profiles outside of normal deployment activity.
Is Falco the only way to detect container escapes?
No. EDR agents running on the underlying nodes (not inside containers) can detect container escape attempts via syscall monitoring, CrowdStrike Falcon, SentinelOne, and Wazuh all support this. Kubernetes audit logs catch the API-level indicators. The advantage of Falco is that it is container-aware and can correlate syscalls with container identity.
What Kubernetes admission controller should I use to prevent privileged containers?
Kubernetes Pod Security Standards (the built-in replacement for PodSecurityPolicy) with the restricted profile blocks privileged containers, hostPID, hostPath volumes to sensitive paths, and most other escape vectors. Apply it at the namespace level: kubectl label namespace NAMESPACE pod-security.kubernetes.io/enforce=restricted
Does Google Autopilot or AWS Fargate prevent container escapes?
Managed node services reduce the escape surface by isolating workloads at the VM level and preventing access to the underlying node. AWS Fargate runs each task in its own microVM (Firecracker), making escape significantly harder, a container escape would require a Firecracker hypervisor vulnerability, which is a substantially different threat model. The tradeoff is reduced visibility into node-level behavior.
How do I test my Falco rules without waiting for a real incident?
Use Falco's built-in test capabilities: falco --list lists all loaded rules. For live testing, deploy a test container that triggers specific Falco rules in a non-production namespace: a container that runs nsenter, mounts /proc, or accesses /var/run/docker.sock will trigger the rules in this guide. Verify the alerts reach your SIEM before relying on the rules in production.
How do I determine which other containers were at risk of credential theft after a confirmed container escape on a shared Kubernetes node?
Any container that was running on the same node at the time of the escape should be treated as potentially compromised. Retrieve the list using: kubectl get pods --all-namespaces --field-selector spec.nodeName=AFFECTED-NODE-NAME and note the pods that were running during the incident window from your container runtime logs or your monitoring platform's historical pod inventory. For each co-located pod, assess what credentials it held: check the pod spec for mounted Kubernetes secrets, projected service account tokens, and environment variables sourced from Secrets Manager. Any service account token mounted on a co-located pod was readable by a process with hostPID access to the node's process namespace. Treat those service accounts as compromised, rotate their tokens via kubectl delete secret {service-account-token-secret}, and audit recent API calls made by those service accounts in the Kubernetes audit log for the incident window.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.