Introduction

Microsoft SQL Server (MSSQL) remains one of the most widely deployed relational database systems in enterprise environments. During penetration tests and red team engagements, MSSQL instances are frequently discovered — and when misconfigured, they can become a powerful pivot point for deeper compromise.

In this article, we walk through a realistic MSSQL exploitation workflow using Impacket’s mssqlclient.py tool, covering everything from initial authentication to OS-level command execution.

Table of Contents

1. Introduction
2. Lab Environment

• Target Details
• Attacker Setup

3. Step 1: Authentication
   • SQL Authentication
   • Windows Authentication
4. Step 2: Enumeration
   • Database Enumeration (enum_db)
   • Database Ownership (enum_owner)
   • Login Enumeration (enum_logins)
   • User Enumeration (enum_users)
   • Impersonation Enumeration (enum_impersonate)
   • Linked Server Enumeration (enum_links)
5. Step 3: Privilege Escalation
   • Impersonating SA (exec_as_login sa)
6. Step 4: OS Command Execution via xp_cmdshell
   • Enabling xp_cmdshell
   • Executing OS Commands
   • Disabling xp_cmdshell (OPSEC)
7. Step 5: Filesystem Access
   • Directory Enumeration (xp_dirtree)
   • File Upload via mssqlclient
   • Upload Verification
8. Quick Reference Guide
9. Defensive Recommendations
10. Conclusion

Lab Environment

The target in our demonstration is a Windows Server running Microsoft SQL Server 2016 (SP2) at IP address 192.168.1.4. We are operating from a Kali Linux attacker machine using Impacket v0.14.0.

• Target IP: 192.168.1.4
• SQL Server: Microsoft SQL Server 2016 (SP2) build 13.0.5026
• Instance: WIN-058B74D7QOH\SQLEXPRESS
• Attacker OS: Kali Linux with Impacket v0.14.0

For More Details – Penetration Testing Lab Setup:MS-SQL

Step 1: Authentication

SQL Authentication

The first step is connecting to the SQL Server. If the sa (System Administrator) account is enabled with a weak password, SQL authentication provides the most direct entry:

impacket-mssqlclient sa:Ignite@987@192.168.1.4

A successful connection shows the server switching to TLS, confirming the database context, and presenting an interactive SQL prompt as dbo@master — the most privileged database role.

Windows Authentication

Alternatively, if you have obtained Windows credentials (e.g., via credential dumping or phishing), use the -windows-auth flag:

impacket-mssqlclient raj:Password@1@192.168.1.4 -windows-auth

Notice that with Windows authentication, the prompt shows the user as guest@master, indicating limited database privileges compared to the sa account. This becomes relevant when performing privilege escalation.

Step 2: Enumeration

Database Enumeration

List all databases and their trustworthy status:

enum_db

The is_trustworthy_on flag is significant — the msdb database has it enabled (value: 1). A trusted database can execute code as the database owner, which is often SA.

Enumerate Owner

enum_owner is used to identify the owner of the current database in Microsoft SQL Server.

enum_owner

Database — the name of the SQL Server database. The four shown (master, tempdb, model, msdb) are all system databases that exist on every SQL Server installation by default.

Owner — the login that owns that database. All four are owned by sa, the built-in System Administrator account.

Login and User Enumeration

Enumerate server-level logins to identify high-privilege accounts:

enum_logins

Key finding: the sa account has sysadmin = 1, confirming it holds the highest SQL Server privilege. WIN-058B74D7QOH\raj is a Windows login with no elevated server roles.

Enumerate users within the current database context:

enum_users

The dbo user is mapped to the sa login, confirming the database owner relationship.

Impersonation Attack

 The enum_impersonate command reveals which logins can be impersonated:

enum_impersonate

We see that WIN-058B74D7QOH\raj has been GRANTed IMPERSONATE permission on the sa login. This is a classic misconfiguration that allows privilege escalation:

For More Details – MSSQL for Pentester: Impersonate

Linked Server Enumeration

Linked servers are a critical escalation vector — they allow one SQL instance to execute queries on another:

enum_links

We discover a linked server called WIN-SQL with sa as the remote login. This means we can potentially execute commands on WIN-SQL with SA privileges by pivoting through this link.

For More Details – MSSQL for Pentester: Abusing Linked Database

Step 3: Privilege Escalation

Privilege Escalation

exec_as_login sa

The prompt immediately changes to SQL (sa  dbo@master)> — we now have full sysadmin privileges despite starting with a low-privilege Windows account.

 Step 4: OS Command Execution via xp_cmdshell

With SA privileges, xp_cmdshell can be enabled to execute operating system commands directly through SQL Server.

Enable xp_cmdshell

enable_xp_cmdshell

The INFO messages confirm that show advanced options and xp_cmdshell were both changed from 0 to 1, and that RECONFIGURE ran successfully.

Execute OS Commands

Now we can run arbitrary OS commands. A classic first command is ipconfig to confirm network context:

xp_cmdshell ipconfig

The output confirms we are executing on the target host (192.168.1.4). From here, the possibilities are extensive — enumeration, credential harvesting, persistence, and lateral movement

For More Details : MSSQL for Pentester: Command Execution with xp_cmdshell

Disable xp_cmdshell (OPSEC)

Good operational security practice dictates disabling xp_cmdshell when not in use to reduce detection footprint:

disable_xp_cmdshell

Step 5: Filesystem Access

Browsing the Filesystem

xp_dirtree enables directory listing without needing xp_cmdshell enabled — a stealthier reconnaissance technique:

xp_dirtree c:\\users

The output reveals user profiles: Administrator, Default, Public — giving us targets for further credential or data harvesting.

File Upload

The upload command transfers files from the attacker machine to the target using SQL Server as the transport channel:

upload /root/dict.txt c:\\temp\\dict.txt

Internally, mssqlclient base64-encodes the file, writes it via xp_cmdshell, then uses certutil to decode it. An MD5 hash check verifies file integrity after transfer. This technique can be used to upload custom payloads, tools, or scripts.

Verify the upload succeeded with xp_dirtree:

xp_dirtree c:\temp

 Quick Reference Guide

Defensive Recommendations

Understanding these techniques is the first step in defending against them. Security teams should consider the following mitigations:

• Disable the sa account or enforce a strong, unique password
• Disable xp_cmdshell permanently unless strictly required
• Audit and remove unnecessary IMPERSONATE permissions
• Restrict linked server configurations and use least-privilege remote logins
• Enable SQL Server Audit to log stored procedure execution
• Deploy an EDR solution capable of detecting certutil decode chains (common upload indicator)
• Regularly review is_trustworthy_on — disable it on all databases that don’t require it
• Segment SQL Server networks — limit which hosts can reach port 1433

Conclusion

This walkthrough demonstrates how a seemingly simple set of SQL Server misconfigurations — a weak SA password, over-granted IMPERSONATE permissions, and enabled linked servers — can chain together into full OS-level compromise.

The mssqlclient.py tool from Impacket makes this workflow remarkably streamlined, wrapping complex T-SQL operations into intuitive shell commands. Penetration testers and red teamers should be familiar with every command in its arsenal.

Defenders, in turn, should treat any MSSQL instance as a high-value target worthy of the same hardening effort as perimeter-facing systems. The database is the crown jewel — protect it accordingly.