The first time I landed a low-privilege shell on a Linux box during a real engagement, I remember staring at the terminal for a solid five minutes not knowing where to start. Linux privilege escalation can feel overwhelming because there are so many possible paths — SUID binaries, cron jobs, kernel exploits, misconfigured sudo rules, exposed credentials. Over time I built a repeatable process, and that’s exactly what I want to share here: a practical, real-world checklist for going from a limited shell to root.
What Linux Privilege Escalation Means
Privilege escalation on Linux is the process of turning restricted access — a low-privilege user shell, a web shell running as www-data, or a service account — into root, or at least into a more privileged account than the one you started with. It usually happens because of a misconfiguration, an overly permissive file, a forgotten credential, or an outdated kernel.
Why This Matters in a Real Assessment
A foothold alone rarely demonstrates business risk. What convinces a client to fix something is showing that a compromised web application can lead all the way to root on the underlying server, and from there, potentially to other systems on the network. Linux privilege escalation is the bridge between “we found a vulnerability” and “here’s what an attacker could actually do with it.”
Authorized Testing Only
Everything in this article is meant for systems you’re explicitly authorized to test: a signed pentest engagement, your own home lab, or legal practice platforms like HackTheBox, TryHackMe, or VulnHub. Running these techniques against systems without permission is illegal.
Initial Enumeration: Know Your Environment
The first thing I check on any new Linux shell is basic situational awareness.
id
whoami
uname -a
cat /etc/os-release
uname -a tells you the kernel version, which matters a lot — an outdated kernel might be vulnerable to a known local exploit. id tells you your current groups, which is important because certain group memberships (like docker or lxd) can be an instant path to root.
sudo -l
This shows what commands, if any, you can run as another user via sudo, and whether a password is required. This single command has gotten me root more times than almost anything else on this list — a misconfigured sudo rule allowing a binary like vim, find, or less to run as root is a near-instant escalation via GTFOBins.
Automated Enumeration Tools
Just like on Windows, manual checks matter, but automated tools save enormous time.
LinPEAS
LinPEAS is the most widely used Linux enumeration script, checking for SUID binaries, writable cron jobs, kernel exploits, capabilities, and dozens of other misconfigurations.
./linpeas.sh
Read the output carefully — like WinPEAS, it color-codes likely findings, but don’t ignore the less flashy output.
LinEnum
An older but still useful bash script that produces a clean, readable summary of common misconfigurations.
./LinEnum.sh -t
Linux Exploit Suggester
This tool cross-references the kernel version against a database of known local privilege escalation exploits.
./linux-exploit-suggester.sh
I treat kernel exploit suggestions as a last resort — they’re often unstable and can crash a production system, so on a client engagement I confirm before attempting one.
Step-by-Step Manual Methodology
1. Check SUID/SGID Binaries
find / -perm -4000 -type f 2>/dev/null
This lists binaries that run with the owner’s privileges (usually root) regardless of who executes them. Compare the results against GTFOBins to see if any of them can be abused to spawn a shell, read files, or write files as root.
2. Check Sudo Permissions
Already mentioned above, but worth digging deeper into. If sudo -l shows you can run something like:
(root) NOPASSWD: /usr/bin/find
You can escalate instantly:
sudo find . -exec /bin/sh \; -quit
3. Check Cron Jobs
cat /etc/crontab
ls -la /etc/cron.*
crontab -l
If a cron job run by root points to a script that your current user can write to, you can insert a reverse shell payload and wait for the next execution.
4. Check World-Writable Files and Directories
find / -writable -type d 2>/dev/null
Pay close attention to any writable files in /etc, systemd unit files, or scripts referenced by services running as root.
5. Check for Interesting Capabilities
Linux capabilities can grant partial root-like powers to a binary without full SUID.
getcap -r / 2>/dev/null
A binary with cap_setuid+ep, for example, can be abused to set your effective UID to 0.
6. Check for Exposed Credentials
grep -ri "password" /etc/*.conf 2>/dev/null
find / -name "*.bak" -o -name "*.old" 2>/dev/null
cat ~/.bash_history
Config files, backup files, and shell history often contain plaintext credentials or API keys that let you pivot to a more privileged account.
7. Check Group Memberships for Known Escalation Paths
Groups like docker, lxd, disk, and adm can each be abused in specific ways. For example, if your user is in the docker group:
docker run -v /:/mnt --rm -it alpine chroot /mnt sh
This mounts the host filesystem inside a container and gives you a root shell on the host, because the Docker daemon itself runs as root.
A Practical Walkthrough Example
Imagine sudo -l shows:
(ALL) NOPASSWD: /usr/bin/vim
Checking GTFOBins for vim shows a straightforward escalation:
sudo vim -c ':!/bin/sh'
Vim spawns a shell, and because it was invoked through sudo, that shell runs as root. This is a perfect example of why checking sudo -l early in your process is so valuable — it’s often the single fastest path to full compromise.
Common Mistakes and Troubleshooting
- Not checking kernel version early. Sometimes the fastest win is a known CVE, and you’ll miss it if you don’t check
uname -afirst. - Ignoring
sudo -lbecause it “looks empty.” Sometimes it requires a password you already have from an earlier credential find — always try it with any password you’ve captured. - Overlooking capabilities. Many testers focus only on SUID binaries and forget
getcap -r /entirely, missing an easy win. - Running LinPEAS without piping output to a file. On a real engagement, always save output (
./linpeas.sh | tee linpeas_output.txt) so you can review it later without re-running the scan. - Attempting a kernel exploit without checking engagement rules. Kernel exploits can crash services; always clear this with the client first.
Security Risks and Defensive Recommendations
- Regularly audit
sudoersfiles and remove unnecessaryNOPASSWDentries. - Avoid granting SUID bits to binaries that don’t strictly need them.
- Restrict membership in privileged groups like
dockerandlxdto trusted administrators only. - Rotate credentials found in configuration files, and use a secrets manager instead of plaintext storage.
- Patch kernels regularly, and track CVEs relevant to your distribution.
- Monitor cron job integrity and restrict write access to scripts they execute.
Frequently Asked Questions
1. What’s the single fastest check to run first on a new Linux shell? sudo -l — misconfigured sudo permissions are one of the most common and fastest paths to root.
2. Are LinPEAS results always accurate? No, LinPEAS surfaces potential issues, but you should always manually verify a finding before relying on it in a report or an exploit chain.
3. Is it safe to run kernel exploits during a client engagement? Only with explicit authorization, since kernel exploits can crash production systems. Always confirm scope and get sign-off first.
4. What is GTFOBins and why does it matter? GTFOBins is a curated list of Unix binaries that can be abused to bypass restrictions, useful for quickly checking if a SUID binary or sudo rule can be exploited.
5. Do I need root to run LinPEAS effectively? No, LinPEAS works from any user context and simply reports what’s accessible or exploitable from your current privilege level.
6. How common are Docker/LXD group escalations in real environments? Fairly common in DevOps-heavy environments where developers are added to the docker group for convenience without understanding the security implications.
7. What should I do if none of the standard checks reveal anything? Widen your search to less common vectors: NFS misconfigurations, PATH hijacking opportunities, writable systemd unit files, and library hijacking through LD_PRELOAD.
Conclusion
Linux privilege escalation, like its Windows counterpart, comes down to methodology rather than memorized exploits. Start with situational awareness, run automated tools to save time, and then work systematically through sudo permissions, SUID binaries, cron jobs, capabilities, and credential exposure. The techniques in this checklist have taken me from a limited shell to root across a wide range of engagements, and building the habit of running through them in order will make you faster and more thorough every time.