Why we need privilege escalation

Our initial access to a remote server is usually in the context of a low-privileged user, which would not give us complete access over the box. For example, some commands (like tcpdump) cannot be run via sudo and can only be run by the root user. To gain full access, we will need to find an internal/local vulnerability that would escalate our privileges to the root user on Linux or the administrator/SYSTEM user on Windows.

Privilege escalation techniques

Check the Linux privilege escalation checklist or the Windows escalation checklist for steps to take.

Many of the above commands may be automatically run with a script to go through the report and look for any weaknesses. We can run many scripts to automatically enumerate the server by running common commands that return any interesting findings. Some of the common Linux enumeration scripts include LinEnum and linuxprivchecker, and for Windows include Seatbelt [github] and JAWS.

Vulnerable OS or software

Once these scripts have been run, look for vulnerable kernels and software versions (dpkg -l on Linux or C:\Program Files for WIndows).

Sudo hacking

Check your privileges using:

sudo -l

And if you can run all commands, switch to root like this:

sudo su -

There are certain occasions where we may be allowed to execute certain applications, or all applications, without having to provide a password:

Privilege Escalation

brianhaddock@htb[/htb]$ sudo -l

    (user : user) NOPASSWD: /bin/echo

The NOPASSWD entry above shows that the /bin/echo command can be executed without a password for the “user” user. To do so, we can specify the user with -u user:

Privilege Escalation

brianhaddock@htb[/htb]$ sudo -u user /bin/echo Hello World!

    Hello World!

Once we find a particular application we can run with sudo, we can look for ways to exploit it to get a shell as the root user.

Scheduled tasks

You may be able to escalate privileges through a script that can be dropped in a scheduler directory (e.g. /etc/crontab, /etc/cron.d, or /var/spool/cron/crontabs/root).

Exposed credentials

Next, we can look for files we can read and see if they contain any exposed credentials. This is very common with configuration files, log files, and user history files (bash_history in Linux and PSReadLine in Windows).

SSH keys

If we have read access over the .ssh directory for a specific user, we may read their private ssh keys found in /home/user/.ssh/id_rsa or /root/.ssh/id_rsa, and use it to log in to the server. If we can read the /root/.ssh/ directory and can read the id_rsa file, we can copy it to our machine and use the -i flag to log in with it:

brianhaddock@htb[/htb]$ vim id_rsa
brianhaddock@htb[/htb]$ chmod 600 id_rsa
brianhaddock@htb[/htb]$ ssh root@10.10.10.10 -i id_rsa

root@10.10.10.10#

Note that we used the command ‘chmod 600 id_rsa’ on the key after we created it on our machine to change the file’s permissions to be more restrictive. If ssh keys have lax permissions, i.e., maybe read by other people, the ssh server would prevent them from working.

Also, make sure there is a blank line at the end of the private key file (i.e. id_rsa).