Análisis a fondo: cómo se frenó un ataque a MSSQL

Durante el MSP Moment anterior, guiamos a nuestros lectores a través de un incidente en el que nuestro socio, NTConnections, usó Huntress para descubrir una brecha que antes no se había detectado. En este Deep Drive, examinaremos las tácticas que usaron los atacantes para obtener acceso a través de la base de datos, detener o desactivar el antivirus, descargar archivos maliciosos y establecer una presencia persistente dentro de la red.

Cuando se trata de una brecha, una de las primeras preguntas que suele surgir es "¿cómo entraron los atacantes?". Lamentablemente, esta no siempre es una pregunta fácil de responder. Por suerte, los actores detrás de este ataque fueron bastante ruidosos y el servidor tenía varios meses de copias de seguridad disponibles para una inspección forense. En cuestión de minutos de investigar los registros de eventos (Event Logs) de Windows Event Logs, descubrimos señales del vector de acceso inicial: miles de intentos fallidos de Inicia sesión en la base de datos de MSSQL.

Fuerza bruta contra credenciales débiles de base de datos

MSSQL ofrece acceso remoto a través de una interfaz de Open Database Connectivity (ODBC) que normalmente escucha en el puerto 1433. Después de establecer una conexión con esta interfaz, se les pide a los usuarios un nombre de usuario y una contraseña de la base de datos. Al igual que la cuenta predecible "Administrator" de Windows, MSSQL tiene una cuenta "sa" que otorga acceso de administrador del sistema. Los hackers aprovecharon este conocimiento y lanzaron un ataque de fuerza bruta con contraseñas de uso común.

Event Viewer con el detalle del ataque de fuerza bruta registrado en el Application Event Log

Además de la cuenta "sa", el atacante probó otros 20 nombres de usuario adicionales:

Después de más de 37.000 intentos, lograron autenticarse con éxito en la base de datos de MSSQL.

Ejecución de comandos de shell desde MSSQL

Con este acceso, los atacantes ahora necesitaban lograr la transición de privilegios de base de datos a ejecución nativa de comandos. Dentro de MSSQL, la función xp_cmdshell es ideal para esto. Sin embargo, está desactivada por defecto, así que los atacantes tuvieron que reconfigurar la base de datos con los siguientes comandos:

En una instalación estándar de Windows, esto es todo lo que se necesita para ejecutar comandos de shell. En sistemas reforzados como quioscos y sistemas de misión crítica, se puede restringir la Política de grupo para impedir que los usuarios manipulen el símbolo del sistema. En lugar de arriesgarse, el atacante optó por modificar y eliminar varias claves del registro para asegurarse de que sus comandos se ejecutaran como esperaba.

Con estos obstáculos fuera del camino, los atacantes quedaron libres para realizar acciones más dañinas, como detener procesos de antivirus:

Desactivación del antivirus con Image File Execution Options

Además de usar taskkill.exe, los atacantes tomaron otras medidas de precaución para impedir que se ejecutaran muchas aplicaciones antivirus comunes. Una de estas técnicas aprovechó la función Image File Execution Options (IFEO) dentro del registro. El atacante abusó específicamente del valor Debugger de IFEO, lo que hacía que se ejecutara taskkill.exe en lugar de los procesos indicados.

Abusar del valor Debugger de IFEO para evitar que notepad.exe se abra

Para los lectores que no la conocen, la clave IFEO es un lugar centralizado para ajustar cómo se ejecutan las imágenes (procesos). Como se muestra en el GIF anterior, puedes modificar la forma en que se ejecutan procesos específicos al crear una clave con el nombre del proceso objetivo (por ejemplo, notepad.exe). Dentro de esta clave, puedes crear varios valores para ajustar la implementación de ASLR (MitigationOptions) o adjuntar automáticamente un depurador específico para solucionar problemas de un proceso (Debugger).

Cuando un proceso empieza a ejecutarse, una de las primeras acciones que realiza explorer.exe es revisar la clave IFEO. Si el proceso ejecutado tiene una subclave correlacionada (comparte el mismo nombre), Windows revisará si existe un valor Debugger. Si el valor Debugger existe, el sistema operativo ejecutará los datos dentro del valor y pasará el proceso original y sus argumentos al depurador especificado.

Por ejemplo, si fueras el desarrollador de myApp.exe, podrías agregar lo siguiente al registro para adjuntar automáticamente el depurador de Windows (windbg.exe) cuando se ejecute tu proceso:

Si la sintaxis de línea de comandos para este programa era myApp.exe, el sistema operativo en realidad ejecutaría windbg.exe myApp.exe (por lo que nunca se ejecutaría myApp.exe directamente). Si los atacantes creaban un valor Debugger configurado como "taskkill.exe /F /IM " dentro de la subclave de myApp.exe, Windows en realidad ejecutaría "taskkill.exe /F /IM myApp.exe", como se demuestra en esta captura de pantalla de ProcMon:

