CQURE Hacks #74: Microsoft SQL Server Privilege Escalation

We’re diving into a classic but devastatingly effective exploit path. Many organizations leave their SQL Servers vulnerable through a combination of three simple misconfigurations: a database set to “trustworthy,” an owner with sysadmin rights (like SA), and a low-privilege user with db_owner permissions.

By abusing these settings, an attacker can create a stored procedure that executes in the context of the database owner. We’re showing you exactly how to identify these “trustworthy” databases using netexec and impacket, and then demonstrate how to inject a login into the sysadmin role.

Secure Your Spot: Hacking and Securing SQL Server Live Virtual Class

This five-day workshop offers an in-depth, hands-on experience with SQL Server 2022 and 2025. We will explore every layer of security – from core principles to implementing advanced protection like encryption, role-based access control, and auditing. We will examine system and network security implications, cover the latest features, and discuss how to integrate SQL Server with Azure solutions like Azure Defender and Sentinel.

The masterclass will be led by Margarita Naumova, a SQL Server Architect, consultant, speaker, and trainer with over 25 years of experience in data platform technologies. She is a Microsoft Certified Master (MCM), Microsoft Certified Trainer (MCT), and has been a Microsoft MVP for 15 consecutive years.

As the Founder of SQL Master Academy and CEO of Inspirit Data Platform Consulting, Magi operates in Bulgaria and Norway. She specializes in SQL Server and Microsoft Fabric Data Platform, helping professionals and organizations design modern, high-performing data solutions.

Sign up for the Masterclass here – we’re starting on March 16th!

TRANSCRIPT

[00:07] We are going to walk through a classic Microsoft SQL Server privilege escalation. We start with a low-privilege application account and end up with sysadmin rights by abusing a trustworthy database. 

[00:20]  First, we check whether a SQL Server is actually listening on the default port. We run “nmap -p1433”, which is the port, against the target IP. So the output shows that port1433 is open and it identifies the Microsoft SQL Server service. Let’s change the directory to where our word list resides. So we’re going to go to the desktop. Next, we look for valid credentials. 

[00:47] We use “netexec” to spray common usernames and passwords against the Microsoft SQL service. So well, as you can see, it quickly finds a hit. The account developer with the password “qwert6”. With working credentials, we now check which databases have “trustworthy” set to “on”. This setting is the most important condition for the attack we are about to perform. We run a simple query through netexec: “SELECT name, is_trustworthy_on FROM sys.databases”. And there we go and see that the databases named “msdb” and “cqlab” have “trustworthy” enabled. Let’s check whether our user has “db_owner” permissions on any of the databases that has “trustworthy” enabled. 

[01:44] We run the query, and as you can see, “msdb” returns “0” for “trustworthy”, meaning that it’s not enabled. Let’s run the query again, and “cqlab” returns “1”. Therefore, it means that “trustworthy” is enabled. 

[02:03] Now we move to an interactive session. We launch “impacket-mssqlclient” with the developer credentials. Once connected, we switch to the “cqlab” database and check our current privileges. System user is “developer” and “sysadmin” membership is “0”. That means we are a low-privileged user. This is where escalation happens. We create a stored procedure that runs with “execute” as owner because the database is “trustworthy” and owned by SA, and because we have db_owner, the procedure executes in the context of SA. Inside the procedure, we add our login developer to the sysadmin server role. 

[03:09] Let’s run another query, and we execute the procedure. We check again. System user is still “developer”, but sysadmin membership is now “1”. All right. In just a few seconds, we went from an ordinary application developer to a full sysadmin on the server. This path works because of three misconfigurations present at the same time: 1) “trustworthy” is turned on for the database, 2) the database owner is SA or another sysadmin account, 3) and our login has db_owner inside that database.

Want to know more?