Compromising Microsoft SQL Server

This chapter will focus on a common and vital service of a typical Windows-based environment – Microsoft SQL Server. SQL Server is a relational database management system, similar to Oracle or MySQL. It is tightly integrated into Active Directory, allowing Windows authentication, the use of trust relationships, and much more. We will go through the usual attack steps, starting with the discovery and enumeration of instances in a target environment. A few different tools can help with these activities. Then, we will explore the ways to escalate privileges within SQL Server and then move on to run commands on the underlying operating system. This chapter will provide you with a solid understanding of lateral movement between database instances by abusing database links. Lastly, we will look at the ways to achieve persistence at the host and application levels utilizing what is available in SQL Server functionality.

In this chapter, we will...

Technical requirements

In this chapter, you will need to have access to the following:

• VMware Workstation Pro or Oracle VirtualBox with at least 16 GB of RAM, 8 CPU cores, and at least 55 GB of total space (more if you take snapshots)
• A Linux-based operating system is strongly recommended
• From the GOADv2 project, we will use SRV02 and SRV03

Introduction, discovery, and enumeration

In this section, we will start our journey in Microsoft SQL Server security assessment. We will briefly introduce you to SQL Server and then move on to the discovery process. A significant amount of the section will be a deep dive into the manual and automated aspects of the enumeration process.

SQL Server introduction

Before we jump into the discovery topic, let’s start by looking at SQL Server functionality, fixed server roles, and security mechanisms. SQL Server is an application installed on the OS; in our case, we will focus only on Windows hosts. The server runs as a set of uniquely named Windows services in the context of the service account. The default listening TCP port is 1433, and the UDP port is 1434; however, if more services are running, the list of ports will be longer[1]. In order to get access to stored data, a user must pass authentication and authorization checks.

Authentication verifies whether a user has...

Privilege escalation

In the previous section, we saw a number of techniques for database enumeration. In this section, we will use gathered reconnaissance results for the user khal.drogo to identify privilege escalation paths on the database server. We will also practice escalating privileges from SQL Server to the host itself. At the end of this section, we will escalate to the sysadmin role from the user, with host local administrator privileges.

Impersonation

One of the most common privilege escalation vectors is user impersonation. This privilege allows the impersonation of another user or login in order to access resources on behalf of the impersonated user, without specifically granting rights[10]. sysadmin has this permission for all databases, members of the db_owner role only have this permission in databases they own. We can check whether a current user is allowed to impersonate sa user login with the following query:

EXECUTE AS LOGIN = 'sa'
SELECT SYSTEM_USER...

OS command execution

In the upcoming sections, we will look at ways to execute OS system commands through SQL Server. To enable command execution, sysadmin privileges are required. Execution itself always happens in the context of a service account. An attacker does not need to know the hash or password of the SQL Server service or agent account. Let’s start by looking at built-in extended stored procedures.

xp_cmdshell

xp_cmdshell is probably the most well-known built-in extended stored procedure, which is disabled by default. Enabling it requires sysadmin privileges. There are a few functions in PowerUpSQL (Invoke-SQLOSCmdExec and Invoke-SQLOSCmd), SQLRecon (EnableXp and XpCmd), as well as the Metasploit admin/mssql/mssql_exec module that can automate this task. The manual query to install xp_cmdshell and enable it is shown here:

sp_addextendedproc 'xp_cmdshell','xplog70.dll
EXEC sp_configure 'show advanced options',1
RECONFIGURE
EXEC sp_configure...

Lateral movement

As we saw in Chapter 5, it is crucial to understand how an adversary can abuse legitimate applications and protocols to expand inside the target environment. SQL Server also broadens lateral movement scenarios via two techniques. One is common and called shared service accounts. The other one is specific only to SQL Server – abusing database links. We will quickly explore the first one and focus on the second. We will examine how to do enumeration on linked servers, execute code, and extract clear-text hardcoded credentials.

Shared service accounts

Using shared service accounts across an environment may lead to disastrous consequences. If a service account is compromised via Kerberoasting, UNC path injection, or any other way, it means that all instances using this account are compromised. Moreover, the service account by default has sysadmin privileges on the database and SQL Server levels, but it also may have extensive privileges on the underlying OS...

Persistence

Now that we know about persistence on domain and domain controller levels, why bother with SQL Server? Most detective controls are implemented at the OS level. Database audits are not so common and thorough. A SQL Server service account may have extensive permissions on the OS, giving an attacker an excellent hideout, as all questionable actions will be logged as they were performed by the service account. Lastly, even if auditing and monitoring are enabled on busy databases, it is difficult to differentiate legitimate activities from malicious ones. We will start with the most noisy and unsafe way to achieve persistence at the OS level via autoruns, moving toward the SQL Server level, with startup procedures and triggers.

File and registry autoruns

These two methods are very OpSec-unsafe, as the Startup folder and registry keys are often monitored by security solutions, such as Sysmon and EDR. There is a slight chance that writing a file in such locations using a...

Summary

In conclusion, there are many reasons for an adversary to choose SQL Server as a valuable target. We saw in practice how to perform enumeration against a database server. We deep-dived into various privilege escalation techniques, not focusing only on the database level. By gradually migrating from a low-privileged public account to SYSTEM, we covered the attacker’s kill chain. Then, many techniques for OS command execution were demonstrated in order to help us understand how tightly applications can be integrated with a host OS. Furthermore, we saw how database links can be abused by an adversary for lateral movement if they are not configured correctly. Finally, persistence techniques were discussed at the OS and database levels. A deeper understanding of available database functionality can give one party an advantage over the other.

Further reading

These aids for further study will let you dive deeper into the attacks covered in the chapter:

1. SQL Server network ports: https://www.mssqltips.com/sqlservertip/7212/sql-server-port-explanation-usage/
2. SQL Server 2022 new fixed server-level roles: https://learn.microsoft.com/en-us/sql/relational-databases/security/authentication-access/server-level-roles?view=sql-server-ver16
3. Pre-SQL Server 2022 fixed server-level roles: https://www.mssqltips.com/sqlservertip/1887/understanding-sql-server-fixed-server-roles/
4. SQLRecon tool: https://github.com/skahwah/SQLRecon
5. PowerUpSQL tool: https://github.com/NetSPI/PowerUpSQL
6. PowerUpSQL Cheat Sheet: https://github.com/NetSPI/PowerUpSQL/wiki/PowerUpSQL-Cheat-Sheet
7. HeidiSQL tool: https://www.heidisql.com/
8. MS SQL Server enumeration: https://book.hacktricks.xyz/network-services-pentesting/pentesting-mssql-microsoft-sql-server#common-enumeration
9. MS SQL Server enumeration 2: https://ppn.snovvcrash.rocks...