4) CronJobs
    4.1) CronJobs - File Permissions
    4.2) CronJobs - Path Environment Variables
    4.3) CronJobs - Wildcards

The involves looking for instances in which a cronjob touches a writable root file we can overwrite. Taking a look at /etc/cronjob/ we can see which files have a cron schedule.

Notice how overwrite.sh has root permissions. We can then inject malicious code into overwrite.sh  which will get executed with root permissions. Check you can overwrite it:

Overwrite the file with malicious code (reverse shell) of yours. Mine is shown below:

Set up a listener and wait for the cronjob to run the file which we've just placed malicious code into. Root access achieved below

Here we are going to hijack the PATH variable of the overwrite.sh. Look at the image below and notice how the overwrite.sh file does not have an exact path. This means we could hijack it:

Create a file called overwrite.sh in the home directory. Place malicious code into our overwrite.sh. Mine is a simple reverse shell from earlier

Create the listener with Netcat and wait for root shell.

We can also abuse wildcards to try and get root. Lets look at the file /usr/local/bin/compress.sh which also has root privileges

Notice how it uses a tar command with a wildcard? this is something we can exploit. If we can create a file with the same names as arguments which are passed to the tar command we can get it to execute malicious code.
Create two files using the following command:

Have a listener set up to receive the connection. Once the cronjob runs, it will run compress.sh which will run the tar command, which executes our malicious shell.sh with root privileges. 

2) Shell Escape Sequences
3) Sudo  Environment Variable Hijacking

whatever you want to call it, this involves using native binaries and their functions to achieve root privileges. First step is finding out which binaries run as root:

Then compare this list with GTFOBins. See if you can use them to get root as shown below:

Another example using apache2 to read /etc/shadow

sudo can inherit environment variables, you can check for these by doing sudo -l as shown above. Keep an eye out for env_keep*

• LD_PRELOAD is inherited from the users environment. It can preload shared object libraries before the program runs 
• LD_LIBRARY_PATH provides a list of directories to search for shared object libraries.

The goal to is "hijack" these enviroment variables with a malicious shared object library. First we must create a Shared Object Library called preload.so.

This is the original C code below:

We can now run a program which was listed when we did "sudo -l" (in this case its iftop) and load the malicious shared object library via LD_PRELOAD:

We will now do something very similar but with LD_LIBRARY_PATH. This involves creating a malicious shared library with the same name as an incumbent library and hijacking LD_LIBRARY_PATH. We'll be attacking the apache2 binary. First find out which libraries are loaded by apache2:

Now create a malicious shared object library name with the same name as an already existing library

The original C code of library_path.c

Next, provide the path containing the malicious library while executing the sudo binary: