Shell Escape Privilege Escalation
This rule flags an AI agent that escapes a sandboxed or limited command environment using known 'shell escape' tricks (like typing a bang-command in vi, or spawning a shell from find or python), and then keeps operating with unrestricted shell access. It's the AI-agent equivalent of a classic GTFOBins privilege escalation trick.
How the attack works
An AI agent is given a restricted execution context, such as a wrapped shell or a limited tool interface. The agent runs a command known to break that restriction, for example invoking a pager or editor's shell-escape feature, using find with -exec /bin/sh, or launching python's pty.spawn. The rule then checks for a second, independent sign in the same session confirming the escape actually worked, such as a privilege wrapper (sudo/su) appearing in the process chain, a shell becoming interactive or preserving elevated privileges, or the agent running recon commands like id/whoami right after. Only exec activity tied to the exact same session and its child processes is considered, so unrelated processes on the same machine don't get mixed in.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 3f9c1e0a-7b42-4d6e-9c85-1a2f4b6d8e07
- Severity
- High
Why it matters
An agent that breaks out of its intended sandbox gains a full, less-restricted shell, which can let it read, modify or delete data and run commands well outside its intended permissions.
What you can do
- →Review any flagged session manually rather than assuming it's malicious - this rule reports for investigation, it doesn't block anything.
- →Restrict which binaries an AI agent's execution environment can invoke, especially editors, pagers, and tools known for shell-escape features (vi, less, man, find, awk, python, expect, script, nmap).
- →Avoid granting agents sudo/su access or SUID-preserving shells unless strictly required, and log/alert on any use of privilege wrappers in agent sessions.
- →If your CI or build pipeline legitimately uses shell-spawning patterns like find -exec /bin/sh or script -qc /bin/sh, document and baseline that usage so it can be distinguished from genuine escapes during review.
Known benign look-alikes
- Developer or operator deliberately taking a root shell on their own machine (sudo -s, sudo su, sudo -i) and then running id / whoami - this produces anchor plus privilege-wrapper corroboration and will be reported.
- Interactive editor or pager shell-out during normal work (:!bash from vim, !sh from less or man) while inspecting build output.
- Build, packaging or CI scripts that use find ... -exec /bin/sh -c ... or script -qc /bin/sh to provide a PTY to a non-interactive runner.
- Automation that legitimately uses python -c 'import pty; pty.spawn(...)' or expect/spawn to drive an interactive tool (ssh, passwd, telnet).
- Security research, GTFOBins study, CTF work, or an authorised pentest run by the user through the agent - the command text is identical to the attack.
- Container debugging where an entrypoint execs /bin/bash and a wrapper such as gosu or su-exec appears in the process chain.