By now, you should have an understanding of basic privilege escalation techniques and how to enumerate and exploit them. This room will take this one step further and expand your arsenal with tools that can automate this process or help you find hidden privilege escalation vectors.

Learning Objectives

• Demonstrate privilege escalation enumeration using automated tools
• Demonstrate privilege escalation techniques using public exploits
• Understand Linux process snooping

Prerequisites

• Linux Privilege Escalation: Enumeration
• Linux Privilege Escalation: Basics

Several tools can help you save time during the enumeration process. These tools should only be used to save time, knowing they may miss some privilege escalation vectors. Below is a list of popular Linux enumeration tools with links to their respective GitHub repositories.

The target system's environment will influence the tool you will be able to use. For example, you will not be able to run a tool written in Python if it is not installed on the target system. This is why it would be better to be familiar with a few rather than having a single go-to tool.

• LinPeas: Automated script that highlights privilege escalation paths across the system — misconfigs, weak permissions, credentials, and more
• LinEnum: Scripted local enumeration tool that dumps system info, users, crons, and SUID binaries in a readable report
• LES (Linux Exploit Suggester): Matches the kernel version against known CVEs and suggests applicable local privilege escalation exploits
• Linux Smart Enumeration: Enumeration script with adjustable verbosity levels — starts quiet and reveals more detail as the level increases
• Linux Priv Checker: Enumerates system info and automatically checks for common privilege escalation opportunities, flagging issues inline

Public Exploits

Many privilege escalation techniques rely on misconfigurations; a sudo rule that's too permissive, a cron job calling a world-writable script, or a capability assigned to a binary that shouldn't have one. In these cases, the software is working exactly as designed; someone just configured it poorly.

Public exploits are different. Here, the software itself is broken. A bug in the code (a buffer overflow, a race condition, a logic error) allows you to do something the developers never intended. When these bugs are discovered, they're assigned a CVE (Common Vulnerabilities and Exposures) identifier, and often, working exploit code is published publicly.

Methodology

Using a public exploit isn't just about downloading code and running it. There's a process, and skipping steps is how you crash machines or waste hours on exploits that were never going to work. The general workflow looks like this:

• Enumerate: Identify what software is installed and what versions are running. You already know how to do this from the enumeration lab. Key things to note: kernel version, distro version, and any SUID binaries or services running as root.
• Research: Take what you found and search for known vulnerabilities. Is there a CVE for that version? Is there a public exploit available? Does it match your target's architecture and distribution?
• Evaluate: Not every exploit you find will work. Read the code. Understand what it does. Check the requirements: does it need gcc on the target? Does it only work on specific kernel versions? Will it crash the system?
• Exploit: Transfer the exploit to the target, compile it if necessary, and run it.
• Verify: Confirm you have elevated privileges. Check whoami, id, and try accessing something you couldn't before.

Where to Find Public Exploits

There are several go-to resources for finding exploit code. You should be comfortable using all of them.

searchsploit (Exploit-DB offline)

searchsploit is a command-line tool that searches a local copy of the Exploit-DB database. It comes pre-installed on Kali.

Usage:

searchsploit <software> <version>

GitHub

GitHub has many repositories containing public exploits for known CVEs. If you ever find a CVE for a specific software version, you can do a Google search for a GitHub repository.

CVE-<id> github

Enumeration Tools

Tools like Linpeas don't just identify misconfigurations — they also check for known CVEs. If Linpeas flags a vulnerable version of software, it will often include the CVE number, which gives you a direct starting point for your research.

Kernel Exploits

The kernel is the most privileged piece of software on a Linux system. A vulnerability in the kernel can allow you to jump straight from an unprivileged user to root, regardless of how well everything else is configured.

Reminder on how to enumerate the kernel version on a target:

uname -r

uname -a

cat /etc/os-release

Then search for known exploits against that version using searchsploit or Google.

Non-Kernel Public Exploits

Not all public exploits target the kernel. Many privilege escalation CVEs exist in userland software — programs and utilities that happen to run with elevated privileges. These are often easier to exploit and less likely to crash the system.

Next, you will have to use a public exploit to gain root privileges on the lab machine. Previously, you identified that the target is vulnerable to a CVE. Now you have to exploit this to gain root privileges. You can find the exploit on GitHub, download it onto your AttackBox, then upload it onto the target using scp.

scp <file> john@MACHINE_IP:/home/john/

The Polling Issue

While the automated tools mentioned in the previous task are excellent at enumerating static misconfigurations, they only capture a snapshot of the system at the time they run. They can't tell you what processes are running in the background, especially short-lived ones like cron jobs or scheduled scripts that execute and exit in milliseconds. This is where pspy fills the gap.

