📦 Microsoft SQL Server (MSSQL)

What is it?

Concept: MSSQL is Microsoft’s relational database server, listening on TCP 1433 by default. In an Active Directory environment it’s rarely standalone — it’s usually domain-joined, runs as a domain service account, and its own login system sits alongside (not instead of) Windows/Kerberos authentication. That combination is what makes it a recurring AD pivot point rather than just “a database.”
Impact: A single SQL credential can turn into OS command execution (MSSQL - xp_cmdshell Command Execution), and OS command execution on a domain-joined SQL box routinely turns into a domain credential, because the service account running SQL Server is a real AD principal with its own rights, password, and group memberships.

MSSQL supports two authentication modes side by side: SQL authentication (a login/password pair stored inside SQL Server itself, e.g. the built-in sa account) and Windows authentication (the connecting principal’s existing domain Kerberos/NTLM identity is used directly, no separate SQL password involved).
Server-level roles (most importantly sysadmin) control what a login can do once connected — sysadmin is effectively root over the database engine, including the ability to enable dangerous extended stored procedures like xp_cmdshell.
The SQL Server service itself runs under a configured Windows account (visible in services.msc/its install config) — every OS-level action taken through the database (via xp_cmdshell or similar) executes as that service account, not as whichever login authenticated to the database.
SQL Server also supports linked servers — persistent connections to other SQL instances configured with their own stored credentials — which lets a compromised instance pivot to another one (via OPENQUERY) using credentials the attacker never directly obtains.

xp_cmdshell ships disabled by default since SQL Server 2005, but re-enabling it only requires sysadmin — meaning “I have sa’s password” and “I have xp_cmdshell RCE” are functionally the same finding, just one sp_configure call apart.
The service account configured during SQL Server setup is often left with a static, documented password sitting in install/config files (sql-Configuration.INI and similar) on the same host — install-time convenience that turns local file read access into a full credential.
sa is disabled by default on newer installs but is very commonly re-enabled (with a memorable/weak password) for legacy application compatibility — always worth testing regardless of what a port scan alone suggests.

Impacket’s mssqlclient.py is the standard tool for both SQL-authenticated and Windows/Kerberos-authenticated connections — it auto-detects TLS requirements and drops into an interactive SQL> prompt that accepts both raw T-SQL and shorthand commands like enable_xp_cmdshell.
Because the database service account is a real domain identity, any credentials recovered through a SQL foothold (config files, service account passwords) are worth spraying against SMB/WinRM immediately — password reuse between “the account that runs the database” and “an actual domain user” is extremely common in small/lab AD environments.

Fix 1: Run the SQL Server service under a dedicated, least-privilege gMSA rather than a static-password domain account, so a leaked config file doesn’t hand over a reusable credential.
Fix 2: Disable xp_cmdshell (and audit sp_configure changes) unless there’s a specific, approved operational need for it.
Fix 3: Prefer Windows/Kerberos authentication over SQL authentication where possible — it removes the separate sa/SQL-login password as an attack surface entirely.

File	Created
HTB - EscapeTwo	Thursday, July 23rd 2026, 10:31:00 pm

References: