Back
Attacking Application Specific SQL Server Instances
This blog walks through how to quickly identify SQL Server instances used by 3rd party applications that are configured with default users/passwords using PowerUpSQL. I’ve presented on this topic a few times, but I thought it was worth a short blog to help address common questions. Hopefully it will be useful to penetration testers and internal security teams trying to clean up their environments.
Update September 13 , 2018
This is just a quick additional to the original blog. I added a 15 more default passwords to the Get-SQLServerLoginDefaultPw function. Details can be found here.
Testing Approach Summary
Default passwords are still one of the biggest issues we see during internal network penetration tests. Web applications are especially neglected, but 3rd party applications that are deployed with their own instance of SQL Server can also go over looked. Rob Fuller created a nice list of default SQL Server instance passwords in PWNWiki a while back. We were tracking our own list as well, so I glued them together and wrapped a little PowerShell around them to automate the testing process.
The high-level process is pretty straight forward:
- Create a list of application specific SQL Server instance names and the associated default users/passwords.
- Identify SQL Instances through LDAP queries, scanning activities, or other means.
- Cross reference the list of default instance names with the discovered instance names.
- Attempt to log into SQL Server instances that match using the associated default credentials. 😊 Tada!
Loading PowerUpSQL
PowerUpSQL can be loaded a quite a few different ways in PowerShell. Below is a basic example showing how to download and import the module from GitHub.
IEX(New-Object System.Net.WebClient).DownloadString("https://raw.githubusercontent.com/NetSPI/PowerUpSQL/master/PowerUpSQL.ps1")
For more standard options visit https://github.com/NetSPI/PowerUpSQL/wiki/Setting-Up-PowerUpSQL.
Also, for more download cradle options check out Matthew Green’s blog at https://mgreen27.github.io/posts/2018/04/02/DownloadCradle.html.
Command Example: Targeting with Broadcast Ping
After you’ve loaded PowerUpSQL, you can run the command below to discover SQL Server Instances on your current broadcast domain.
Get-SQLInstanceBroadcast -Verbose
As you can see, the command provides you with a list of SQL Server instances on your local network. To identify which of the SQL Instances are configured with default passwords you can pipe “Get-SQLInstanceBroadcast” to “Get-SQLServerLoginDefaultPw” as shown below.
Get-SQLInstanceBroadcast -Verbose | Get-SQLServerLoginDefaultPw -Verbose
Command Example: Targeting with LDAP Query
If you have domain credentials, or are already running on a domain system, you can also query Active Directory via LDAP for a list of registered SQL Servers with the command below. This can also be executed from a non-domain system using syntax from the PowerUpSQL Discovery Cheatsheet.
Get-SQLInstanceDomain -Verbose
Like the last example, you can simply pipe “Get-SQLInstanceDomain” into “Get-SQLServerLoginDefaultPw” to identify SQL Server instances registered on the domain that are configured with default passwords.
Get-SQLInstanceDomain -Verbose | Get-SQLServerLoginDefaultPw -Verbose
The full list of SQL Server instance discovery functions supported by PowerUpSQL have 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 service principal names. The function will default to the current user’s domain and logon server, but an alternative domain controller can be provided. 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 parsing responses. |
I also wanted to note that there is a DBATools function called “Find-DbaInstance” that can be used for blind SQL Server instance discovery . It actually supports a few more discovery options than PowerUpSQL. Chrissy LeMaire already wrote a nice overview that can be found at https://dbatools.io/find-sql-instances/.
What does Get-SQLServerLoginDefaultPw look for?
Currently the “Get-SQLServerLoginDefaultPw” functions cover 41 application specific default SQL Server instances, users and passwords. I intentionally didn’t include instances named SQL Express or MSSQLSERVER, because I wanted to avoid account lockouts. The only time a login is attempted is when there is an instance match that is unique to the application deployment. For those who are curious, the current list of application specific instances has been 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 |
If you see an instance name I’m missing let me know. I’m more than happy to update the function. 🙂
Wrap Up
In conclusion, make sure to take a close look at the third party applications you deploy in your environment. Hopefully this blog/tool will help security teams clean up default passwords associated with default SQL Sever instances. Good luck and hack responsibly!
