This blog briefly describes how to quickly identify instances of SQL Server used by third-party applications that use Powerupsql to configure the default user/password configuration. Although I have mentioned this topic many times, I think it is worth writing a short blog for this topic to help you solve common problems. Hopefully it will help penetration testers and cyber security teams who try to clean up the environment.
Summary of test methods
The default password is still one of the biggest problems we encountered in the intranet penetration test. Web applications are particularly prone to ignoring this problem, but third-party applications that are laid out with their own instance of SQL Server can also be browsed. Rob Fuller set up a default SQL Server instance password list in Pwnwiki. We also track our own lists, so in order to automate the testing process, I put them together and wrapped them up in PowerShell.
This high-level process is very simple:
-
Create a list that is the application-specific instance name of SQL Server and the default username/password associated with the instance;
-
Identify SQL instances through LDAP queries, scan activities, or other means.
-
Cross-reference the list of default instance names with the discovered instance names.
-
Attempt to log in to an instance of SQL Server that matches the associated default certificate.
Load Powerupsql
Powerupsql can be loaded in PowerShell in many different ways. Here's a basic example that shows how to download modules and import modules from GitHub:
IEX (New-object System.Net.WebClient). Downloadstring ("https://raw.githubusercontent.com/NetSPI/PowerUpSQL/master/PowerUpSQL.ps1 ")
To learn more about the basic options, see: Https://github.com/NetSPI/PowerUpSQL/wiki/Setting-Up-PowerUpSQL.
Similarly, to download more content, see Matthew Green's blog: https://mgreen27.github.io/posts/2018/04/02/DownloadCradle.html.
Command example: Positioning by broadcast Ping
After you load Powerupsql, you can discover the SQL Server instance within your current broadcast domain by running the following command.
Get-sqlinstancebroadcast-verbose
As you can see, this command provides you with a list of SQL Server instances in your local network. To tell which SQL instance is set with the default password, you can pass "Get-sqlinstancebroadcast" to "GET-SQLSERVERLOGINDEFAULTPW", as shown below.
Get-sqlinstancebroadcast-verbose | Get-sqlserverlogindefaultpw–verbose
command example: Locating through LDAP queries
If you have a domain name certificate, or have already run on a domain Name system, you can also use LDAP to query the current directory, for a series of registered SQL Server through the following command. This can also be performed from a non-domain system by using the syntax from the Powerupsql Discovery cheatsheet.
Get-sqlinstancedomain-verbose
As the last example shows, you only need to transfer "Get-sqlinstancedomain" to "GET-SQLSERVERLOGINDEFAULTPW" to identify instances of SQL Server that are registered in the domain of the default password settings.
Get-sqlinstancedomain-verbose | Get-sqlserverlogindefaultpw-verbose
The complete list of SQL Server instance discovery features supported by Powerupsql has been listed below:
Function Name |
Description |
Get-sqlinstancefile |
Returns SQL Server instances from a file. One per line. |
Get-sqlinstancelocal |
Returns SQL Server instances from the local system based on a registry search. |
Get-sqlinstancedomain |
Returns a list of SQL Server instances discovered by querying a domain controller for systems with registered MSSQL Servic e principal Names. The function would default to the current user's domain and logon server, but a alternative domain controller can be provi Ded. UDP scanning of Management servers is optional. |
Get-sqlinstancescanudp |
Returns SQL Server instances from UDP scan results. |
get-sqlinstancescanudpthreaded |
Returns SQL Server instances from UDP Scan results and supports threading. |
Get-sqlinstancebroadcast |
Returns SQL Server instances on the local network by sending a UDP request to the broadcast address of the subnet and pars ING responses. |
I would also like to point out that a dbatools function called "find-dbainstance" can be used to blind SQL Server instance discovery. It actually offers more discovery options than Powerupsql. Chrissy Lemaire has written a good overview that can be found on https://dbatools.io/find-sql-instances/.
What is GET-SQLSERVERLOGINDEFAULTPW looking for?
Typically the GET-SQLSERVERLOGINDEFAULTPW function contains 41 application-specific default SQL Server instances, users, and passwords. I intentionally did not include an instance named SQL Express or MSSQLServer because I wanted to avoid account lockout. The only attempt to login is to have an instance that matches the application deployment here. For those who are curious, the current list of application-specific instances is provided below
ACS |
Codepal |
MyMovies |
rtclocal |
Vocollect |
ACT7 |
CODEPAL08 |
Ecc |
Saleslogix |
VSdotNET |
AOM2 |
Counterpoint |
Ecopydb |
Sidexis_sql |
ARIS |
CSSQL05 |
Ecopydb |
Sql2k5 |
Autodeskvault |
Cadsql |
Emerson2012 |
STANDARDDEV2014 |
Boschsql |
Dhleasyship |
HDPS |
Pcamerica |
BPASERVER9 |
Dpm |
Hpdss |
PRISM |
Cdrdicom |
Dvtel |
Insertgt |
Tew_sqlexpress |
Vsql |
Easyship |
Intravet |
Rmsqldata |
Summarize
As a summary, make sure you have a careful review of the third-party software deployed in your environment. Hopefully this article/tool will help the security team clean up the default passwords associated with the default SQL Server instance.
Attacking an instance of SQL Server with Powerupsql