Courses Runtime & eBPF securityContainer escapes & IR

Detecting escapes at runtime

The behavioral signatures and fast containment.

Expert30 min · lesson 14 of 15

Prevention removes the known enablers, but you still need to detect the escape attempts that get through — a novel runtime bug, a capability you had to grant, a zero-day. Escapes are not invisible: the techniques generate distinctive kernel activity that runtime tools can catch.

The behavioral signatures of an escape

Escape attempts produce tell-tale syscalls and events: mount operations inside a container, writes to host-mounted paths, access to the container runtime socket, ptrace against other processes, unexpected use of CAP_SYS_ADMIN, spawning a process on the host PID namespace, or a process suddenly running outside its expected cgroup. Falco and Tetragon ship rules for many of these, and you can add detections tuned to your environment — for example, any exec whose parent is not in the workload’s expected process tree, or any write to /proc paths associated with the release_agent escape.

detect escape-adjacent behavior

# Falco-style detections for escape techniques:
- rule: Mount launched in container
  condition: spawned_process and container and proc.name = mount
  output: "Mount in container (pod=%k8s.pod.name cmd=%proc.cmdline)"
  priority: WARNING
 
- rule: Write to host-mounted path
  condition: open_write and container and fd.name startswith /host
  output: "Write to host mount (pod=%k8s.pod.name file=%fd.name)"
  priority: CRITICAL
 
- rule: Container runtime socket access
  condition: open_read and container and fd.name in (/var/run/docker.sock, /run/containerd/containerd.sock)
  output: "Runtime socket access from container (pod=%k8s.pod.name)"
  priority: CRITICAL

Detect, then contain fast

Because an escape means an attacker is moving toward the host, these are the detections that most justify automated or near-immediate response: on a high-confidence escape signal, isolate the pod with a deny-all NetworkPolicy, cordon the node so nothing new schedules there, and preserve state before eviction. Pair detection with the enforcement primitives from earlier — a Tetragon Sigkill on runtime-socket access, or a BPF-LSM deny on the mount — so the clearest escape attempts are stopped in-kernel, not merely logged. Layer this on top of prevention: admission policy removes the easy escapes, and runtime detection catches the ones that remain.

Catching an escape in progress

1escape technique

mount, socket, host write, ptrace

2kernel event

distinctive syscall pattern

3runtime rule fires

Falco/Tetragon, high priority

4contain

isolate pod, cordon node, preserve

Escapes generate detectable kernel activity. Watch for it, and treat an escape signal as one of the few clear cases for fast automated containment.

An escape signal is a drop-everything event

Runtime-socket access, a mount inside a container, or a write to a host path is rarely benign and means an attacker may be one step from the host. Route these as CRITICAL with immediate paging and, where confidence is high, automated isolation — treating them like ordinary alerts gives the attacker the minutes they need to reach the node.

Container escape pathsRuntime incident response