You have user shell. sudo -l shows you can run /usr/bin/vim as root. Best next step?
Use allowed sudo command to obtain root (e.g., via vim shell escape) and then capture proof.
You find a root cron job running /opt/backup.sh, and the script is writable by your user. What do you do?
Edit the script to execute a safe root proof action/shell, then wait for cron and capture proof.
No sudo rights. You find SUID binary find owned by root. What does this imply?
Potential privesc if the binary can execute commands with elevated privileges; validate safely.
getcap -r / shows a binary with dangerous capability. Next step?
Research capability impact and test safe escalation technique; document steps and evidence.
You find creds in .bash_history for another user. Best next step?
Try switching user (su/ssh) and re-run enumeration for that user’s privileges.
You find /etc/passwd writable but /etc/shadow is not. What does that mean?
Limited usefulness; focus on writable root-run scripts/configs and sudo/SUID instead.
A service runs as root and reads config from /etc/service.conf which is writable by you. What do you do?
Modify config to execute benign root action or load attacker-controlled path (if applicable) and restart only if allowed.
Kernel version is old and public exploit exists. What’s the safe decision rule?
Use kernel exploit only if simpler paths fail and you’ve validated version/patch compatibility and risk.
You see a writable directory early in PATH used by a root script. What’s the privesc angle?
PATH hijacking: place a malicious binary with the same name as a called command.
You can read /var/www/html/config.php and it has DB creds. How can this help privesc?
DB creds may reuse system creds or grant access to admin panels/files; pivot and re-enumerate.
You’re in a Docker container with mounted host paths. What’s the key question?
Whether host filesystem/socket is exposed (e.g., docker.sock) enabling host-level actions.
You found SSH key file readable. Best next step?
Check permissions, whether it’s passphrase protected, and attempt authorized use to pivot.
A cron job runs every minute but you need proof quickly. What’s best?
Use the cron window to trigger your change; keep actions minimal and immediately capture proof.
