MSSQL Server & AD Abuse
SQL Servers in AD environments can be chained together via trusted links to execute commands across domains — turning a database connection into a path to Domain Admin.
Microsoft SQL Server is one of the most common database platforms in enterprise environments, and it is almost always joined to the Active Directory domain. SQL Servers can be configured with "linked servers" — trusted connections between SQL instances that allow one server to run queries on another. Attackers who gain access to a SQL Server (through a web application SQL injection, compromised credentials, or Kerberoast of a SQL service account) can discover these links and follow them like a chain, potentially reaching servers in other domains or with higher privileges. Additionally, SQL Server's xp_cmdshell feature allows executing operating system commands directly from SQL queries, turning a database connection into full system access.
Imagine Bank A trusts Bank B to process transfers on its behalf, and Bank B trusts Bank C the same way. A customer at Bank A can ask Bank A to ask Bank B to ask Bank C to execute a transaction — and Bank C does it under Bank B's authority, not the original customer's. MSSQL linked servers work identically: a chain of trusted database connections can escalate a low-privileged SQL login into code execution on a remote server running as a high-privileged service account, potentially on a Domain Controller.
Key Takeaways
- MSSQL linked servers can be chained across domains, escalating access with each hop.
- xp_cmdshell converts SQL access into operating system command execution.
- SQL service accounts are often Kerberoastable and may run with elevated AD privileges.
- PowerUpSQL automates the entire discovery, enumeration, and exploitation chain.
- Cross-domain SQL links bypass normal trust boundaries — a frequent pentest finding.
- CLR assemblies and OLE Automation provide alternative code execution when xp_cmdshell is disabled.
SQL Servers are present in nearly every enterprise AD environment and are frequently overlooked in security assessments. A single misconfigured linked server chain can provide a path from a web application compromise to Domain Admin across multiple forests.
Defense Recommendations
Audit linked server configurations, restrict xp_cmdshell, use gMSAs for SQL service accounts, and segment SQL servers from the rest of the network.
- 1Audit all MSSQL linked servers: SELECT * FROM sys.servers WHERE is_linked = 1 — review security contexts.
- 2Remove unnecessary links, especially those crossing domain or trust boundaries.
- 3Disable xp_cmdshell: EXEC sp_configure 'xp_cmdshell', 0; RECONFIGURE.
- 4Replace SQL service accounts with gMSAs to prevent Kerberoasting.
- 5Run SQL Server under a dedicated, low-privilege service account — never LocalSystem.
- 6Restrict SQL Server network access: only application servers should connect to SQL ports (1433/1434).
- 7Monitor sqlservr.exe process creation events (child processes like cmd.exe, PowerShell) via Sysmon.
- 8Audit EXECUTE AS and impersonation privileges: SELECT * FROM sys.server_permissions WHERE type = 'IM'.