Taskkill.exe se llama automáticamente para terminar el proceso objetivo

Esta técnica es una forma ideal de evitar que algunos productos antivirus se ejecuten. Para ver exactamente qué procesos buscaban estos atacantes, consulta la lista completa de sus modificaciones del registro relacionadas con IFEO aquí.

Descarga de malware con archivos de respuesta FTP

Una vez que los atacantes deshabilitaron el antivirus, inmediatamente comenzaron a descargar malware. Para hacerlo, primero intentaron deshabilitar el firewall de Windows deteniendo el servicio dependiente SharedAccess. Luego, el atacante usó el comando "echo" para crear archivos de respuesta FTP:

Creación del contenido de un archivo de respuesta FTP mediante "echo"

Estos archivos de respuesta funcionan como scripts desatendidos que le indican a "ftp.exe" qué acciones ejecutar. Una vez creado el archivo de respuesta, se ejecutó el comando "ftp -s:NameOfScript.txt". En el siguiente ejemplo, nos conectamos al servidor FTP del atacante y descargamos un archivo desde su servidor hacia nuestro directorio.

¡Los archivos de respuesta FTP en acción!

Durante este incidente, descubrimos que los atacantes descargaron todo tipo de amenazas, incluyendo crimeware, herramientas de acceso remoto y mineros de criptomoneda. Nuestros análisis técnicos detallados de las muestras que analizamos mediante ingeniería inversa se encuentran a continuación:

Redosdru: payloads DLL cifrados para evitar firmas en disco
Descargador genérico lleva a un minero de BitCoin: ¡próximamente!
Troyano Vitro: ¡próximamente!

Cómo mantienen acceso persistente a la víctima

Nuestro producto Huntress complementa los productos de seguridad preventiva (como el antivirus), auditando los puntos de apoyo persistentes que los atacantes usan para asegurar un acceso a largo plazo. Durante esta brecha, descubrimos varias Run Keys maliciosas y Services maliciosos que lanzaban automáticamente malware cuando un usuario iniciaba sesión o después de reiniciar el sistema.

Clave Run sospechosa
Inmediatamente después de comprometer la base de datos MSSQL, los atacantes usaron la técnica xp_cmdshell mencionada antes para crear varios puntos de apoyo persistentes basados en el registro:

REG ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v Aut2 /t REG_SZ /d c:\windows\system32\cmd.exe /c net stop sharedaccess… /F

Aunque cmd.exe era un ejecutable legítimo de Microsoft, el uso de un valor de registro llamado "Aut2" con estos comandos anidados era anómalo. Como resultado, Huntress clasificó la actividad como maliciosa.

Servicio sospechoso
Huntress también descubrió un servicio llamado "Wsqhwr zajttrgb" creado por uno de los archivos maliciosos descargados mediante los Answer Files de FTP. Este servicio lanzaba automáticamente un binario empaquetado con UPX desde C:\Program Files\Microsoft Otvkec\Cgowgmi.exe al iniciar el sistema. Tras un análisis más detallado, descubrimos que el malware era capaz de instalar su propio mecanismo de persistencia y se comunicaba con frecuencia con fyunf.f3322[.]net (42.51.33.115).

Configuración del servicio dentro del registro

SHA256:420bdfbd9df7773185c39a771d24b6ffa7a38c3983ce08448b55182bbe77d004

Reflexiones finales sobre esta brecha

Aunque los hackers detrás de este compromiso usaron muchas técnicas diferentes, todas eran bien conocidas y estaban documentadas dentro de la comunidad de ciberseguridad. A pesar de esto, estos atacantes lograron obtener acceso, deshabilitar la seguridad preventiva existente, establecer un punto de apoyo persistente y alterar significativamente la productividad de una SMB.

Al igual que las empresas del Fortune 500, las pequeñas y medianas empresas necesitan experiencia en seguridad más allá de configurar firewalls y antivirus. Nuestro servicio de detección y respuesta administradas hace que esta sea una solución fácil y rentable para los proveedores de servicios administrados.

¿Listo para encontrar a los hackers en tu red? Regístrate para obtener nuestra Prueba gratuita de 21 días

En Huntress Labs, creemos que la mejor defensa es un buen ataque. Hemos pasado nuestras carreras evadiendo productos de seguridad preventiva para mantenernos un paso adelante de los actores maliciosos. Esta mentalidad permite que nuestros productos y analistas enfrenten las amenazas de frente. Como resultado, obligamos a los hackers a ganarse cada centímetro de su acceso dentro de las redes que protegemos y monitoreamos.