Linux Privilege Escalation Audit: The 12-Point Checklist That Finds the Misconfigurations Attackers Exploit to Reach Root
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Linux privilege escalation audits are most useful when run from the perspective of the lowest-privilege account that can access the system -- typically the application service account. The assumption is that an attacker has already compromised that account (via a web application vulnerability, for example) and is attempting to escalate to root. The following 12 checks cover the categories that consistently yield escalation paths on production systems.
Checks 1-4: SUID, SGID, and Capabilities
Check 1: Non-standard SUID binaries
# Find all SUID binaries (run as file owner's UID when executed)
find / -perm -u=s -type f 2>/dev/null | sort
# Compare against expected SUID binaries for this distro
# Expected on most systems: /usr/bin/sudo, /usr/bin/passwd, /usr/bin/su, /usr/bin/newgrp
# UNEXPECTED: /usr/local/bin/python3, /usr/bin/vim, /usr/bin/find, /usr/bin/nmap
Check every non-standard SUID binary at GTFOBins (https://gtfobins.github.io). Any binary listed there with an SUID entry can be used to read files as root or spawn a root shell.
Check 2: SGID binaries with group write access
find / -perm -g=s -type f 2>/dev/null | sort
# SGID binaries run with the group's GID -- less common escalation but check group memberships
Check 3: Binaries with dangerous capabilities
# List all files with Linux capabilities set
getcap -r / 2>/dev/null
# High-risk capabilities:
# cap_setuid+ep -- allows setting any UID (root access)
# cap_net_raw+ep -- allows raw socket access (packet capture, ARP spoofing)
# cap_sys_admin+ep -- near-root equivalent
# Example dangerous finding:
# /usr/bin/python3 = cap_setuid+ep <-- python can setuid(0) and execute /bin/sh
Check 4: Writable SUID binary directory
# Find directories containing SUID binaries that are world-writable
for suid in $(find / -perm -u=s -type f 2>/dev/null); do
dir=$(dirname $suid)
ls -ld $dir | grep -E "^.......w"
done
# If a directory containing a SUID binary is world-writable, an attacker can
# replace the binary with a malicious version
Checks 5-7: Sudo Configuration
Check 5: Read the sudoers configuration
# List sudo rules for the current user
sudo -l
# Read full sudoers file (requires read access to /etc/sudoers)
cat /etc/sudoers 2>/dev/null
cat /etc/sudoers.d/* 2>/dev/null
High-risk sudo patterns:
(ALL) NOPASSWD: ALL-- full root access without a password(ALL) NOPASSWD: /usr/bin/vi-- vi can escape to shell::!sh(ALL) NOPASSWD: /usr/bin/find-- GTFOBins:sudo find . -exec /bin/sh \;(ALL) NOPASSWD: /usr/bin/python*--sudo python3 -c 'import pty; pty.spawn("/bin/sh")'(ALL) NOPASSWD: /usr/bin/tee-- can overwrite any file as root by piping content
Check 6: Sudo version vulnerability
sudo --version
# CVE-2021-3156 (Baron Samedit): sudo < 1.9.5p2 -- heap overflow leading to root
# CVE-2019-14287: sudo < 1.8.28 -- -1 UID bypass (sudo -u#-1 command)
# If vulnerable version found, check if the CVE applies to this distro's patched version
Check 7: LD_PRELOAD abuse via sudo (env_keep)
# Check if sudo preserves LD_PRELOAD
sudo -l | grep LD_PRELOAD
# If env_keep includes LD_PRELOAD, a malicious shared library can be injected:
# cat evil.c: void _init() { setuid(0); system("/bin/bash"); }
# gcc -fPIC -shared -o /tmp/evil.so evil.c -nostartfiles
# sudo LD_PRELOAD=/tmp/evil.so [any allowed command]
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Checks 8-9: Cron Jobs and Scheduled Tasks
Check 8: World-writable scripts executed by root cron
# List all cron jobs (system-wide)
cat /etc/crontab
ls -la /etc/cron.d/ /etc/cron.daily/ /etc/cron.weekly/ /etc/cron.monthly/
crontab -l # Current user's crontab
# For each script executed by root cron, check if it is writable by low-privilege users:
find /etc/cron* -type f 2>/dev/null | xargs ls -la
# Check if the script itself is writable
ls -la /path/to/cron-script.sh
# If writable by current user: append malicious command to escalate
# Also check if the directory containing the script is writable
# (allows replacing the script with a malicious version)
ls -ld $(dirname /path/to/cron-script.sh)
Check 9: Cron PATH manipulation
# Check the PATH in /etc/crontab
grep PATH /etc/crontab
# If PATH includes user-writable directories before system directories,
# creating a malicious binary with the same name as a cron-called command
# in the writable directory will execute it as root
Checks 10-11: File Permissions and PATH Hijacking
Check 10: World-writable files owned by root
# Find world-writable files owned by root (high risk: modifying them affects root operations)
find / -writable -user root -type f 2>/dev/null | grep -v '/proc\|/sys'
# Find world-writable directories in system paths
find /etc /usr /bin /sbin -writable -type d 2>/dev/null
Check 11: PATH hijacking opportunities
# Check the current user's PATH for writable directories
echo $PATH | tr ':' '\n' | while read dir; do
if [ -w "$dir" ]; then
echo "WRITABLE: $dir"
fi
done
# Check root's PATH via sudo or SUID context
# If a script run as root uses relative command calls (e.g., 'curl' without full path /usr/bin/curl)
# and the script's working directory is writable, a malicious 'curl' binary
# in that directory will execute as root
# Find scripts in PATH that call binaries without full paths
grep -r '\bawk\b\|\bsed\b\|\bcut\b\|\bcurl\b\|\bwget\b' /usr/local/bin/ 2>/dev/null |
grep -v '/usr/bin\|/bin\|/usr/local/bin'
Check 12: Sensitive files with weak permissions
# Check /etc/passwd and /etc/shadow permissions
ls -la /etc/passwd /etc/shadow /etc/group
# /etc/shadow should be: -r-------- (readable only by root)
# If /etc/shadow is world-readable: hashcat/john can crack the hashes offline
# Find SSH private keys that are world-readable
find / -name 'id_rsa' -o -name 'id_ecdsa' -o -name '*.pem' 2>/dev/null |
xargs ls -la 2>/dev/null | grep -v '\-r[\-][\-][\-][\-][\-][\-][\-][\-][\-]'
# Find .bash_history files containing passwords
find / -name '.bash_history' -readable 2>/dev/null |
xargs grep -l 'password\|passwd\|secret\|api_key' 2>/dev/null
Remediation Priority and Automated Tooling
Remediation priority order:
- NOPASSWD sudo on any GTFOBins-listed binary: Immediate -- remove or restrict the rule
- Non-standard SUID binaries: Remove SUID bit if not required:
chmod u-s /path/to/binary - Dangerous capabilities: Remove with:
setcap -r /path/to/binary - Writable root cron scripts: Fix permissions:
chmod 750 /path/to/script; chown root:root /path/to/script - World-readable /etc/shadow: Fix:
chmod 640 /etc/shadow; chown root:shadow /etc/shadow
For automated discovery, run linPEAS as the low-privilege user:
# Download and run linPEAS
curl -L https://github.com/carlospolop/PEASS-ng/releases/latest/download/linpeas.sh | bash 2>/dev/null | tee /tmp/linpeas-output.txt
# Or run from memory without writing to disk
curl -sL https://github.com/carlospolop/PEASS-ng/releases/latest/download/linpeas.sh | bash
linPEAS colorizes findings by severity (red = highly likely PE vector, yellow = interesting). Review all red findings first. Add linPEAS scans to your vulnerability management program for production servers -- run it under the application service account to reflect the realistic attacker perspective.
The bottom line
Linux privilege escalation paths cluster around four misconfiguration categories: SUID/capability binaries that are on GTFOBins, NOPASSWD sudo rules on exploitable commands, cron scripts that are writable or call binaries without full paths, and world-writable sensitive files. Run these 12 checks from the application service account's perspective on every production server. Automated tools like linPEAS accelerate discovery but do not replace understanding of why each finding is exploitable.
Frequently asked questions
Which Linux privilege escalation technique is most commonly found in real production environments?
In production server audits, the most common finding is overly permissive sudo rules -- specifically NOPASSWD rules on commands like vim, find, python, or custom scripts that were added for operational convenience and never reviewed. The second most common is non-standard SUID binaries (such as a development tool that was installed with SUID for local testing and never removed). GTFOBins exploitation of these findings is well-documented and exploitable without any exploit code.
How do I monitor for privilege escalation attempts on production Linux servers?
Enable auditd and configure rules to monitor: `sudo` command execution (all executions, not just failures), SUID binary execution attempts, and `/etc/passwd` and `/etc/shadow` access. Key auditd rules: `-a always,exit -F arch=b64 -S execve -F uid!=0 -k exec_as_user` and `-w /etc/passwd -p wa -k passwd_changes`. Forward auditd logs to your SIEM and alert on: non-root users executing commands as root via sudo, modifications to /etc/sudoers, and any process setting UID to 0.
How do I safely remove a SUID bit that may be needed by a legitimate application?
Before removing a SUID bit, verify which applications use the binary: `lsof | grep binary-name`, check package manager documentation for the binary's purpose, and if possible test in a staging environment. For critical binaries like `passwd` (requires SUID to modify /etc/shadow), removing SUID breaks the application. Use `chmod u-s` to remove and monitor for application errors. If application breaks occur, restore with `chmod u+s` and document the business justification for the SUID bit in your exception register.
Is running linPEAS safe to run on production servers?
linPEAS is a read-only enumeration script -- it does not exploit vulnerabilities or modify system state. It reads configuration files, checks permissions, and queries running processes. The risks of running it on production are: it may trigger security monitoring alerts (the file reads and process queries are distinctive), it writes its output to /tmp by default (which may be monitored), and on very resource-constrained servers the scanning activity may briefly increase CPU usage. Run it during a maintenance window or low-traffic period, and notify your security monitoring team in advance to avoid incident response triggers.
What is the most common Linux privilege escalation path found in enterprise environments?
Misconfigured sudo rules are the most common enterprise Linux privilege escalation path. The pattern: a service account or developer account has a sudo entry allowing execution of a specific command (e.g., `someuser ALL=(ALL) NOPASSWD: /usr/bin/vim`), and an attacker or auditor discovers that the allowed command can spawn a shell (vim can run `:!bash`, python can run `os.system('/bin/sh')`, find can use `-exec`). GTFOBins (gtfobins.github.io) catalogs which commands can be abused for privilege escalation when run with elevated privileges. Audit your sudoers configuration quarterly using `sudo -l` for each non-root account and cross-reference against GTFOBins.
How do SUID/SGID binaries create privilege escalation risk and how do I audit for them?
SUID (Set User ID) binaries run with the file owner's permissions rather than the calling user's permissions. If a binary owned by root has the SUID bit set, any user who can execute it runs it as root. Many legitimate SUID binaries exist on Linux systems (passwd, ping, sudo itself). The risk arises when custom or third-party binaries have SUID set unnecessarily, or when a SUID binary has a vulnerability that allows the calling user to influence its execution in unintended ways. Audit SUID binaries with: `find / -perm -4000 -type f 2>/dev/null` for SUID and `find / -perm -2000 -type f 2>/dev/null` for SGID. Compare the results against a known-good baseline from a clean system installation. Any SUID binary not on the baseline is a finding. Remove SUID bits from any binary that does not require it: `chmod u-s /path/to/binary`. Custom application binaries should never have SUID set -- use sudo rules or capability-based privilege (setcap) instead.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.