Quick answer

In the “Files with Interesting Permissions” section, LinPEAS lists SUID and SGID binaries and highlights ones with known abuse paths. A red/yellow SUID line is a high-priority lead — but you still confirm the binary is actually exploitable in your context before acting. Everything below assumes an authorised lab, CTF, or pentest target.

Where it appears in the output#

SUID/SGID checks live in the Files with Interesting Permissions section (the interesting_perms_files target for -o). LinPEAS enumerates every set-UID and set-GID binary on the filesystem, then compares the list against its built-in registry of binaries with known privilege-escalation techniques. Binaries on that registry get highlighted; everything else is listed for completeness.

How to read the highlights#

LinPEAS uses the standard colour legend here. For SUID/SGID entries it means:

HighlightMeaningWhat to do
Red/yellowBinary has a known abuse path in the LinPEAS registryInvestigate first — highest priority
RedSuspicious or non-standard SUID binaryIdentify it; check version and GTFOBins
GreenCommon SUID binary matched by name (passwd, sudo)Usually expected — but still glance at it
UncolouredListed for completenessLow priority unless unusual
Highlight ≠ exploit

A highlighted SUID binary is only exploitable if its version and configuration allow it. pkexec, for instance, was famously exploitable via CVE-2021-4034 (PwnKit) but is fixed on patched systems. The highlight is a lead, not proof — always verify the version.

Reproduce the enumeration manually#

LinPEAS is doing the equivalent of these commands. Running them yourself confirms the finding and teaches you what the script saw:

Reproduce the SUID/SGID enumeration
find / -perm -4000 -type f 2>/dev/null   # all SUID binaries
find / -perm -2000 -type f 2>/dev/null   # all SGID binaries
ls -l /usr/bin/find                       # confirm the SUID bit (-rwsr-xr-x)
dpkg -l | grep -i <package>               # version of the owning package (Debian/Ubuntu)

From a highlighted binary to a tested technique (authorised lab)#

The standard workflow, used in OSCP-style labs and authorised pentests, is:

  1. 1

  2. 2

  3. 3

  4. 4

Authorised use only

Run these tests only on systems you are explicitly authorised to test — your own lab VMs, CTF targets, or a contracted pentest scope. Testing SUID abuse on any other system is unauthorised access.

Binaries that show up most often#

These appear regularly in LinPEAS output and have documented GTFOBins SUID techniques. Presence alone is not a vulnerability — context and version decide:

BinaryWhy it matters
findCan execute arbitrary commands via -exec
vim / nvimCan spawn a shell with :!/bin/sh
less / more / manShell escape with !sh
awkCan run system commands and read files as the owner
bash / dashSUID shell — check -p behaviour
nanoCan read/write files as owner via ^R^X
cp / mvCan overwrite sensitive files (e.g. /etc/passwd)
envCan launch a shell preserving the SUID context
perl / python* / phpScripting engines — arbitrary code as owner
nmap (old)Legacy interactive mode gave a shell; modern builds removed it
pkexecCheck version — CVE-2021-4034 (PwnKit) if unpatched
passwd, chsh, suNormally expected SUID root — baseline, not findings

How to fix SUID findings (defensive)#

If you are hardening the system LinPEAS audited, work through the highlighted binaries:

  • Remove the SUID bit where the binary does not need it: chmod u-s /path/to/binary.
  • Prefer Linux capabilities (e.g. cap_net_raw) over full SUID root — they grant less power.
  • Keep packages updated: many SUID CVEs (PwnKit, Baron Samedit) are fixed by patching.
  • Audit on a schedule — package updates can re-add SUID bits; re-run LinPEAS after changes.
  • On immutable or container images, drop SUID binaries you do not need from the image entirely.
Note

Defenders should run LinPEAS on their own hosts exactly as an attacker would. Whatever it highlights in red/yellow is what a real intruder would try first — fix those findings before anything else.

Quick triage checklist#

  • Note every red/yellow SUID line and its full path.
  • Confirm each is SUID root (ls -l), not SUID to another user.
  • Check the owning package version for known CVEs.
  • Look the binary up on GTFOBins → SUID section.
  • Test the technique in your authorised lab; record what worked.
  • Report the binary path, version and exact reproducing command.

For the underlying concept, read what is SUID? and what is SGID?. Related checks: file permissions and sudo.

SGID: the overlooked twin#

SGID (set-group-ID) gets less attention than SUID but follows the same logic: the binary runs with its group's privileges. That matters when the group is powerful:

  • An SGID binary owned by group shadow may read /etc/shadow — hashes without being root.
  • SGID on directories is different: new files inherit the directory's group — a collaboration feature, rarely a vector, but worth knowing so you do not misread it.
  • LinPEAS lists SGID binaries in the same section; triage them exactly like SUID — full path, owning group, GTFOBins lookup.
Enumerate SGID separately
find / -perm -2000 -type f 2>/dev/null   # SGID binaries
ls -l /usr/bin/write   # classic SGID tty group example

Capabilities: the modern alternative to SUID#

Linux capabilities split root's power into pieces, so a binary can get just what it needs instead of full SUID root. LinPEAS reports binaries with elevated capabilities because some are escalation-equivalent:

  • cap_setuid / cap_setgid — become any user directly.
  • cap_sys_admin — the “new root”: mounts, namespaces, and more.
  • cap_dac_read_search / cap_dac_override — read or write any file, including /etc/shadow.
  • cap_net_raw / cap_net_admin — usually fine; needed by ping and friends.
Reproduce the capability enumeration
getcap -r / 2>/dev/null   # binaries with capabilities
/usr/sbin/getcap -r /usr/bin /usr/sbin 2>/dev/null

Defensively, replacing SUID with a narrow capability is an upgrade — but audit the capability list with the same suspicion you give SUID.

Baseline your system#

The fastest way to spot a new rogue SUID binary — the kind an attacker plants — is to know what the baseline looks like:

SUID baseline and drift check
# store a baseline (on a clean system)
find / -perm -4000 -type f 2>/dev/null | sort > /root/suid.baseline
# later: diff the current state against it
find / -perm -4000 -type f 2>/dev/null | sort | diff /root/suid.baseline -

Package updates legitimately add or remove SUID binaries, so review diffs rather than alerting on any change — but an unexpected binary with no package owner (dpkg -S / rpm -qf find nothing) deserves immediate investigation.

Sources & references

  1. linPEAS README
  2. PEASS-ng release — reviewed 20260908-dffb9496
  3. HackTricks: Linux privilege escalation