In the world of Capture The Flag (CTF) competitions and real-world penetration testing, privilege escalation is often said to be 90% enumeration and 10% exploitation. Once you have obtained a low-privileged shell on a target machine, your immediate first step is to gather as much information as possible about the environment. Rushing to run exploits without understanding the system will likely crash the machine or trigger alarms.
Start with basic system enumeration. Use uname -a to check the kernel version and architecture. Run id to see your current user and group memberships. Check sudo -l to see if your user is allowed to run any commands as root without a password. Next, look for sensitive files: check the /etc/passwd file to see other users, and look for readable configuration files in /opt, /var/www/html, or user home directories that might contain hardcoded database credentials or SSH keys.
Linux privilege escalation typically falls into a few well-known categories. Understanding these vectors is crucial for knowing what to look for during your enumeration phase.
find, vim, or bash has the SUID bit set by root, it can be trivially abused to spawn a root shell.sudo awk or sudo less, they can use the interactive features of those programs to break out into a root shell.While manual enumeration is essential for learning, automated tools save massive amounts of time. Scripts like LinPEAS (Linux Privilege Escalation Awesome Script) or LinEnum will scan the system and highlight potential vectors in color-coded output (red/yellow for high probability). Once a vector is identified, the website GTFOBins is an invaluable resource. It provides a curated, searchable list of Unix binaries that can be used to bypass local security restrictions.
Let's walk through a practical example. During your enumeration, you run the command find / -perm -4000 -type f 2>/dev/null to search for SUID binaries. The output reveals that /usr/bin/nmap has the SUID bit set. You check the version and find it is an older release (versions 2.02 to 5.21).
According to GTFOBins, older versions of nmap have an interactive mode that allows users to execute shell commands. Because the SUID bit is set, these commands will execute as the owner of the binary (root). You run nmap --interactive. At the nmap prompt, you type !sh. Instantly, your prompt changes from $ to #. You run whoami, and the system responds with root. You have successfully escalated privileges.
Sometimes the obvious vectors fail. If SUID binaries and sudo misconfigurations yield nothing, you must dig deeper. Look for NFS shares with no_root_squash enabled, which allows you to mount the share locally, create a malicious SUID binary, and execute it on the target. Investigate internal ports using netstat -ano to find services running locally as root (like a vulnerable MySQL instance) that aren't exposed to the outside network.
If an exploit fails, don't blindly run it again. Check the architecture (32-bit vs 64-bit). Ensure you have the necessary dependencies installed on the target (like gcc for compiling C exploits). If you are transferring files, verify the integrity using MD5 hashes to ensure the payload wasn't corrupted during transfer. Patience and methodical troubleshooting are the hallmarks of a successful penetration tester.
Linux privilege escalation is a critical phase of any penetration test or Capture The Flag (CTF) challenge. Once initial access is achieved as a low-privileged user (such as www-data), the goal is to identify misconfigurations, software flaws, or administrative oversights to escalate privileges to the root account. One of the first vectors we check is the presence of misconfigured SUID (Set Owner User ID) or SGID (Set Group ID) binaries.
SUID is a permission bit that allows a file to be executed with the privileges of the file owner (which is frequently root) rather than the user executing the file. We search for these files using the find command: find / -perm -4000 -type f 2>/dev/null. Once we locate the SUID binaries, we check them against GTFOBins, an online curated list of Unix binaries that can be abused to bypass local security restrictions. For instance, if a standard binary like find or nano has the SUID bit set, an attacker can use built-in parameters or shell escapes to execute commands directly as root, bypassing all local authorization controls.
Cron jobs are scheduled tasks that run automatically in the background under the context of specific users, often root. If a root-run cron job executes a script that is writable by standard users, or if the cron configuration uses wildcards incorrectly, it creates a direct pathway for privilege escalation.
A classic wildcard exploit occurs when a cron job runs a command like tar -cf backup.tar * in a directory where standard users have write access. The wildcard character (*) is expanded by the shell into the filenames of all files in the directory. An attacker can create files with names that match tar command-line options, such as --checkpoint=1 and --checkpoint-action=exec=bash exploit.sh. When the cron job executes, tar interprets these filenames as parameters rather than files, executing the script (exploit.sh) as root. Auditing cron jobs requires looking for any scripts with insecure permissions or unsafe wildcard usage.
The sudo command allows users to run specific commands with root privileges. In many CTFs and real-world environments, developers configure sudo permissions in the /etc/sudoers file to allow standard users to run specific scripts or commands without typing a password (NOPASSWD). If these scripts are writable, or if they allow execution of external commands, they are easily exploited.
For example, if a user can run a python script as sudo, the attacker can exploit Python's module search order using library hijacking. When Python executes a script containing the code import os, it first searches the current working directory for a file named os.py before checking the standard system libraries. If the attacker has write access to the directory from which the script is run, they can create a malicious os.py file containing shell code. When the script is executed with sudo, Python loads the attacker's module, executing commands as root. Auditors review all sudo configurations (sudo -l) and ensure scripts enforce absolute paths and restrict directory write access.
If local configurations are secure, the final escalation vector is the operating system kernel. Kernel exploits target vulnerabilities in the core operating system code (such as the infamous Dirty COW, Dirty Pipe, or PwnKit vulnerabilities) to gain root access. While highly effective in CTF environments, kernel exploits must be handled with extreme caution.
In a real-world penetration test, running a kernel exploit is a high-risk action that can cause kernel panics, corrupt filesystem data, or crash critical servers, violating the Rules of Engagement. In CTFs, however, they are frequently required. We check the kernel version using uname -a and search databases like Exploit-DB or GitHub for compiled proof-of-concepts. Before running an exploit, we must verify compiler compatibility, library dependencies, and potential cleanup steps. A successful exploit grants root instantly, but ensuring you understand the exploit's mechanics and potential instability is essential for professional security research.