MSSQL
Tools
PowerUpSQL: https://github.com/NetSPI/PowerUpSQL
HeidiSQL: https://www.heidisql.com/
Gaining Access
Finding SQL Servers
# UDP Scanning
Get-SQLInstanceScanUDP
# Local Instance
Get-SQLInstanceLocal
# Discovery (SPN Scanning):
Get-SQLInstanceDomain
# Check Accessibility:
Get-SQLConnectionTestThreaded
# Get available servers and test if current user can connect:
Get-SQLInstanceDomain | Get-SQLConnectionTestThreaded -Verbose
# Gather Information:
Get-SQLInstanceDomain | Get-SQLServerInfo -VerboseBrute Forcing
Enumeration
Users / Roles
Databases
Tables
Sensitive Data
Privilege Escalation
Impersonation
Trustworthy Database
UNC Path Injection
Juicy-Potato
Command Execution
Xp_cmdshell
Extended Stored Procedures
CLR Assemblies
Blog: https://blog.netspi.com/attacking-sql-server-clr-assemblies/
OLE Automation Procedures
Agent Jobs
External Scripts
Database Link Abuse
Enumerating Database Links
Enabling xp_cmdshell if rpcout is enabled (disabled by default)
Executing Commands
Stealing Link Account
When the link is setup, its set with an account. This could be SA or it could be a user account. You can find out what that account is by enumerating the link. Whatever account the command is running as on the link, is the account used to set it up.
Compromise DB-Server1, its linked to DB-Server2 with the SA of DB-Server2. Can use powershell to get the cleartext cred of SA for DB-Server2. Can then use HeidiSQL or similar to log into the DB-Server2 as SA, can then install cmd execution without dealing with RPCOUT (which prevents this occuring over the link).
Persistance
Startup Stored procedures
Triggers
Registry
Dumping Hashes
Defence
Good Practice
Audit SQL Servers to check the flow of links, trusts, privileges and credentials.
Ensure that Service Accounts for databases are not high privilege domain account.
Make sure that known dangerous Stored Procedures are disabled.
Use SQL Server Audit to log interesting server level and database level events.
Log and Audit.
Monitor the logs.
General Logs
SQL Server Error Log is the place to look for interesting SQL Server logs. By default, the error log is located at %ProgramFiles%\Microsoft SQL Server\MSSQL.1MSSQL\LOG\ERRORLOG
Logs can be viewed in Management Studio by browsing to Management -> SQL Server Logs
Logs are also written to Windows Application logs with MSSQLSERVER as source.
Brute Force Logs
General best practices like having a good password policy and not using same username across databases.
SQL server Logon failures are logged by default in the Windows application log with source MSSQLSERVER.
Look for Event ID 18456. The log message also details the type of brute force - "Password did not match for the login provided" vs "Could not find a login matching the name provided."
Other Event IDs
Event ID 5084 also reports for setting TRUSTWORTHY to on/off.
Event ID 17135 logs launch of startup stored procedures.
Event ID 33090 for successful and 17750 for failed loading of DLLs.
Recall that all command execution techniques we used needed the use of sp_configure.
Using sp_configure leaves Event ID 15457 in the Windows Application log with the configuration changed (argument passed to sp_configure).
This can be used as a very good indicator of command execution.
Make sure that an alert is generated only on the argument of sp_configure to avoid false positives.
Last updated
Was this helpful?