Last updated
Last updated
Microsoft SQL Server is a relational database management system commonly found in Windows environments. They’re typically used to store information to support a myriad of business functions. In addition to the obvious data theft opportunities, they also have a large attack surface, allowing code execution, privilege escalation, lateral movement and persistence.
and are excellent tools for enumerating and interacting with MS SQL Servers.
PowerUpSQL has a few cmdlets available for finding MS SQL Servers, including Get-SQLInstanceDomain
, Get-SQLInstanceBroadcast
and Get-SQLInstanceScanUDP
.
Get-SQLInstanceDomain
works by searching for SPNs that begin with MSSQL*. This output shows that SQL-2 is running an instance of MS SQL server, under the context of the mssql_svc
domain account. You may also search the domain for groups that sound like they may have access to database instances (for example, a "SQL Admins" group).
Get-SQLConnectionTest
can be used to test whether or not we can connect to the database.
Then use Get-SQLServerInfo
to gather more information about the instance.
If there are multiple SQL Servers available, you can chain these commands together to automate the data collection.
SQLRecon can also enumerate servers via SPNs and fetch information about the instance with the info
module.
The /auth:wintoken
option allows SQLRecon to use the access token of the Beacon. This output shows that whilst the database is accessible, our current user, bfarmer, is not a sysadmin. SQLRecon has a nice module which can show us what roles we do have.
Finding a user (or group) that does have access can be challenging, because without the ability to query the SQL instance to ask it, you can be stuck guessing. One port of call is to look for appropriately named domain groups and their members.
Another option is to go after the MS SQL service account itself as this is also often given sysadmin privileges. This assumption is the basis of BloodHound's SQLAdmin attack path. We know that the domain account being used to run the service is DEV\mssql_svc
and that the account is kerberoastable owing to its SPN. If we can crack its plaintext password, we can use it to gain access to the SQL instance. The credentials can be used with make_token
in Beacon and /a:WinToken
in SQLRecon; or the /a:WinDomain
option with /d:<domain> /u:<username> /p:<password>
in SQLRecon directly.
Once we have access, there are several options for issuing queries against a SQL instance. Get-SQLQuery
from PowerUpSQL:
SQLRecon:
mssqlclient.py
from Impacket via proxychains:
On default installations, standard users do not have this "public" role by default and must be explicitly granted through (SSMS). The aforementioned information on a SQL instance cannot be enumerated if the user's security context does not have a valid role.
Or a Windows SQL GUI, such as via Proxifier: