Ir al contenido

Microsoft SQL Server

Por

Madurezreviewed
Última revisión
Publicado
Última actualización

Microsoft SQL Server separa el host de la instancia. Una máquina puede ejecutar una instancia predeterminada y varias instancias con nombre, cada una con su puerto, bases, cuentas y configuración. SQL Server Browser ayuda a descubrir esa relación, mientras Tabular Data Stream (TDS) transporta prelogin, autenticación y consultas hacia el destino elegido.

Esa arquitectura obliga a conservar el nombre de instancia junto al endpoint. Un puerto sin Browser puede seguir alojando una instancia válida. Un login puede existir en el servidor y mapearse a usuarios diferentes por base. Una capacidad como xp_cmdshell puede estar habilitada y seguir fuera del alcance de la cuenta. La enumeración avanza desde transporte e identidad hasta permisos efectivos antes de estudiar funciones que alcanzan el sistema operativo.

Los ejemplos usan TARGET_IP, INSTANCE, DOMAIN, USERNAME, DATABASE y TABLE como placeholders.

Nmap y SQL Server Browser localizan instancias. impacket-mssqlclient es práctico desde Linux porque admite autenticación SQL y Windows, muestra el contexto y permite ejecutar T-SQL. sqlcmd es el cliente oficial habitual en estaciones Windows y Linux administradas. Mantén el mismo destino, base de datos e identidad al comparar ambos.

Pregunta Herramienta Validación
¿qué instancias y puertos existen? Nmap y SQL Server Browser conexión TDS al destino devuelto
¿qué autenticación acepta? mssqlclient o sqlcmd login SQL frente a Kerberos o NTLM
¿qué puede ver la cuenta? consultas a catálogos base actual, usuarios, roles y permisos
¿puede suplantar otro principal? EXECUTE AS y funciones de permisos contexto antes y después
¿alcanza el sistema operativo? consultas de configuración permiso, estado de la función y cuenta de servicio

No empieces por xp_cmdshell. Primero demuestra el contexto SQL y los permisos que hacen posible habilitar o usar una capacidad ligada al sistema operativo.

La instancia predeterminada suele escuchar en 1433/tcp. Las instancias con nombre pueden usar puertos dinámicos. SQL Server Browser responde en 1434/udp y permite resolver nombres de instancia a puertos cuando está habilitado.

ms-sql-info consulta información de instancia. -sU -p 1434 pregunta al Browser por UDP, mientras -sV -p 1433 identifica un listener TCP conocido:

Descubrir instancias mediante SQL Server Browser
nmap -sU -p 1434 --script ms-sql-info TARGET_IP
Identificar una instancia en TCP 1433
nmap -sV -p 1433 --script ms-sql-info TARGET_IP

Una named instance puede existir aunque Browser no responda. Correlaciona puertos TCP, connection strings, SPN y configuración local.

TDS negocia prelogin, cifrado y autenticación antes de transportar SQL. Los valores predeterminados de cifrado dependen de la versión y configuración. Registra si el cliente cifra, si valida el certificado y qué versión de TDS negocia. Un canal cifrado no sustituye la validación de identidad del servidor.

mssqlclient.py expresa el destino con la forma DOMAIN/USERNAME@TARGET_IP. -windows-auth solicita autenticación integrada. Sin esa opción, el cliente usa una cuenta SQL:

Conectar mediante Windows Authentication
impacket-mssqlclient 'DOMAIN/USERNAME@TARGET_IP' -windows-auth
Conectar mediante SQL Authentication
impacket-mssqlclient 'USERNAME@TARGET_IP'

El cliente pide la contraseña de forma interactiva. Para una instancia con nombre o un puerto distinto, utiliza la sintaxis soportada por la versión instalada y compruébala con -h. Conserva siempre la instancia y el destino en las notas.

Dentro de la sesión, empieza por registrar versión, login y usuario de base de datos:

Registrar el contexto de la sesión
SELECT @@VERSION;
SELECT ORIGINAL_LOGIN(), SUSER_SNAME(), USER_NAME();
SELECT encrypt_option, auth_scheme, net_transport
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

SUSER_SNAME() describe el security principal del servidor. USER_NAME() devuelve el usuario mapeado en la base actual. Un login puede tener permisos diferentes en cada base.

