Hack the Box: Querier Walkthrough

Querier was an ‘medium’-rated machine on Hack the Box that required attackers to harvest files from unsecured SMB shells, and capture database credentials off the wire to get a toehold on the system, and then carefully enumerate the box to find admin credentials to finally pwn the system.

On the target network at, the system description noted that it was a Windows box, and from the name, it was likely that a database server was likely to play some role.

Initial Enumeration

Running nmap against the box, I find that there’s quite a few open ports, incuding SMB, MS-SQL, and some Windows remote management services (wsman and winrm):

root@kali:~/htb/querier# nmap -v -Pn -R -p1-65000 -oG querier_nmap_all.txt
Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-07 19:41 EDT
Initiating Parallel DNS resolution of 1 host. at 19:41
Completed Parallel DNS resolution of 1 host. at 19:41, 0.00s elapsed
Initiating SYN Stealth Scan at 19:41
Scanning [65000 ports]
Discovered open port 139/tcp on
Discovered open port 135/tcp on
Discovered open port 445/tcp on
Discovered open port 49669/tcp on
Discovered open port 49667/tcp on
Discovered open port 49664/tcp on
Discovered open port 49671/tcp on
Discovered open port 49665/tcp on
Discovered open port 49668/tcp on
Discovered open port 5985/tcp on
Discovered open port 47001/tcp on
Discovered open port 1433/tcp on
Discovered open port 49670/tcp on
Discovered open port 49666/tcp on
Completed SYN Stealth Scan at 19:42, 31.53s elapsed (65000 total ports)
Nmap scan report for
Host is up (0.032s latency).
Not shown: 64986 closed ports
135/tcp open msrpc
139/tcp open netbios-ssn
445/tcp open microsoft-ds
1433/tcp open ms-sql-s
5985/tcp open wsman
47001/tcp open winrm
49664/tcp open unknown
49665/tcp open unknown
49666/tcp open unknown
49667/tcp open unknown
49668/tcp open unknown
49669/tcp open unknown
49670/tcp open unknown
49671/tcp open unknown
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_Tree_Name: HTB.LOCAL
|_ Product_Version: 10.0.17763
| ssl-cert: Subject: commonName=SSL_Self_Signed_Fallback
| Issuer: commonName=SSL_Self_Signed_Fallback
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2019-06-07T19:36:42
| Not valid after: 2049-06-07T19:36:42
| MD5: f232 b7fc 7f41 4dbc 8453 479f 8950 f343
|_SHA-1: c986 b6ee c2b7 cea6 c0fd cc62 a32d 64da fe20 2b7b
|_ssl-date: 2019-06-07T22:35:03+00:00; -1h06m12s from scanner time.
No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ).
TCP/IP fingerprint:
Network Distance: 2 hops
TCP Sequence Prediction: Difficulty=262 (Good luck!)
IP ID Sequence Generation: Incremental
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows
Host script results:
|_clock-skew: mean: -1h06m12s, deviation: 0s, median: -1h06m12s
| ms-sql-info:
| Version:
| name: Microsoft SQL Server
| number: 14.00.1000.00
| Product: Microsoft SQL Server
|_ TCP port: 1433
| smb2-security-mode:
| 2.02:
|_ Message signing enabled but not required
| smb2-time:
| date: 2019-06-07 18:35:06
|_ start_date: N/A

After doing a little research and a little poking, it looks like the Windows remote management services need credentials. The SMB share, on the other hand, is open to guest sessions.

There are some default shares, and then a “Reports” share. What’s in that?

In \\\Reports, I  find the macro-enabled Excel spreadsheet “Currency Volume Report.xlsm”. I don’t have anything on my Kali box that can open xlsm files, but I can unzip it and run ‘strings’ against the pieces. Lo, and behold, in xl/vbaProject.bin, we find…

A MS-SQL connection string with username ‘reporting’ and password ‘PcwTWTHRwryjc$c6’. We also get the database name of ‘volume’.

Initial compromise

Impacket has a nice little MSSQL client Python script, and after monkeying around with it for a bit, I was able to connect to the previously-identified MSSQL server, using the ‘-windows-auth’ flag for authentication.

./mssqlclient.py -db volume QUERIER/reporting:@ -windows-auth

So, xp_cmdshell is not enabled, and “reporting” doesn’t have sufficient privileges to enable it. Additionally, poking around the database didn’t reveal anything of interest in the tables.

At this point, I hit something of a wall and ended up turning to the forums for a hint. They suggested looking at some previous Ippsec walkthroughs, where I eventually found instructions on using the MSSQL built-in xp_dirtree function and Impacket’s smbserver.py to harvest credentials.

Mark Mo has a good tutorial on how to do this on Medium.

So, I start up a SMB server with Impacket’s smbserver.py script in one shell and talk to the MSSQL server in another.

The result? The database server calls our SMB server to get a directory listing, very helpfully packaging its NTLM credentials in the request, which our SMB server catches and spits out.


Save that hash to a file (in this case mssql-svc.hash), and run it through John with the rockyou password list.

14 seconds later, I have new credentials:


Using these creds back in the database, I’m now running as the service account, and can enable Xp_cmdshell and start running commands on the host:

After some poking around in the file system, I get…

Upgrading our shell, and escalating privilege

So, that’s user, but I still need an admin shell to fully pwn the box. Messing around on the system via xp_cmdshell is tedious, so the next thing to do is to upgrade my connection.

I go back to my SMB server, and put ncat in the share directory, then pull it over to the target box.

Or… not.

So, there’s probably an easier way of doing this, but a small part of me wanted to see how antivirus on the box was detecting ncat. Black Hills Information Security did a post a while back about just editing the code of a Meterpreter shell binary to evade antivirus by removing certain overtly malicious keywords. Unfortunately, I can’t find a link to it at the moment. Regardless, I was curious to see if something similar would work here, so I broke out hexeditor and turned ‘ncat’ into ‘mcat’ one character at a time.

A few minutes of find-and-replace later, and I have a perfectly innocent-looking binary.

With a firm beachhead on the machine, I turned to enumerating the box. I pulled out Just Another Windows (Enum) Script , went through Fuzzysecurity’s Windows enumeration tutorial, used Pentestmonkey’s windows-privesc-check2.exe… Nothing. I went back and tried using the credentials I had with winrm and wsman… Zip. Zilch. Nada.

Finally, after much searching, and banging of my head against the wall, I went back and looked at something I’d skipped before because it looked like it was only relevant to domain machines, and this was (I thought) a standalone box. But in

ProgramData\Microsoft\Group Policy\History\{31B2F340-016D-11D2-945F-00c04FB984F9}\Machine\Preferences\Groups\Groups.xml

I find:

The cpassword is what I’m looking for. Per fuzzysecurity, Microsoft published the static AES key used to encrypt all the cpasswords a few years ago. PowerSploit has a tool Get-GPPPassword, for retrieving those passwords, but since I already had the ciphertext, I just pulled out the Get-DecryptedCpassword function, made it a module and ran that:


One psexec later…




Author: TheKilt

Information Security, Cosmic Horror, Gaming, Homebrewing, BBQ

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: