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 -Verbose

Brute 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

Enabling xp_cmdshell if rpcout is enabled (disabled by default)

Executing Commands

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?