Linux Privilege Escalation: Techniques Guide (2026)

What Is Linux Privilege Escalation?

What is Linux privilege escalation? Linux privilege escalation is the technique of gaining higher permissions on a Linux system than your current account holds, usually moving from a standard or service user to root. It exploits local misconfigurations rather than the remote flaw that got you the shell in the first place.

Initial access rarely lands you as root. A vulnerable web application runs as www-data, a compromised database service runs under its own scoped user, an SSH key gets you a normal login account. None of those can read /etc/shadow, install a persistent backdoor, or pivot with full control. Root can. Escalation is the bridge between the two, and MITRE ATT&CK tracks it as its own tactic, TA0004, because nearly every serious intrusion depends on it.

The good news for a learner: Linux escalation is overwhelmingly about configuration, not memory corruption. You do not need to write a single line of assembly to root most boxes. You need to enumerate carefully and recognize a handful of patterns. That is a skill you build through repetition, not talent.

Step 1 - Enumerate the Box

Enumeration is where every root shell begins. Before you try anything, you build a picture of the system: who you are, what you can run, and where the machine trusts something it should not.

Start with the three commands that cost nothing and often hand you the answer outright:

id                    # your UID, GID, and group memberships
sudo -l               # what you can run as root, with or without a password
find / -perm -4000 -type f 2>/dev/null   # every SUID binary on the system

Group membership on that first line matters more than beginners expect. If id shows you in the docker, lxd, or disk group, you have a near-instant root path before you look at anything else, since each of those groups can be abused to read or write outside your user's boundary.

From there, widen the net: check the kernel with uname -a, list scheduled jobs in /etc/crontab and /etc/cron.d/, look for capabilities with getcap -r / 2>/dev/null, and read any world-readable config files in web roots and home directories for stored credentials. In practice, database passwords sitting in a config.php or a .env file are one of the most common real-world paths, and no automated tool prioritizes them for you.

Doing all of this by hand takes time, so most testers run an automated enumeration script to sweep the machine in one pass. Our LinPEAS guide covers installing it, running it without touching disk, and reading its color-coded output, red-on-yellow means a high-probability escalation path. The script does not exploit anything. It tells you where to look; you still have to open the door yourself.

SUID and SGID Binaries

The SUID (Set User ID) bit tells Linux to run a binary with the permissions of its owner, not the user who launched it. When the owner is root, any user who can execute that binary runs its code as root for the duration. That is by design for tools like passwd, which needs to write to /etc/shadow. It becomes an escalation path when the SUID bit lands on a binary that can be coerced into running arbitrary commands.

Your find / -perm -4000 output lists every candidate. Most entries are standard system binaries. What you are hunting for is anything unusual: a copy of find, nmap, vim, python, or a custom in-house tool with the bit set. Cross-reference each unfamiliar entry against GTFOBins, a catalog of Unix binaries and the exact syntax to abuse them.

The textbook example: if find itself carries the SUID bit, this single command hands you a root shell, because find runs the spawned shell with its own elevated privileges:

find . -exec /bin/sh -p \; -quit
# id
uid=0(root) gid=0(root) groups=0(root)

The -p flag on the shell is the part people forget. Without it, bash and sh drop elevated privileges on startup as a safety feature, and you end up back as your original user wondering why the exploit failed.

Sudo Misconfigurations

Run sudo -l and read every line. It shows exactly which commands your user can run as root, and each one is a candidate. A rule like (ALL) NOPASSWD: /usr/bin/vim reads as harmless administrative convenience until you check GTFOBins for vim:

sudo vim -c ':!/bin/sh'

That escapes to a root shell, because vim runs as root under the sudo rule and can spawn a child process. The same logic applies to awk, less, find, python, tar, and dozens of other interpreters and utilities. Any sudo rule pointing at something that can execute code, read arbitrary files, or write arbitrary files is worth checking before you assume it is safe.

Two environment-based tricks are worth knowing. If the sudoers file has env_keep+=LD_PRELOAD, you can compile a small shared object that spawns a shell and preload it into any sudo-allowed command. And older sudo versions carry outright vulnerabilities: Baron Samedit (CVE-2021-3156) let any local user reach root regardless of their sudoers entry on sudo versions before 1.9.5p2. Always check sudo --version against known CVEs.

Linux Capabilities

Capabilities are the fine-grained cousin of the SUID bit. Instead of granting a binary the full power of root, Linux can grant it one specific privilege, and admins sometimes set them thinking they are the safer option. Often they are not.

