GTFOBins Cheat Sheet

GTFOBins is a curated database of standard Unix binaries — the kind already installed on nearly every system — documenting what each one can be abused to do when it's reachable through SUID, sudo, or a Linux capability. It's a lookup reference, not a tool you run: the skill is knowing which binary you have access to, then checking what it's actually capable of.

Red Team / Offensive Use

This is the resource the script privesc checklist points to constantly — every time sudo -l or a SUID search turns up a binary, GTFOBins answers "can this get me a shell or read/write access I shouldn't have." It shows up in almost every CTF and a meaningful share of real internal pentests, because system administrators granting sudo access to a specific binary for a legitimate, narrow reason is extremely common, and most people don't realize how many ordinary binaries were never designed to be handed elevated access safely.

Established Cheatsheet

gtfobins.github.io — the project itself; search by binary name, filter by function (Shell, SUID, Sudo, File read, File write, Capabilities, and more).

PWNMI's Top 6 Use Cases

• Search GTFOBins for any binary sudo -l lets you run — the single highest-value check on this whole list; a surprising number of sudo grants for "just this one utility" turn out to have a documented shell escape
• Filter by "Sudo" specifically when you have a confirmed sudo entry, rather than reading a binary's entire page — the site's filter chips narrow straight to the relevant function
• Example: sudo find . -exec /bin/sh \; -quit — find's -exec flag runs an arbitrary command with find's own privileges, one of the most commonly cited GTFOBins entries because find shows up in so many sudo grants for legitimate reasons
• Example: sudo vim -c ':!/bin/sh' — many text editors can shell out to run a command, and if they're run with elevated privileges via sudo, that shell inherits them
• Filter by "SUID" when you've found a binary with the SUID bit set via find / -perm -4000 — a different exploitation path than the sudo case, since you're relying on the binary's owner privilege, not an explicit grant
• Check the "Limited SUID" tag specifically for binaries that need extra conditions (a specific argument, an environment variable) to actually work as SUID — worth reading the exact notes rather than assuming every technique on a binary's page applies unconditionally

Next step

For the full checklist this fits into, see Script Privilege Escalation or the conceptual overview at Privilege Escalation Fundamentals. For the Windows equivalent — trusted binaries abused for execution and evasion rather than privesc specifically — see LOLBAS.