2 AM. My phone buzzes. A Grafana alert: an unknown user is running a cron job with root privileges on the production server. I jump in to investigate and realize — the server has been compromised. The attacker escalated privileges through a service account that had been forgotten for years.
It wasn’t the first time. A few years earlier there was an SSH brute-force incident, also in the middle of the night, also patched manually in a half-asleep haze. After that, I switched to proactive auditing — running LinPEAS on every new server I set up or inherited from someone else, before anyone has a chance to exploit it.
Run LinPEAS in 5 Minutes
A single bash script. No installation, no build step — download and run:
# Option 1: Download and run directly
curl -L https://github.com/peass-ng/PEASS-ng/releases/latest/download/linpeas.sh | sh
# Option 2: Download first (recommended on production)
wget https://github.com/peass-ng/PEASS-ng/releases/latest/download/linpeas.sh
chmod +x linpeas.sh
./linpeas.shIf the server has no internet access, copy it over with scp from your local machine:
# From local machine
scp linpeas.sh [email protected]:/tmp/
# On the server
chmod +x /tmp/linpeas.sh
/tmp/linpeas.shAlways save the output for later analysis — don’t let it scroll past and disappear:
./linpeas.sh 2>/dev/null | tee linpeas_output.txtLinPEAS Color Coding — Spot Issues in Minutes, Not Hours
LinPEAS output is long, sometimes over 1,000 lines. Fortunately, you don’t need to read all of it. Understand the color system and you’re done in a few minutes:
- Red/Bold Yellow: 95% likely to be a privilege escalation vector — check immediately
- Light Yellow: Worth noting, needs further review
- Green: Useful information but not directly dangerous
- Blue / No color: Raw system data for reference
Simple rule: start with red. Only move to yellow if there’s nothing red.
Main Check Categories in LinPEAS
- SUID/SGID binaries: Files with the SUID bit set — the most common source of privilege escalation
- Sudo rules: Commands allowed to run via sudo without a password
- Cron Jobs: Scripts running on a schedule with root privileges that regular users can write to
- Writable paths in PATH: Writable directories in root’s PATH
- Users & Groups: Who belongs to the docker, sudo, lxd, and adm groups
- Credentials: Config files containing plaintext passwords, unprotected SSH keys
- Container checks: Whether you’re inside Docker/LXC and whether container escape is feasible
- Kernel exploits: Suggested exploits based on the current kernel version
Reading Results — Don’t Read Line by Line
Filter straight to the dangerous sections. Reading top to bottom is just wasting time:
# Filter lines flagged as 95% dangerous
grep -a "95%" linpeas_output.txt
# View the entire SUID section
grep -a -A 30 "SUID - Check" linpeas_output.txt
# View sudo rules
grep -a -A 20 "Sudo version" linpeas_output.txt
# Find suspicious cron jobs
grep -a -A 20 "Cron jobs" linpeas_output.txtThe Three Most Common Dangerous Findings
1. SUID bit on a non-standard binary:
# LinPEAS reports:
-rwsr-xr-x 1 root root 12345 Jan 1 00:00 /usr/local/bin/custom-tool
# Check that binary on GTFOBins:
# https://gtfobins.github.io/
# If it's listed there — that's a vulnerability that needs to be patched immediately2. Overly permissive sudo rules:
# Dangerous output:
(ALL) NOPASSWD: /usr/bin/vim
(ALL) NOPASSWD: /usr/bin/python3
# With vim, privilege escalation takes just one command:
sudo vim -c ':!/bin/bash'
# With python3:
sudo python3 -c 'import os; os.system("/bin/bash")'3. Root cron job running a writable script:
# LinPEAS finds in crontab:
* * * * * root /opt/maintenance/cleanup.sh
# Check file permissions:
ls -la /opt/maintenance/cleanup.sh
# If world-writable or group-writable and you belong to that group:
# → Injecting a command into the script is enough to run code as rootCustomizing LinPEAS When Needed
By default LinPEAS scans everything — taking around 3–5 minutes. To run faster or focus on a specific area, use these options:
# Check network only
./linpeas.sh -o network
# Check processes and services only
./linpeas.sh -o procs_crons_timers_srvcs_sockets
# Skip network scan (faster, less noise)
./linpeas.sh -s
# Run with timeout to avoid blocking too long on production
timeout 300 ./linpeas.sh 2>/dev/null | tee linpeas_output.txt
# View all available options
./linpeas.sh -hOn production servers, I usually run with the -s flag — skipping the network scan makes it faster and reduces load on the system.
Running Without Leaving Files on Disk
In pentesting or when you need to minimize artifacts, use this approach:
# On the auditor's machine — set up a temporary HTTP server
python3 -m http.server 8080
# On the target server (script runs in RAM, no file created)
curl http://AUDITOR_IP:8080/linpeas.sh | bash 2>/dev/null | tee /dev/shm/result.txtLessons Learned After Running LinPEAS in the Field
Run as a low-privileged user, not root. LinPEAS gives the most realistic results when run as a regular user — exactly the scenario where an attacker already has a shell and wants to escalate to root. Running it as root produces different output that’s far less useful.
# Switch to a service account user to test
su - webapp_user
./linpeas.sh 2>/dev/null | tee /tmp/linpeas_webapp.txtSave output by date and diff to detect unexpected changes. A new SUID file or unfamiliar cron job appearing between two runs is a signal that warrants immediate investigation:
# Name files by date
./linpeas.sh 2>/dev/null | tee "linpeas_$(date +%Y%m%d).txt"
# Compare with the previous run
diff linpeas_20260601.txt linpeas_20260701.txt | grep "^[<>]" | head -50Kernel exploits — extreme caution on production. LinPEAS suggests kernel exploits based on the kernel version. On CTFs, go ahead and try them. On real production systems: don’t run them. Kernel exploits can crash the entire system. Note the kernel version and then update to a patched release — that’s enough.
Check GTFOBins immediately when you see an unusual SUID or sudo rule. The site gtfobins.github.io lists exploitation techniques for Linux binaries. Any binary listed there that your server has set with SUID or sudo NOPASSWD — fix it tonight, don’t wait until morning.
Post-LinPEAS Remediation Checklist
- Remove SUID bit from unnecessary binaries:
chmod u-s /path/to/binary - Tighten sudo rules — use absolute paths, restrict arguments, remove NOPASSWD where not required
- Check and set correct permissions on every script called by root’s cron:
chmod 750, owned by root - Audit group membership — remove regular users from
docker,sudo, andadmif they don’t need it - Update the kernel if a serious CVE is being suggested
- Find and encrypt or remove plaintext credentials in config files
LinPEAS is an offensive tool — its goal is to find every exploitable weakness. Use it from the defensive side: run it before the attacker does, find issues first, patch first. After that SSH brute-force incident years ago, I started running LinPEAS on a monthly schedule across all servers. It beats sitting around waiting for your phone to buzz at 2 AM.
