Linux Privilege Escalation for Pentesters

Moving from a basic user shell to a privileged root account is often the most critical phase of a penetration test or red team engagement. A foothold on a system is only as valuable as the level of access it provides, and on Linux, privilege escalation involves uncovering and exploiting a chain of misconfigurations, weak permissions, and unpatched vulnerabilities. Mastering this skill transforms you from a passive observer into an effective security assessor who can accurately gauge the real-world risk a system faces.

Foundational Misconfigurations: SUID, SGID, and Writable Files

The most common path to privilege escalation stems from simple permission misconfigurations. Understanding how Linux file permissions work is the first step. The SUID (Set User ID) and SGID (Set Group ID) bits are special permissions that, when set on an executable file, allow it to run with the privileges of the file's owner or group, respectively. A classic example is the /usr/bin/passwd command, which has the SUID bit set so that regular users can modify the system password file, which is owned by root.

Exploitation occurs when a SUID/SGID binary is owned by root but is poorly written or allows command injection. For instance, if you find a custom SUID binary that executes the cat command without specifying its full path, you can exploit this via PATH variable manipulation. By creating a malicious script named cat in a directory you control and prepending that directory to the $PATH environment variable, you can trick the SUID binary into executing your code with root privileges. The first step is always enumeration: use the find command to locate all SUID/SGID files on the system (find / -type f -perm -u=s -ls 2>/dev/null).

Similarly, writable cron jobs present a major opportunity. Cron is the system's job scheduler. If a script executed by root (or any privileged user) is writable by your current user, you can modify it to execute your own payload. The enumeration command crontab -l and checking system cron directories (/etc/crontab, /etc/cron.d/, /var/spool/cron/crontabs/) is essential. Never overlook writable configuration files for services or applications, as they can often be modified to execute code in the context of the service, which frequently runs as root.

Advanced Permission Abuse: Capabilities and NFS

Modern Linux systems use capabilities to provide a more granular breakdown of root privileges. Instead of granting a process full root access, a capability can grant a specific power, like the ability to bypass file read permissions (CAP_DAC_READ_SEARCH) or to bind to privileged network ports (CAP_NET_BIND_SERVICE). However, capabilities can be misconfigured. A binary with the CAP_SETUID capability embedded, for example, can be abused to set its own effective user ID to root. You can enumerate binaries with capabilities using getcap -r / 2>/dev/null.

Network File System (NFS) misconfigurations are another vector, often overlooked in internal network assessments. When an NFS share is configured with the no_root_squash option, a client connecting as root will retain root privileges on the share. If you can mount such a share, you can create a SUID binary on it, execute it from the client, and gain root access on the NFS server. The key is to check the server's /etc/exports file (or your ability to enumerate shares via showmount -e <target>).

Container and Kernel-Level Escalation

In today's environments, you must consider container escape paths. A Docker escape typically involves breaching the isolation boundary of a container to gain access to the underlying host. This can happen if the container is run with dangerous privileges, such as --privileged flag, or if sensitive host directories (like /, /var/run/docker.sock) are mounted inside the container with write access. For instance, write access to the host's / filesystem from within a container allows you to create a scheduled task (like a cron job) on the host itself, leading to code execution outside the container.

When all other avenues are exhausted, kernel exploits become the tool of last resort. These exploit vulnerabilities in the Linux kernel itself to gain root privileges. The process involves gathering system information (kernel version via uname -a, distribution, installed packages) and matching it against a database of known public exploits. Tools like Linux Exploit Suggester assist in this process. However, kernel exploits carry significant risk: they can crash the system (denial of service), are often noisy, and their success depends heavily on the specific kernel configuration and mitigations (like SELinux, AppArmor, or kernel hardening patches like KASLR). Always test exploits in a lab environment that matches your target as closely as possible before running them in a production assessment.

Systematic Enumeration and Approach

A haphazard search is ineffective. Successful privilege escalation relies on a systematic approach driven by thorough enumeration. This begins the moment you gain initial access. Automated enumeration scripts like LinPEAS, LinEnum, or LES (Linux Privilege Escalation Awesome Script) are invaluable. They rapidly check for all the common vectors—SUID/SGID files, writable paths, cron jobs, capabilities, environment variables, leaked credentials in history or config files, and vulnerable software versions.

Your methodology should be iterative:

1. Automated Enumeration: Run a trusted script to get a broad overview of the system's attack surface.
2. Manual Verification: Manually investigate the most promising leads from the script output. Don't trust automation blindly.
3. Exploitation Attempt: Try the most reliable and least intrusive method first (e.g., exploiting a writable cron job before attempting a risky kernel exploit).
4. Post-Exploitation Enumeration: Once you escalate, immediately enumerate again from the new context (e.g., as root) to look for credentials, lateral movement paths, or additional security controls.

Common Pitfalls

Over-reliance on Automation: Treating script output as gospel without understanding the underlying concepts is a major mistake. Scripts can miss obscure misconfigurations or produce false positives. You must be able to manually verify findings and understand why a particular finding is exploitable.

Blind Kernel Exploit Execution: Downloading and running a random kernel exploit from the internet against a client system is unprofessional and dangerous. It can crash critical infrastructure. Always research the exploit, understand its requirements and side effects, and test it in a safe environment first. Prefer reliable, publicly vetted exploits from reputable sources.

Ignoring Context and OpSec: In a red team scenario, operational security (OpSec) is crucial. A kernel exploit might be loud and get you caught. A noisy find command scanning the entire filesystem might trigger alerts. Sometimes, a slower, more subtle method like abusing a scheduled task is preferable to a flashy kernel exploit.

Failing to Document the Path: As a pentester, your goal is not just to get root but to demonstrate the exact path an attacker would take. Failing to document each step—from the initial misconfiguration you found to the final proof of root access—diminishes the value of your assessment and provides the client with less actionable remediation advice.

Summary

• Linux privilege escalation is a systematic process of chaining misconfigurations like SUID/SGID binaries, writable cron jobs, and PATH manipulation to elevate your access from a user to root.
• Advanced vectors include abusing Linux capabilities, exploiting NFS shares with no_root_squash, and identifying Docker escape opportunities through privileged container configurations.
• Kernel exploits are a high-risk, last-resort option that require careful matching of the target's kernel version and configuration to a known vulnerability.
• A disciplined methodology centered on automated enumeration (with tools like LinPEAS) followed by manual verification and exploitation is essential for consistent success.
• Always consider operational security and stability; the quietest, most reliable path to root is usually the best one during a professional assessment.