pspy is a process monitoring tool that lets unprivileged users observe running processes, cron jobs, and commands executed by other users in real time, without requiring root privileges.

Event-driven Approach

On Linux, processes are isolated — low-privileged users can only see their own processes via /proc. Short-lived tasks (like cron jobs) may exit before anyone can observe them, making traditional polling tools unreliable for discovery.

pspy uses an event-driven approach instead of polling. It sets inotify watches on commonly accessed directories (e.g., /etc, /tmp, /usr, /var). When filesystem activity is detected, pspy scans /proc to identify the new process, capturing its UID, PID, timestamp, and full command — even for processes run by other users.

This works because process metadata in /proc is briefly available during a process's lifetime, even to unprivileged users. pspy doesn't bypass any kernel permissions — it just reacts fast enough to catch what polling tools miss.

Using pspy

pspy can be found in /home/john/.

Run pspy from john's home directory as such:

./pspy64

After a short delay, you should see a root process, similar to the example below.

           
2026/02/10 06:40:11 CMD: UID=0     PID=12     |
2026/02/10 06:40:11 CMD: UID=0     PID=11     |
2026/02/10 06:40:11 CMD: UID=0     PID=10     |
2026/02/10 06:40:11 CMD: UID=0     PID=9      |
2026/02/10 06:40:11 CMD: UID=0     PID=8      |
2026/02/10 06:40:11 CMD: UID=0     PID=7      |
2026/02/10 06:40:11 CMD: UID=0     PID=6      |
2026/02/10 06:40:11 CMD: UID=0     PID=5      |
2026/02/10 06:40:11 CMD: UID=0     PID=4      |
2026/02/10 06:40:11 CMD: UID=0     PID=3      |
2026/02/10 06:40:11 CMD: UID=0     PID=2      |
2026/02/10 06:40:11 CMD: UID=0     PID=1      | /sbin/init
2026/02/10 06:40:16 CMD: UID=0     PID=1937   | /bin/bash /root/run-backup.sh
2026/02/10 06:40:16 CMD: UID=0     PID=1938   | tar -czf /var/backup/syslog.tar.gz /var/log/syslog
2026/02/10 06:40:16 CMD: UID=0     PID=1939   | /bin/sh -c gzip
2026/02/10 06:40:16 CMD: UID=0     PID=1940   | gzip
2026/02/10 06:40:16 CMD: UID=0     PID=1941   | sleep 10
2026/02/10 06:40:16 CMD: UID=0     PID=1942   | /bin/bash /root/run-rm-tmp.sh
2026/02/10 06:40:16 CMD: UID=0     PID=1943   | /bin/bash /usr/local/bin/rm-tmp.sh
2026/02/10 06:40:16 CMD: UID=0     PID=1944   | /bin/bash /usr/local/bin/rm-tmp.sh
2026/02/10 06:40:16 CMD: UID=0     PID=1945   |
2026/02/10 06:40:16 CMD: UID=0     PID=1946   | chpasswd
2026/02/10 06:40:16 CMD: UID=0     PID=1948   | /bin/bash /root/run-rm-tmp.sh

        

As you can see, root (UID=0) is running a script in the /root folder (which is not accessible by low-level users) and another one in /usr/local/bin.

Checking the file permissions and contents reveals the following:

           john@privesc:~$ ls -la /usr/local/bin/rm-tmp.sh
-rwxrwxrwx 1 root root 57 Jan 20 10:27 /usr/local/bin/rm-tmp.sh
john@privesc:~$ cat /usr/local/bin/rm-tmp.sh
#!/bin/bash

rm -r /tmp/*

It appears that this script is meant to clear the /tmp folder; however, since the script is world-writable and runs in a loop as root, you can add your own command to escalate privileges. In the example below, a command was added to change the root password.

           #!/bin/bash

rm -r /tmp/*
echo "root:newpass" | chpasswd

Finally, you can log in as the root user by just calling the su command and inputting the new password.

           john@privesc:~$ su
Password:
root@privesc:/home/john#

Next, you will have to use pspy to facilitate the exploitation of a similar scenario and gain root privileges.

It is now time for you to apply the privilege escalation techniques you've learned to enumerate and exploit the lab machine. If you need any tools, feel free to download them onto your attacker machine, then upload them onto the target using scp.

scp <file> john@MACHINE_IP:/home/john/

In this room, you sped up privilege escalation by adding automation to your workflow.

• You used automated enumeration tools to quickly surface misconfigurations and vulnerable software, learning that no single tool catches everything.
• You then worked with public exploits, following a clear methodology 
• Finally, with pspy, you covered the blind spot that scanners miss: short-lived processes. 

The takeaway: automation is a force multiplier, not a replacement for understanding. The tools show you where to look, but you still have to know what you're looking at.