This is a TL;DR, due to the length of the writeup, I created the full post here.
HTB Guardian is a Linux machine that hides its real attack surface behind a classic port knocking defense which is basically its whole personality.
Your initial Nmap scan only shows three things: SSH on 22, Nginx on 80, and a suspicious filtered port 443. That filtered state is your first breadcrumb.
Digging into the web server on port 80 with Gobuster eventually surfaces a README.txt file that gives away the knock sequence: 7, 4, 6, 2.
Fire those off with the knock command, re-scan, and suddenly port 5000 opens up running a Flask/Werkzeug app called the "Guardian Angel Monitoring Dashboard."
The app has a login page with no obvious bypass, but further directory brute-forcing reveals an /api/check_service_status endpoint. It takes a service parameter and feeds it directly into a ping command classic command injection setup.
The filter blocks ;, &, and |, but a simple newline character (\n) in the JSON body bypasses it cleanly. Inject localhost\nwhoami and you get back svc_guardian in the response , code execution confirmed.
From there, base64-encode a bash reverse shell payload, inject it the same way, catch the callback on your Netcat listener, and stabilize with Python's pty module.
Once on the box as svc_guardian, the /app/.env file hands you everything:
SUPPORT_USER_PASS=GuardianSupport#2023!.
Switch to the support user with su, and sudo -l reveals you can run systemctl status guardian-watchdog.service as root without a password.
Since systemctl status pipes output through less, you can type !/bin/bash to escape to a root shell , though on harder configurations that trick may be blocked.
The deeper escalation path runs through a custom SUID binary at /usr/local/bin/guardian-cli, owned by root but executable by svc_guardian.
Running strace on it reveals it calls service without an absolute path, making it wide open to PATH hijacking.
Drop a malicious service script in a writable directory, prepend that directory to $PATH, execute the SUID binary, and it runs your script as root at which point you cp /bin/bash /tmp/rootbash, set the SUID bit, and /tmp/rootbash -p gives you a root shell.
Flags are at /home/support/user.txt and /root/root.txt. Box done.
0 comments