Linux Privilege Escalation: From Initial Foothold to Root Access

Table of Contents

The 5-Minute Security Health Check

A few years ago, one of my staging servers logged over 42,000 failed SSH attempts in just six hours. It was a wake-up call. Once an attacker lands on your system as a low-privileged user like www-data, they don’t stop there. They want root. Root access lets them dump /etc/shadow, install persistent rootkits, or wipe your entire filesystem.

Grab a terminal. Run these three commands to see what an attacker sees in their first 30 seconds:

# See your sudo permissions immediately
sudo -l

# Find binaries with the SUID bit (potential root shells)
find / -perm -4000 -type f 2>/dev/null

# Spot world-writable folders for hiding malicious payloads
find / -writable -type d 2>/dev/null

If sudo -l returns NOPASSWD: ALL, your security is effectively zero. Any binary listed there is a potential ladder to the top.

How Attackers Climb the Ladder

Privilege escalation isn’t some dark art. Usually, it’s just an attacker taking advantage of a lazy configuration or a two-year-old unpatched bug. In my experience, 90% of internal breaches exploit one of these four vectors.

1. The SUID Permission Trap

Set User ID (SUID) allows a program to run with the permissions of the file owner—usually root. It is necessary for tools like passwd, but it is dangerous if misapplied. During a 2024 audit, I found a system where find had the SUID bit enabled.

An attacker can bypass all restrictions with one line:

find . -exec /bin/sh -p \; -quit

This command spawns a shell that inherits root’s UID. Before adding SUID to any custom script, check GTFOBins. It is an essential database of Unix binaries that hackers use to break out of restricted environments.

2. Sudo Misconfigurations

Convenience is the enemy of security. Admins often grant sudo rights to specific tools to save time. For example, if you let a user run python3 as root, you’ve handed over the keys to the kingdom:

sudo python3 -c 'import os; os.system("/bin/sh")'

That’s an instant root shell. Watch out for the LD_PRELOAD variable too. If env_keep += "LD_PRELOAD" is set in your /etc/sudoers, an attacker can force the system to load a malicious library before any legitimate command runs.

3. Kernel Vulnerabilities

Old kernels are gold mines for local attackers. Famous exploits like “Dirty COW” (CVE-2016-5195) or “PwnKit” (CVE-2021-4034) allow users to overwrite read-only files. They target memory corruption bugs to inject code directly into privileged processes. Always check your version:

uname -a
cat /etc/os-release

4. World-Writable Cron Jobs

Cron jobs in /etc/crontab usually run with root authority. If a root-owned cron job executes a script located in a world-writable directory, the game is over. An attacker can simply append a reverse shell to that script. The next time the timer hits, the server connects back to the attacker’s machine with full privileges.

Proactive Monitoring and Detection

Manual audits are fine for a single server. However, if you’re managing a cluster, you need automated visibility. I use three specific tools to keep tabs on my infrastructure.

Automation with LinPEAS

LinPEAS is the go-to script for every professional pentester. It scans for everything from loose file permissions to hidden passwords in config files. Run it in a containerized or test environment first to see what it flags.

# Run the latest scan directly
curl -L https://github.com/peass-ng/PEASS-ng/releases/latest/download/linpeas.sh | sh

Real-Time Tracking with pspy

Sometimes you need to see what’s happening right now without root access. pspy monitors processes as they start. It uses inotify API calls rather than just spamming the /proc directory. This makes it perfect for catching short-lived cron jobs or automated cleanup scripts that might be vulnerable.

Auditd: The Flight Recorder

The Linux Audit Daemon (auditd) is the most reliable way to track sensitive file changes. I always set rules for /etc/shadow and /etc/sudoers. If a non-admin touches these, I get a log entry with the exact PID and user ID responsible.

# Monitor sudoers for any write or attribute changes
sudo auditctl -w /etc/sudoers -p wa -k alert_sudoers

Hardening Tactics That Actually Work

Don’t just fix the bugs; change the environment. These are the specific steps I take on every new production build.

Use sudoedit: Never let users run a full text editor like vim or nano via sudo. They can easily escape to a shell. Use sudoedit instead, which creates a temporary copy of the file for editing.
No-Exec Partitions: Mount /tmp and /dev/shm with the noexec flag. This prevents attackers from running downloaded exploit binaries in the only folders they usually have permission to write to.
Strip Compilers: Most production web servers don’t need gcc or make. Remove them. If an attacker can’t compile their exploit code on the fly, they often get stuck.
Sysctl Hardening: Block hardware-level exploits by restricting the perf subsystem.

# Apply immediately
sudo sysctl -w kernel.perf_event_paranoid=3

# Persist after reboot
echo "kernel.perf_event_paranoid=3" | sudo tee -a /etc/sysctl.conf

Security isn’t a checkbox; it’s a constant state of adjustment. By closing off SUID shortcuts and monitoring process execution, you make your servers an expensive and frustrating target for attackers. Patch your kernels, audit your sudoers, and never trust a world-writable script.