Linux Privilege Escalation Techniques Guide

Linux privilege escalation is the critical process of elevating access from a standard user account to a higher-privileged one, typically root. For penetration testers and red teamers, it's the essential bridge between initial foothold and full system compromise, allowing you to access sensitive data, move laterally, and establish persistence. For defenders and CTF players, understanding these techniques is fundamental to hardening systems and solving security challenges. This guide provides a comprehensive, methodical walkthrough of the most common and effective privilege escalation vectors, pairing each offensive technique with the corresponding defensive mindset for mitigation.

Foundational Enumeration: Knowing What to Look For

Before attempting any escalation, thorough enumeration is non-negotiable. You must understand the system's configuration, your user's context, and potential weak points. Manual checks are valuable, but automated enumeration tools like LinPEAS (Linux Privilege Escalation Awesome Script) are indispensable for high-priority engagements. LinPEAS is a bash script that scans for dozens of potential misconfigurations, from kernel versions to writable files, and highlights findings with color-coded risk ratings. Running it provides a structured attack surface. However, always cross-reference its output; don't rely solely on automation. Key manual commands to run include id, sudo -l, uname -a (for kernel version), find / -perm -4000 2>/dev/null (for SUID files), and reviewing processes with ps aux.

Defensive Countermeasure: Regular auditing using similar tools from a defensive standpoint is crucial. Tools like Lynis can perform security hardening scans. Limit the installation of unnecessary packages and scripts, and monitor for the execution of unknown enumeration scripts on your systems.

Exploiting File Permissions: SUID, SGID, and Writable Files

Misconfigured file permissions are a primary escalation vector. A SUID (Set User ID) binary executes with the privileges of the file's owner, often root. If such a binary is poorly coded or allows command injection, it can be hijacked. For example, if find has the SUID bit set, you can spawn a shell: find . -exec /bin/sh \; -quit. The same logic applies to SGID (Set Group ID) binaries, which run with the group's privileges.

Similarly, writable service files or their configuration files (e.g., systemd service unit files in /etc/systemd/system/) can be modified to execute malicious commands when the service is restarted. If a service running as root has a writable script it calls, you can replace that script with a reverse shell.

Defensive Countermeasure: Minimize SUID/SGID binaries. Use the command find / -perm -4000 -type f 2>/dev/null to audit them and remove the bit where not strictly required. Ensure service files and critical configurations are owned by root and are not globally writable (permissions like 644). Implement file integrity monitoring (FIM) to detect unauthorized changes.

Scheduled Tasks and Environment Manipulation

The PATH variable is an ordered list of directories where the shell looks for commands. If you can write to a directory that appears early in the PATH of a script executed by a privileged user (like a cron job), you can create a malicious binary with the name of a command called in that script. When the cron job runs, it will execute your malicious version.

Cron job abuse extends beyond PATH. Cron jobs scheduled by root that run scripts with world-writable permissions are a direct path to escalation. Examine /etc/crontab, crontab -l for the current user, and system-wide cron directories (/etc/cron.*/). Any script or binary referenced there that you can modify is a target.

Defensive Countermeasure: Use absolute paths in all cron job and script definitions. Audit cron jobs regularly for insecure file permissions. Secure the PATH variable for root and system services, ensuring it does not include world-writable directories like /tmp.

Kernel Exploits and Modern Mechanisms

A kernel exploit targets a vulnerability in the Linux kernel itself. After initial access, you check the kernel version (uname -a) and search for a public exploit matching that version. While highly effective, kernel exploits are noisy and can crash the system. They also require compatibility with the target's architecture and distribution.

Linux Capabilities provide a more granular way to assign privileged operations to binaries without giving them full root access. However, misconfigured capabilities can be exploited. For instance, if a binary has the CAP_SYS_ADMIN or CAP_DAC_READ_SEARCH capability, it can be leveraged to read shadow files or escape chroots. You can list capabilities with getcap -r / 2>/dev/null.

Defensive Countermeasure: Keep kernels patched and up-to-date. Use mechanisms like SELinux, AppArmor, or grsecurity to add an additional layer of protection against kernel exploits. Audit capabilities rigorously using getcap and remove unnecessary ones. Follow the principle of least privilege.

Network and Service Misconfigurations

NFS (Network File System) misconfiguration can be a goldmine. If an NFS share is configured with the no_root_squash option and is mounted on your attacking machine, you can create a SUID binary as your local root user. When that binary is executed on the target (which sees it as owned by root), it will run with root privileges on the target system.

Docker and container escapes are a specialized but critical area. If you find yourself inside a container, check if it's running with dangerous flags, like --privileged or with sensitive host directories mounted (e.g., /, /etc). Exploits like abusing the docker.sock socket or the cgroups release_agent feature can lead to a full host breakout.

Defensive Countermeasure: For NFS, avoid using no_root_squash; use root_squash as the default. For Docker, never run containers with --privileged. Use read-only bind mounts where possible, drop all capabilities and add only those required, and run containers as a non-root user inside the container.

Common Pitfalls

Relying Solely on Automation: Running LinPEAS and blindly trying every exploit it suggests is a recipe for failure and detection. You must understand the context—why a finding is relevant and how the system's specific configuration makes it exploitable. Manual verification is key.

Ignoring Operational Security (OPSEC): Blindly running a kernel exploit downloaded from the internet on a production system can cause a denial-of-service, alert defenders, and burn your access. Always test exploits in a comparable environment if possible, and consider the stability and noise level of your chosen method.

Overlooking Simple Checks: Before diving into complex kernel exploits, always run sudo -l. You might have permission to run a specific command as root without a password, which is the simplest path to escalation. Similarly, checking for files with weak permissions in the home directory of other users or root (e.g., .ssh/authorized_keys, bash history) can yield quick wins.

Failing to Document and Pivot: After a successful escalation, the work isn't over. You must document the method, gather credentials (like hashes from /etc/shadow), and look for ways to pivot to other systems or establish persistent access. Fixating on the single escalation event without considering the next steps limits the impact of your test.

Summary

• Privilege escalation is a systematic process beginning with comprehensive enumeration using both manual commands and automated tools like LinPEAS to map the attack surface.
• File permission misconfigurations—SUID/SGID binaries, writable service files, and cron jobs—are among the most common and reliable vectors for escalating privileges on a system.
• Environmental and kernel-level attacks, including PATH variable manipulation, kernel exploits, and Linux capabilities exploitation, provide pathways to root when basic misconfigurations are not present.
• Network services and containerization introduce unique vectors like NFS shares with no_root_squash and Docker container escapes, which require specific knowledge to exploit and defend against.
• A successful tester balances automation with understanding, always considers OPSEC and system stability, and knows that the simplest check (sudo -l) can often be the most fruitful.