DownAndExec: propagación de malware bancario usando las CDN

Los servicios como Netflix utilizan redes de entrega de contenidos (content delivery networks o CDN, en inglés) para maximizar el uso del ancho de banda. Así, les dan mayor velocidad a sus usuarios al ver los contenidos; siguiendo el ejemplo, como el servidor está cerca tuyo y forma parte de la CDN de Netflix, las series y películas cargan rápido en cualquier parte del mundo en que te encuentres. Pero, al parecer, las CDN están empezando a convertirse en una nueva vía de propagación de malware.

Recientemente detectamos un fuerte crecimiento en el aprovechamiento de NSIS (Nullsoft Scriptable Install System) con fines maliciosos, para la propagación de malware bancario. NSIS es un manejador de scripts desarrollado por los creadores del famoso y ya desaparecido Winamp, que hoy en día es utilizado para distribuir los instaladores de muchas aplicaciones en Internet. Es muy parecido a Windows Installer, pero más fácil de codificar y con amplio soporte a diferentes tipos de compresión.

La cadena de ataque es bastante extensa, ya que involucra la ejecución de scripts remotos (en algún punto semejante a la que vemos en la tendencia reciente de “fileless” en malware bancario), el uso de CDN para comando y control (C&C), además de las técnicas habituales de ejecución y ocultamiento de malware.

Como podrás ver en el siguiente gráfico, las detecciones de una amenaza detectada por ESET como NSIS/TrojanDropper.Agent.CL aumentaron en el pasado mes de junio, y nos dimos a la tarea de averiguar por qué.

Figura 1: Telemetría de detección de NSIS/TrojanDropper.Agent.CL en junio de 2017.

Sin embargo, esta no parece ser la única campaña reciente: en los últimos días, desde la cuenta de Twitter @MalwareHunterTeam han estado alertando sobre un ataque que se aprovecha de la CDN de Facebook para alojar un archivo malicioso, al cual propagan a través de correos que simulan provenir de entidades gubernamentales de Brasil. Por lo tanto, podríamos pensar que estamos ante una incipiente tendencia de los cibercriminales a usar estas redes para propagar malware.

Tomando como base la campaña de NSIS/TrojanDropper.Agent.CL, este artículo se propone analizar el patrón de descarga y ejecución (denominado "downAndExec"), que hace uso intensivo de scripts JS para comprometer con bankers las máquinas de las víctimas. 

Fase 1: infección inicial

El proceso de infección inicia con el envío de archivos detectados por ESET como NSIS/TrojanDropper.Agent.CL. Algunos de los archivos maliciosos que se estuvieron propagando tienen nombres en los cuales es posible percibir el intento de convencer a las víctimas de que ejecuten el malware usando técnicas de ingeniería social.

Una característica de NSIS es el hecho de que, desde la versión 9.43 (junio de 2014), es posible extraer el script incrustado en el ejecutable, que contiene las funcionalidades de ese troyano inicial.

Cuando es cargado, el script hace uso extenso de llamadas recursivas, lo cual dificulta que se pueda seguir su ejecución. Así que con pocas modificaciones en relación al script original, que hace uso de recursos como ActiveX (disponible solo para Internet Explorer), es posible debuggear el script utilizando DevTools de Chrome.

Figura 2: Llamada recursiva c() y patch de script para debuggar vía DevTools.

El script cumple la función de actuar como downloader, por lo que ese encarga de bajar y ejecutar otros códigos maliciosos en la máquina. En este caso, descarga un snippet JS alojado externamente, el cual es necesario para complementar su ejecución.

En estas últimas campañas analizadas las infraestructuras CDN de algunos proveedores son  utilizadas para alojar el snippet JS mencionado. Como no es posible bloquear todo el dominio de la CDN, la respuesta a la amenaza impone algunos desafíos:

• Bloqueo de nuevos C&C: tal vez por eso se observó el surgimiento frecuente de nuevas URL en el mismo dominio que aloja los C&C.
• Búsqueda por IoCs: en ambientes afectados hay (potencialmente) un gran número de registros de acceso hechos por software no malicioso.

Figura 3: Simulación de CDN que aloja el snippet JS malicioso.

Para simular la CDN que aloja la porción maliciosa en JS  y facilitar el debugging, es posible cargar ese contenido localmente, utilizando un servicio HTTP local (basta con  habilitar la opción de compartir recursos y, de esa forma, ejecutar el script en otros orígenes).

Figura 4: Carga del snippet JS alojado externamente.

Se observa en la figura 4 que el script hace la petición al dominio externo (CDN), para obtener el contenido del snippet, y si el estado de la respuesta es "OK" (a saber, HTTP 200), el contenido es devuelto.

Fase 2: verificaciones de control

Después de la llamada f(), que devuelve una cadena de caracteres del script, se invoca el método eval, añadiendo la string “downAndExec(\”<parametro_1>\”, \”<parametro_2>\”)” al final del snippet JS.

Figura 5: Llamada de downAndExec que añade C&C y x-id al snippet JS.

El primer parámetro (<parametro_1>) corresponde a la URL donde está alojado el C&C, mientras que el segundo (<parametro_2>) contiene el dato de “x-id” que, como veremos más adelante, es necesario para descargar otros payloads.

Figura 6: Relación de los archivos involucrados en downAndExec.

El snippet JS posee diversas cadenas que se asignan en tiempo de ejecución. Eso dificulta la comprensión del script cuando se realiza un análisis estático, aunque los nombres de las funciones no hayan sido modificados u ofuscados.