Enumerate them with getcap -r / 2>/dev/null. The one to watch for is cap_setuid. If a Python interpreter carries it, for instance, the output looks like this:

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

That single capability is enough to become root, because the binary can set its own UID to 0 and then execute a shell:

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

Capabilities get overlooked precisely because they feel granular and controlled. In practice, a cap_setuid or cap_dac_read_search capability on a scriptable binary is every bit as dangerous as a bare SUID root binary, and it slips past reviewers who only ever check for the SUID bit.

Cron Job Abuse

Scheduled jobs that run as root but execute a file you can write to are one of the cleanest escalation paths on Linux. Check /etc/crontab, the /etc/cron.d/ directory, and /etc/cron.daily/ for jobs, then look at the permissions on whatever script each job calls.

If a root cron job runs /opt/scripts/backup.sh and that file, or the directory holding it, is writable by your user, you own the next execution. Append a payload and wait:

echo 'cp /bin/bash /tmp/rootbash && chmod +s /tmp/rootbash' >> /opt/scripts/backup.sh
# after the job runs on schedule:
/tmp/rootbash -p
# id -> uid=0(root)

A wildcard in a cron-run tar or chown command opens a related attack called wildcard injection, where crafted filenames get interpreted as command-line flags. The signal to watch for is any root-owned automation that touches a location a non-root user can write to. That mismatch is the whole vulnerability.

PATH and Writable File Abuse

When a root-owned script calls a binary by name only, tar instead of /bin/tar, the shell searches the directories in $PATH in order and runs the first match. If you can write to a directory that appears earlier in that search order, or you can influence $PATH before the script runs, your malicious tar executes with the script's privileges. Drop a two-line script named after the called binary into a writable, earlier directory and you inherit root.

Two file-permission checks belong in the same category. First, a writable /etc/passwd is game over: add a line with a known password hash and a UID of 0, then su into it. Second, a writable /etc/shadow or a readable one with a crackable root hash feeds straight into offline password cracking. Always run ls -l /etc/passwd /etc/shadow early, since a single loose permission there ends the engagement.

Kernel Exploits

When configuration-based paths turn up nothing, the kernel version itself becomes the target. This is a last resort, not a first move, because kernel exploits can panic the machine and take the target offline, which is rarely acceptable on a live engagement without explicit sign-off.

The two names to know: PwnKit (CVE-2021-4034) exploited the pkexec component of Polkit and gave any local user root on default installs of Ubuntu, Debian, Fedora, and CentOS, after sitting undiscovered for over twelve years. Dirty Pipe (CVE-2022-0847) let an unprivileged user overwrite data in read-only files on kernels from 5.8 onward, including /etc/passwd, making root trivial.

Match the kernel version from uname -r against known CVEs before reaching for an exploit, and confirm the target is a lab or an engagement where instability is authorized. A crashed production box is a much bigger problem than a missed root flag.

Linux Privilege Escalation Cheat Sheet

Keep this enumeration order next to your terminal. It moves from the checks most likely to pay off quickly to the ones you reach for when the easy paths are dry.

How to Defend Against It

How do you prevent Linux privilege escalation? Remove the specific misconfigurations attackers rely on. There is no single control that stops all of it, but each path above closes with a concrete, cheap fix.

• Strip unnecessary SUID bits. Audit with find / -perm -4000 and remove the bit from anything that does not genuinely need it. Nothing custom should carry it without review.
• Never grant NOPASSWD sudo to interpreters. A sudo rule for vim, awk, python, or find is an open door to a root shell. Scope sudo rules to specific, non-scriptable actions.
• Review file capabilities. Run getcap -r / during hardening and treat cap_setuid on any general-purpose binary as equivalent to a SUID root bit.
• Lock down cron scripts. Root-owned scheduled jobs must call root-owned files in root-owned directories, with no write access for anyone else.
• Patch on a real cadence. PwnKit and Dirty Pipe were both fixed by an update. Most successful kernel escalations happen on systems months behind.

When testing real hosts, the fastest way to find these gaps before an attacker does is to run the same enumeration an attacker would, LinPEAS plus a manual sudoers and capabilities review, on a schedule rather than once at deployment.

Legal and Ethical Considerations

Every command in this guide is what a real attacker runs to turn a foothold into full compromise. The only thing separating a penetration tester from a criminal typing the same syntax is authorization, agreed in writing before the engagement starts.

Practice legally in three venues: bug bounty programs within their published scope, paid engagements under a signed statement of work, and sandboxed lab platforms built to be broken. Everything above is written for those three and nothing else.