Quick answer

The best defence against LinPEAS is to run it yourself: execute it on your own Linux hosts exactly as an attacker would, fix the red findings first, then work down through yellow. Every finding LinPEAS reports is something a real intruder would also find — remediate in priority order and re-run to confirm.

Think like the tool#

LinPEAS does not exploit anything — it lists misconfigurations an attacker could exploit. That makes it a perfect hardening checklist: schedule regular runs on production hosts (maintenance windows; it is CPU-intensive), save the output, and treat each flagged item as a ticket. The sections below map each major vector to its fix; deeper walkthroughs live on the linked pages.

Fix red findings first#

LinPEAS flagsFix
Overly broad sudo rulesLeast privilege in /etc/sudoers; remove NOPASSWD where unjustified. See the sudo guide.
Dangerous SUID binariesRemove the SUID bit (chmod u-s) where unneeded. See the SUID guide.
Writable cron scripts / pathsRoot-owned, non-writable scripts; absolute paths in crontabs. See the cron guide.
Dangerous capabilitiesDrop with setcap -r; justify every remaining cap. See the capabilities guide.
World-writable sensitive filesTighten ownership and modes; audit /etc/passwd and /etc/shadow. See the permissions guide.
Kernel CVEsPatch; confirm backports via your distro tracker rather than version strings. See the kernel guide.
Docker group / socket exposureRemove users from the docker group; never expose the socket to untrusted users. See the Docker guide.

Harden systematically, not just the flags#

  • Remove stale user accounts and audit group memberships (sudo, docker, lxd).
  • Enforce SSH key hygiene and rotate credentials found in files, history and environment variables.
  • Keep an allow-list of expected SUID binaries and capabilities; alert on drift.
  • Patch on a schedule — kernel and software CVEs are the long tail LinPEAS keeps finding.

Detecting LinPEAS on your systems#

You cannot prevent an attacker with a shell from trying enumeration, but you can notice it:

  • Process monitoring / EDR: a sudden burst of enumeration commands (find / sweeps, getcap -r, mass sudo -l) is a strong signal.
  • File integrity: alert on linpeas.sh appearing in /tmp or /dev/shm.
  • Logs: centralise auth and sudo logs; look for enumeration patterns preceding privesc attempts.
  • Canaries: honeypot credentials or files that no legitimate process touches.

Build the loop#

  1. 1

  2. 2

  3. 3

  4. 4

Prioritising with limited time#

If you cannot fix everything this sprint, order the work by blast radius:

  1. Internet-facing hosts first — they are probed constantly.
  2. Privileged vectors first — anything giving instant root (writable cron as root, NOPASSWD sudo, CAP_SETUID on odd binaries) outranks info leaks.
  3. Credential exposure next — keys and passwords in files are one step away from lateral movement.
  4. Then the long tail — kernel patching, informational findings, documentation of accepted risks.

Making detection practical#

You do not need a full SOC to notice enumeration. Start with the cheap signals: alert when linpeas.sh (or any new executable) appears in world-writable directories, watch for bursts of sudo -l or recursive find / in process logs, and make sure sudo and authentication logs actually reach a central store instead of living only on the host being attacked. Tune from there — the first alert that fires during a real test is worth more than a perfect ruleset that never does.

Is running LinPEAS on my own servers safe?

Yes — it is read-only enumeration. Schedule it in maintenance windows because it is CPU-intensive, and keep the output (which may contain credential fragments) somewhere access-controlled.

We fixed everything red and LinPEAS still reports yellow items. Are we done?

No — yellow means worth investigating. Some will be by design (document and accept the risk); the rest are your next tickets. Security is the loop, not a single clean run.

Can we block LinPEAS from running at all?

Not reliably against an attacker who already has a shell — they can rename it, obfuscate it, or enumerate manually. Invest in detection and in removing the findings instead.

How often should we re-run it?

After every significant change (deploys, new packages, user changes) and on a regular schedule — monthly is a sane default for most estates.

Sources & references

  1. PEASS-ng (official) — Run the same tool attackers run; reviewed 20260908-dffb9496.
  2. HackTricks: Linux privesc (know what to fix)