Linux Privilege Escalation Cheatsheet

The Golden Rule Before Any Privesc Attempt

Privilege escalation is the art of moving from a low-privileged user to a higher-privileged one after an initial foothold. It is a core part of authorized penetration testing, CTF challenges, and lab work, but it only ever applies to systems you own or have written permission to test.

In a real engagement, you usually begin with a limited shell obtained through a documented, in-scope vulnerability. Everything you do after that must stay inside the scope the client agreed to. Stop when you reach the level of access the test requires and document how you got there.

The method matters more than memorized commands. Enumerate systematically, look for misconfigurations, and reason about what each finding allows you to do.

hostname; id; uname -a
cat /etc/os-release
sudo -l 2>/dev/null; crontab -l 2>/dev/null

System and User Enumeration

Start by understanding who you are, where you are, and what the machine is running. Kernel version, operating system, and current privileges shape which attack paths exist at all.

Then map users, groups, and history. Shell history files often contain passwords, tokens, and commands the admin assumed were private. World-readable files in home directories are a classic source of credentials.

Look for writable paths, mounted drives, and running processes. A process running as root that reads user-controlled files is a lead worth investigating.

• •Users with login shells and their home directories
• •Shell history and config files for credentials
• •Writable files and directories reachable by your user
• •Running processes and the users they run as
• •Mounted filesystems and network shares

cat /etc/passwd | grep -E '/(bin|usr/sbin)/.*sh$'
ls -la /home/*/ 2>/dev/null
cat ~/.bash_history ~/.ssh/authorized_keys 2>/dev/null
ps aux | grep -v root
find / -writable -type f 2>/dev/null | grep -v -E '^(/proc|/sys|/dev)' | head -30

Permission Mistakes: SUID, sudo, and World-Writable Files

The SUID bit makes a program run with the file owner's privileges, usually root. An exploitable SUID binary is one of the fastest paths to root, so list them early and check the obvious suspects.

The sudo configuration tells you exactly which commands your user may run as root. A permissive sudoers entry is often all you need. Check what you can run, then look up whether that command can escape to a shell or write files as root.

World-writable scripts that run through cron or as part of a service are a subtler prize: if you can write a file that a privileged process executes, you control what that process does.

find / -perm -4000 -type f 2>/dev/null
sudo -l
cat /etc/crontab; ls -la /etc/cron.* 2>/dev/null
# check any listed sudo commands with: sudo -u root <command> --help

Automating the Hunt with LinPEAS

Manual enumeration is the foundation, but automation makes you thorough. LinPEAS scans the system for hundreds of misconfigurations and prints the most promising findings in one pass, color-coded by likely value.

Transfer it carefully: download it to your own machine, verify the checksum, and copy it to the target over your established channel. Be aware that uploading scanning tools can trigger alerts on monitored systems, so prefer a targeted manual check when you are on a sensitive engagement.

Treat automated output as a menu, not a verdict. Every hit LinPEAS reports is a hypothesis to verify by hand before you trust it.

curl -L <linpeas-release-url> -o linpeas.sh
chmod +x linpeas.sh
./linpeas.sh | tee linpeas.out
# read the output top to bottom - red lines first

Picking the Path and Reporting

When several paths appear, choose by reliability and stealth. A clean sudo misconfiguration beats a fragile kernel exploit, because kernel exploits are unstable and can crash the box. Prefer the smallest change that achieves the goal.

Once you have root, verify you truly have elevated privileges and understand exactly which misconfiguration allowed it. That single root cause is what your report must describe, together with a concrete fix.

A good privesc report contains: the initial foothold, the exact commands that escalated privileges, the misconfiguration, and the remediation. If you reached access the engagement did not require, stop there and note it rather than poking further into production data.