MSSQL
Last updated
Was this helpful?
Last updated
Was this helpful?
PowerUpSQL:
HeidiSQL:
Blog: https://blog.netspi.com/attacking-sql-server-clr-assemblies/
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).
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.
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.
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."
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.