First you look, then you climb
You cannot exploit a mistake you have not found. Good privilege escalation is mostly patient enumeration — asking the system a short list of questions and reading the answers carefully. Here is the core list; every later module is really just one of these checks followed through.
1. What am I allowed to do with sudo?
Even a user who is not in the sudo group can sometimes be allowed to run one specific command as root. sudo -l lists exactly what:
sudo -lIn the terminal (type the student password (student) when it asks)
student@vulntech:~$ sudo -l Matching Defaults entries for student on vulntech: env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin, use_pty, lecture=never User student may run the following commands on vulntech: (ALL) NOPASSWD: /usr/bin/less
2. Which programs run as their owner (SUID)?
A file with the SUID bit runs with the privileges of its owner, not yours. A SUID-root program you can misuse is a direct ticket to root. List them all:
find / -perm -4000 -type f 2>/dev/nullIn the terminal
student@vulntech:~$ find / -perm -4000 -type f 2>/dev/null /usr/bin/chfn /usr/bin/chsh /usr/bin/find /usr/bin/gpasswd /usr/bin/mount /usr/bin/newgrp /usr/bin/passwd /usr/bin/su /usr/bin/sudo /usr/bin/umount /usr/lib/dbus-1.0/dbus-daemon-launch-helper
Many of those are normal (su, passwd, mount…). The skill is spotting the one that should not be there.
3. What is writable that should not be?
Files the system trusts but that you can write are gold. Two classics: the account database, and anything a root-owned job runs. Check their permissions:
ls -l /etc/passwd
ls -l /etc/cron.d/In the terminal
student@vulntech:~$ ls -l /etc/passwd -rw-rw-rw- 1 root root 1017 Oct 19 06:12 /etc/passwd student@vulntech:~$ ls -l /etc/cron.d/ total 2 -rw-r--r-- 1 root root 72 Oct 19 06:12 backup -rw-r--r-- 1 root root 199 Jun 6 2025 e2scrub_all -rw-r--r-- 1 root root 111 Oct 19 06:12 maint
A w in the wrong column — a world-writable /etc/passwd, a script in a root cron job that you can edit — is a way up. You will exploit each of these in the modules ahead.
Tip: Redirecting errors to nowhere with
2>/dev/null(as in thefindabove) hides the flood of ‘Permission denied’ messages so you see only the results that matter.