linpeas scans a low priv shell for near certain privesc wins

hook

if you've ever landed a low priv shell on a box (your own box, in your own lab, doing your own audit) you know the feeling. you're in, but you're nobody. no root, no idea what's misconfigured, hundreds of possible paths to check by hand. linpeas exists because nobody wants to manually grep through cron jobs and sudoers files at 2am. it automates the recon and color codes what it finds so you know exactly where the easy wins are. that's useful for attackers, sure, but it's arguably more useful for you, the person who actually owns the system and needs to find the hole before someone else does.

what linpeas actually does

linpeas is a script that crawls a linux system looking for privilege escalation paths. it checks kernel version, suid binaries, cron jobs, writable files owned by root, sudo permissions, capabilities, docker group membership, and a few hundred other things that historically have been used to go from a low priv user to root. it doesn't exploit anything itself, it just reports. the output is color coded: red and yellow usually mean "this is very likely exploitable," everything else is context.

the command from the clip looks like this:

curl -sL https://github.com/.../linpeas.sh | sh | tee peas.txt

breaking it down: curl -sL silently downloads the script and follows any redirects. piping straight into sh runs it immediately without saving it first. tee peas.txt splits the output so it prints to your screen and also saves a copy to a file for later review. that's the whole pipeline, download, run, log.

the sudo example, explained

one of the most common red flags linpeas surfaces is a sudo rule that lets a user run a binary as root that was never meant to be a privesc vector. the example shown is find. if a sudoers entry lets a low priv user run find as root with no restrictions, gtfobins documents the exact one liner to turn that into a root shell:

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

find has a legit feature to execute a command on every file it finds. if you can run find as root, you can tell it to execute /bin/sh instead, and now you have a root shell. this isn't a bug in find, it's a misconfiguration in how sudo access was granted. the tool did exactly what it was told to do.

why this matters for defenders

the actual lesson here isn't "run linpeas to get root." it's "run linpeas against your own systems before someone else does, and fix everything it flags red." every single privesc path linpeas checks for is a path a real attacker's tooling checks for too. linpeas is basically a free audit checklist written by people who've spent years cataloging what actually works.

run it on your own servers, your own vms, your own containers, anything you're responsible for. save the output with tee like the example does, so you have a record to work through instead of scrolling terminal history. then go section by section and ask yourself why each red item exists. does that cron job really need to be writable by a non root user. does that sudoers line really need to allow unrestricted access to a binary that can spawn a shell.

fixing what linpeas finds

for sudo misconfigurations specifically, the fix is almost always to scope the rule down. instead of granting a user sudo access to an entire binary, restrict it to specific arguments, or better, restrict it to a wrapper script that only does the one narrow thing the user actually needs. check your sudoers file directly:

sudo -l

that command shows you exactly what the current user is allowed to run as root, which is the same first move an attacker makes and the same first move you should make on your own boxes. cross reference anything listed against gtfobins yourself, if it's on that list as an escalation vector, your rule is too broad.

beyond sudo, go after the other common categories linpeas flags: suid binaries that shouldn't have the bit set, world writable files in system directories, cron jobs calling scripts an unprivileged user can edit, and services running with capabilities they don't need. each one is a small door left open, and linpeas just tells you where all the doors are.

the takeaway

linpeas isn't magic and it isn't just an attacker's toy. it's a mirror. run it on systems you own, read the red output like a to-do list, and close every item before it becomes someone else's easy win. the best defense against a tool like this being used against you is running it against yourself first.