SQL Server crea bases de sistema como master, model, msdb y tempdb. Las bases de usuario aparecen junto a ellas:

Enumerar bases de datos visibles
SELECT name, state_desc, is_trustworthy_on
FROM sys.databases;

Para cambiar de contexto y enumerar objetos:

Enumerar tablas de una base
USE DATABASE;
SELECT s.name AS schema_name, t.name AS table_name
FROM sys.tables AS t
JOIN sys.schemas AS s ON s.schema_id = t.schema_id;

El schema forma parte del nombre. dbo.Users y app.Users son objetos distintos. Limita la primera lectura:

Leer una muestra acotada
SELECT TOP (20) * FROM schema_name.TABLE;

Los roles de servidor y las impersonaciones condicionan el siguiente paso:

Comprobar roles y permisos de servidor
SELECT IS_SRVROLEMEMBER('sysadmin') AS is_sysadmin;
SELECT * FROM fn_my_permissions(NULL, 'SERVER');

Repite fn_my_permissions(NULL, 'DATABASE') en las bases relevantes. La ausencia de sysadmin no descarta permisos delegados, ownership o EXECUTE AS.

Funciones como xp_cmdshell, SQL Agent, CLR, linked servers y acceso a shares pueden extender la posición de la cuenta. Enuméralas como capacidades separadas. Por ejemplo:

Comprobar el estado configurado de xp_cmdshell
SELECT name, value_in_use
FROM sys.configurations
WHERE name = 'xp_cmdshell';

Que esté habilitado no indica que el login pueda ejecutarlo. Si se invoca, los comandos se ejecutan en el contexto de la cuenta del servicio o de un proxy y crean procesos, logs y estado fuera de la base de datos.

Los linked servers amplían el grafo de confianza:

Enumerar servidores vinculados
SELECT name, product, provider, data_source, is_linked
FROM sys.servers;

Registra mapeos de login y contexto efectivo en cada salto. Un nombre listado no garantiza conectividad actual.

La instalación Nmap 7.99 distribuye varios grupos:

  • ms-sql-info y ms-sql-ntlm-info identifican instancias y metadatos expuestos
  • ms-sql-config, ms-sql-hasdbaccess y ms-sql-tables necesitan contexto suficiente para consultar configuración, acceso y objetos
  • ms-sql-query ejecuta una consulta proporcionada
  • ms-sql-empty-password y ms-sql-brute prueban autenticación
  • ms-sql-xp-cmdshell, ms-sql-dump-hashes y ms-sql-dac persiguen capacidades de impacto distinto

No ejecutes el grupo por glob. Revisa --script-help, argumentos de instancia y credenciales, y valida las consultas con un cliente TDS. SQL Browser por UDP/1434 puede descubrir puertos dinámicos, pero su silencio no descarta una instancia conocida por hostname, SPN, configuración o acceso local.

Una sesión SQL puede conducir a datos, suplantación, servidores vinculados, credenciales, trabajos de SQL Server Agent, assemblies, archivos o ejecución en el sistema operativo. La posibilidad depende de la base de datos principal, los roles de servidor y base, los permisos efectivos, el contexto de ejecución y la configuración. IS_SRVROLEMEMBER, HAS_PERMS_BY_NAME, EXECUTE AS, sys.server_principals, sys.database_permissions y los metadatos de los servidores vinculados permiten formular la rama sin activar todavía xp_cmdshell.

Los mensajes de login pueden ocultar si falla usuario, contraseña, base por defecto, TLS, autenticación Windows o política de origen. Conserva número y estado del error cuando el cliente lo muestre. En autenticación integrada, registra dominio y tipo de credencial. Un login válido en una base no implica acceso a las demás.

SQL Server puede registrar inicios de sesión, errores, consultas, Extended Events, SQL Audit y acciones del Agent. Windows añade procesos, red y autenticación. Evita cambios durante el inventario. Si una prueba crea una tabla, un trabajo, un inicio de sesión, un mapeo de servidor vinculado o cambia una opción con sp_configure, registra el estado anterior, valida, revierte y demuestra el estado final. Cierra sesiones y elimina archivos locales con resultados sensibles según la política de evidencia.

La comparación de clientes, NetExec y NSE vive en herramientas y automatización. Usa la checklist para separar contexto SQL, permisos y capacidades del host. La cheatsheet conserva la sintaxis de consulta.