Container Escape Attempt

How the attack works

An attacker who has code execution inside a container looks for ways to reach the host it runs on. They may access the Docker socket to issue commands to the container engine itself, use nsenter to enter the host's process or network namespace, mount the host filesystem into the container to read or write files outside its intended scope, or manipulate /proc entries that expose or affect the host kernel. Any of these can let a process step outside its container boundary and act with host-level access.

Netzilo detection

Why it matters

A successful escape gives the attacker control over the host machine, not just the container, which typically means access to other containers, host data, credentials, and the ability to pivot further into the environment.

What you can do

• →Run containers without the Docker socket mounted inside them unless a specific workload genuinely needs it.
• →Restrict container capabilities and disable privileged mode by default; require explicit justification for exceptions.
• →Review any process inside a container that calls nsenter, mounts host paths, or writes to /proc, and confirm it's a known management or orchestration tool.
• →Apply namespace and cgroup isolation consistently, and keep container runtimes patched against known escape vulnerabilities.

Known benign look-alikes

• Legitimate Docker management operations accessing the Docker socket
• Container orchestration tools that use nsenter for container inspection

References

• https://attack.mitre.org/techniques/T1611/
• https://arxiv.org/abs/2403.04783

Related threats