Ataques a servidores MSSQL, parte II

El ataque

El 8 de febrero de 2024, Huntress publicó la primera entrada de blog Attacking MSSQL Servers. El 23 de febrero, un analista del SOC de Huntress observó actividad similar asociada a un endpoint completamente distinto, y escaló el incidente con base en la publicación anterior.

Como resultado de la investigación, se registró el primer uso del procedimiento almacenado de MSSQL xp_cmdshell a las 14:45:08 UTC. A partir de las 14:45:15 UTC, y en un lapso de 10 segundos, se ejecutaron los siguientes comandos:

"C:\WINDOWS\system32\cmd.exe" /c bcp "select binaryTable from uGnzBdZbsi" queryout "C:\users\public\music\AD.exe" -T -f "C:\users\public\music\FODsOZKgAU.txt"

"C:\WINDOWS\system32\cmd.exe" /c bcp "select binaryTable from uGnzBdZbsi" queryout "C:\users\public\music\kur.bat" -T -f "C:\users\public\music\FODsOZKgAU.txt"

"C:\WINDOWS\system32\cmd.exe" /c bcp "select binaryTable from uGnzBdZbsi" queryout "C:\users\public\music\n.bat" -T -f "C:\users\public\music\FODsOZKgAU.txt"

"C:\WINDOWS\system32\cmd.exe" /c bcp "select binaryTable from uGnzBdZbsi" queryout "C:\users\public\music\user1.bat" -T -f "C:\users\public\music\FODsOZKgAU.txt"

Varios de estos archivos por lotes claramente se ejecutaron, como lo evidencian los comandos posteriores observados a través de la telemetría de Huntress EDR, así como en los registros del Event Log de Windows. Por ejemplo, el archivo por lotes user1.bat se ejecutó a las 14:45:51 UTC, seguido de comandos para crear la cuenta de usuario admins124 con la contraseña “@@@Music123..,” y agregarla a varios grupos locales. Estos comandos eran visibles en la telemetría de EDR, y su impacto se pudo observar en el Security Event Log.

Sin embargo, el archivo C:\users\public\music\n.bat no parece haberse ejecutado, ya que todavía se encontró en el endpoint. El contenido del archivo aparece de la siguiente manera:

net user admins124 @@@Music123.. /add

net localgroup administrators admins124 /add

net localgroup Administradores admins124 /add

net localgroup Administratoren admins124 /add

net localgroup Administrateurs admins124 /add

net localgroup "Remote Desktop Users" admins124 /add

c:\users\public\music\AD.exe --install C:\"Program Files (x86)"\ --silent

REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\wdigest" /v UseLogonCredential /t REG_DWORD /d 0x00000001

del "%~f0"

El archivo termina con el comando del “%~f0”, lo que indica que, de haberse ejecutado y completado con éxito, el archivo se habría eliminado del endpoint. Cabe notar que el archivo parece ser muy similar al archivo por lotes user.bat identificado en la primera entrada de blog de Huntress.

A las 14:51:57 UTC, se ejecutó el archivo por lotes kur.bat, que contenía el siguiente comando:

c:\users\public\music\AD.exe --install C:\"Program Files (x86)"\ --silent

A partir de este punto, los registros de Windows Event Log demostraron que AnyDesk se había instalado con éxito, según lo indicado por los mensajes en varios registros de eventos.

A las 14:53:44 UTC, una aplicación de monitoreo adicional instalada registró un mensaje que indicaba que se había agregado una nueva aplicación, "AnyDesk", al endpoint. A las 14:57:00 UTC (poco más de tres minutos después), un administrador accedió al endpoint mediante ScreenConnect versión 23.9.10.8817, se autenticó correctamente mediante Duo y comenzó a remediar el endpoint.

Conclusión

Al igual que en la primera entrada de blog de Huntress sobre este tema, el tiempo de ejecución de los comandos demostró la naturaleza automatizada de los ataques. Si bien no se habían observado actividades previas relacionadas con el alojamiento de los archivos dentro de la tabla de la base de datos MSSQL, la actividad posterior del actor de amenazas evidenció la naturaleza automatizada del ataque, al extraer y ejecutar los archivos previamente alojados, lo que dio lugar a múltiples medios de persistencia, mediante AnyDesk y una cuenta recién agregada.

Tras esta investigación, búsquedas posteriores en Internet revelaron que estas TTPs del actor de amenazas también habían sido observadas por el AhnLab Security Emergency response Center (ASEC; consulta la sección 3 de la entrada de blog). En esos incidentes investigados por AhnLab ASEC, los ataques resultaron en que el actor de amenazas implementara ransomware Mimic. Como resultado, la alerta oportuna y el aislamiento del endpoint por parte de los analistas de Huntress, junto con la notificación de una aplicación de monitoreo adicional instalada, lograron evitar la implementación del ransomware.

Este incidente demuestra claramente la necesidad de contar con un inventario de activos preciso y actualizado, que incluya no solo sistemas físicos y virtuales, sino también todas las aplicaciones y servicios disponibles, para fines de aplicación de parches. También demuestra la necesidad de la reducción de la superficie de ataque, donde los administradores restringen el acceso o simplemente eliminan aplicaciones y servicios innecesarios, ya que estos pueden proporcionar un medio de acceso alternativo y fácil o un medio para acceder al endpoint que evade mecanismos de protección como MFA.