Figura 7: Ofuscación utilizada en el snippet JS.

El fragmento principal de ese script refiere justamente a la función downAndExec(), que es añadida por el primer downloader NSIS. De esa forma, en caso de que el snippet JS sea analizado de manera separada, posiblemente por alguna solución de sandboxing, las funciones maliciosas no serán ejecutadas y es muy probable que el snippet no sea detectado como malicioso.

Figura 8: Definición de downAndExec() en el snippet JS.

Además de la protección contra sandboxing, el script también hace algunas verificaciones antes de ejecutar el fragmento malicioso, para filtrar solo los equipos potencialmente interesantes para los cibercriminales.

La primera verificación es isOS(), que en este caso devuelve solamente true, aunque podría utilizarse como un código auxiliar quizá si los cibercriminales siguen evolucionando la amenaza. La segunda es haveAnyPrograms(),  que verifica la instalación de algunos programas.

Figura 9: Estructura de función haveAnyProgram() que busca software bancario en el sistema.

Las funciones getPathfromGuid() y getPathFromGuidWow() hacen la búsqueda de archivos a través de la existencia de claves CLSID en HKCR. Los archivos buscados vía CLSID son:

En caso de que ninguno de los archivos sea encontrado, el script busca carpetas asociadas a entidades bancarias. El caso de las muestras analizadas en esta investigación se centra en bancos que operan en Brasil, como Bradesco, Itaú, Sicoob y Santander.

La búsqueda de esos archivos intenta evitar la activación de las funcionalidades maliciosas en computadoras que probablemente no son utilizadas para online banking. Así, el nivel de detecciones disminuye, quedando fuera de la mira de los analistas, mientras que la efectividad permanece bastante alta.

Hay una tercera verificación para comprobar si la conexión parte de Brasil, en el caso de encontrar algunos de los archivos buscados. Como las cuentas de las víctimas de interés de las amenazas investigadas están en Brasil, a fines de evadir los análisis (principalmente automáticos) realizados fuera del país, el snippet verifica si la IP del cliente es de algún proveedor de servicio brasileño.

Figura 10: Función para verificar que el origen del acceso está en Brasil.

La verificación se hace a través de la API de ip-api.com, que devuelve datos referentes a la IP pública suministrada por el proveedor cuando el cliente se conecta a Internet. En caso de que countryCode sea "BR", el snippet verifica con éxito la tercera condición y pasa a la ejecución del fragmento malicioso.

Fase 3: comunicación con el C&C y ejecución del payload

Si las verificaciones hechas por la amenaza cumplen con las condiciones esperadas por los atacantes, la ejecución lleva a la comunicación con el C&C para finalizar con el compromiso de la máquina.

Figura 11: Principal fragmento de ejecución del snippet JS.

La función dlToText_s(), (ver línea 497 en la Figura 11) recibe dos parámetros: la URL del servidor de C&C y una string adicional; ambos corresponden con los parámetros pasados a la función downAndExec.

El primer parámetro de dlToText_s() (o sea, “<parametro_1>/?t”) indica cuál payload del C&C debe bajarse, mientras que el segundo parámetro sirve para proteger la descarga del payload por un campo “x-id” (de valor <parametro_2>) añadido al encabezado de la solicitud GET.

Figura 12: Funciones utilizadas para la descarga de payloads del C&C.

El archivo t, al momento del análisis, contenía solo el valor "3". Como vemos en downAndExec(),  hay diferentes comportamientos posibles basados en el valor de t.

Figura 13: Contenido del archivo t.

Ese valor corresponde a la variable K, la cual es utilizada como control y determina alguna de las siguientes posibilidades:

• K = “1”: el snippet sale de ejecución sin realizar ninguna acción maliciosa.
• K = “3”: el snippet realiza la descarga de tres archivos, siendo uno de ellos solo una cadena de caracteres (con el nombre de un archivo DLL), y otros dos archivos PE. Se invoca la función runAsUser ().
• K = “4”: caso semejante al anterior, aunque solo se descargan dos archivos PE y, en lugar de runAsUser(), se invoca la función runAsRundll().

El archivo ep (para K = "4") no estaba disponible para descarga, por lo que todavía no es posible saber qué sucede en ese caso. Para K = "3", los archivos descargados son:

Nuestro análisis indica que el payload es Win32/Spy.Banker. También sabemos que el hecho de ejecutar CERTMGR.EXE indica que el PE malicioso es inyectado en la memoria a través de precarga de DLL (DLL preloading attack).

Como hemos visto, la técnica downAndExec involucra dos etapas de descarga y diversas protecciones, tanto para filtrar solo las máquinas con perfil deseable como el hecho de que se encuentren en los territorios objetivos de los atacantes, en este caso Brasil.

El hecho de encontrar la propagación de esta amenaza dispara cuestiones que debemos seguir investigando en relación a downAndExec:

• ¿Por qué se usa una CDN para alojar el snippet JS?
• Hay funciones como runAsAdmin() que no están siendo utilizadas. ¿Estaría el snippet JS sirviendo de módulo compartido para otros malware del cibercrimen brasileño?
• ¿Cómo debería funcionar la infección cuando K = “4”?

A medida que encontremos respuestas a estas preguntas te mantendremos al tanto, así que no dejes de visitar WeLiveSecurity.

Indicadores de Compromiso (IoC)