Millones de usuarios que visitaron conocidos sitios web de noticias han sido atacados por una serie de anuncios publicitarios maliciosos que redirigían a un exploit kit que busca aprovecharse de diversas vulnerabilidades en Flash. Por lo menos desde comienzos de octubre, los usuarios se han encontrado con anuncios que promocionaban aplicaciones que se llamaban a sí mismas “Browser Defence y “Broxu”, utilizando banners similares a estos:

Estos anuncios fueron alojados en un dominio remoto con la URL hxxps://browser-defence.com y hxxps://broxu.com.

Sin que sea necesaria la interacción del usuario, el script inicial reporta información sobre el equipo de la víctima al servidor remoto del atacante. Luego, basándose en una lógica del lado del servidor, se le presenta a la víctima ya sea una imagen “limpia” o su casi imperceptible y modificado gemelo malvado.

La versión maliciosa de la imagen tiene un script cifrado en su alpha channel, que define la transparencia de cada pixel. Dado que la modificación es pequeña, el tono de la imagen es apenas diferente al de la versión limpia.

Utilizando la conocida vulnerabilidad de Internet Explorer CVE-2016-0162, el script cifrado intenta verificar si no está siendo ejecutado en un entorno monitoreado como por ejemplo el equipo de un analista de malware.

Si el script no detecta ninguna señal de monitoreo, redirige a la landing page del exploit kit Stegano, a través del servicio TinyURL. Esta página carga un archivo Flash que permite explotar tres vulnerabilidades diferentes (CVE-2015-8651, CVE-2016-1019, CVE-2016-4117), dependiendo de la versión de Flash que se encuentre en el sistema de la víctima.

Luego de la explotación exitosa, el shell code ejecutado recolecta información de los productos de seguridad instalados y realiza otro chequeo para verificar que no está siendo monitoreado. Si los resultados son favorables, intentará descargar desde el mismo servidor, el payload cifrado “disfrazado” de una imagen gif.

El payload es luego descifrado y ejecutado a través de regsvr32.exe o rundll32.exe. Los payloads  detectados hasta el momento incluyen backdoors, troyanos bancarios, spyware, ladrones de archivos y varios trojan downloaders.

Análisis técnico del exploit kit Stegano

Una variante anterior de este escurridizo exploit pack se ha estado ocultando ante los ojos de todos por lo menos desde 2014, cuando fue advertido atacando consumidores holandeses. En 2015 los atacantes se focalizaron en la República Checa y ahora han cambiado su foco hacia Canadá, Reino Unido, Australia, España e Italia.

En campañas anteriores, en un esfuerzo por enmascararse como un anuncio publicitario, el exploit kit utilizaba nombres de dominios que comenzaban con “ads*.” y nombres de URL que contuvieran watch.flv, media.flv, delivery.flv, player.flv, o mediaplayer.flv.

En la presente campaña, los atacantes han mejorado sus tácticas de manera significativa. Al parecer, el hecho de que el exploit pack esté apuntado a países específicos es el resultado de la posibilidad de aprovecharse de redes publicitarias que tuvieron los atacantes.

Podemos decir que incluso los exploits kits más importantes, como Angler y Neutrino, han sido superados por Stegano en término de referencias, esto es, sitios web en los que han logrado instalar los banners maliciosos. Hemos observado dominios muy importantes, que incluyen sitios de noticias visitados por millones de personas por día, actuando como “referencias” que alojan estos anuncios.

Al llegar al espacio publicitario, el navegador muestra un banner ordinario al lector. Pero, hay mucho más que una publicidad.

Publicidad esteganográfica

En la mayoría de los casos, el anuncio promocionaba un producto llamado “Browser Defence” y solo recientemente se ha detectado que aparecieron banners que promocionan el software “Broxu”. De todas maneras, para mantenerlo simple y porque las campañas son prácticamente idénticas (aparte del banner y el dominio, por supuesto), solo la campaña de “Browser Defence” se analiza debajo.

Los anuncios estaban alojado en el dominio browser-defence.com con una estructura URI similar al siguiente (notar el https):

hxxps://browser-defence.com/ads/s/index.html?w=160&h=600

El index.html carga countly.min.js y le brinda los parámetros iniciales al script. Este countly, no es la librería de la plataforma open source de analítica web y mobile que podrías descargar de github. Es una versión totalmente modificada y ofuscada, con algunas partes eliminadas y con código agregado. Este último es el responsable del chequeo del entorno inicial. La información ambiental es reportada al servidor como parámetros XOR cifrados del archivo gif 1×1, tal como se ve en la imagen anterior.

La siguiente información del entorno es enviada:

systemLocale^screenResolution^GMT offset^Date^userAgent^pixelRatio

Luego de eso, el script solicita el banner publicitario. El servidor responderá ya sea con una versión limpia o con una maliciosa, dependiendo principalmente en el chequeo del entorno previo.

El script luego intentará cargar el banner y leer la estructura RGBA. Si una versión maliciosa de la imagen fuera recibida, ejecutará algunos Javascript y variables del alpha channel.

La esteganografía es implementada de la siguiente manera: dos valores alpha consecutivos representan los diez y unos de un character code, cifrado como una diferencia de 255 (el full alpha). Además, para hacer más difícil la detección del cambio, la diferencia es minimizada usando un offset de 32.

Por el ejemplo si los primeros alpha bytes contenían los valores 239, 253, 237, 243, 239, 237, 241, 239, 237, 245, 239, 247, 239, 235, 239 y 237, descifrarán la palabra “function”. En este ejemplo, los primeros dos alpha values 239,253 nos dan una ‘f’:

Una mirada más profunda a los banners limpios y a aquellos con el código Stegano muestra una sutil diferencia.

El alpha channel de los pixels inutilizados están llenos de valores pseudoaleatorios, para hacer que el “ruido alpha” esté distribuido de manera pareja y sea más difícil de advertir.

Luego de una extracción exitosa, se chequea la integridad del código JS frente al hash cifrado al final de la imagen, para luego ser ejecutado.

Después de esto, el nuevo script intenta chequear el entorno del navegador y del equipo utilizando una conocida vulnerabilidad de Internet Explorer, CVE-2016-0162. En particular, está focalizado en revisar la presencia de captura de paquetes, sandboxing y software de virtualización, así como también varios productos de seguridad. Además revisa varios drivers gráficos y de seguridad para verificar si está siendo corrido en una máquina de verdad. Más detalles pueden ser encontrados en el Apéndice 1.

Si no hay ningún indicio de que exista un monitoreo, se crea un iframe (solo un pixel de tamaño) por fuera de la pantalla, y establece su propiedad window.name (este nombre será utilizado más adelante) y redirige a TinyURL vía https. TinyURL luego redirige a una landing page que contiene exploit, vía http. El referente al sitio original se pierde durante este proceso.

El exploit

Luego de la redirección exitosa, la landing page chequea el userAgent, buscando el Internet Explorer, carga un archivo Flash y ajusta los parámetros FlashVars a través de un archivo JSON cifrado. La landing page además oficia como un intermediario para el Flash y el servidor a través de ExternalInterface, y provee funciones básicas de cifrado y descifrado.

El archive Flash contiene otro archive Flash embebido y, parecido al exploit kit Neutrino, viene con 3 exploits diferentes basados en la versión de Flash.

El archive Flash del segundo estadío descifra el FlashVars, que contiene un archivo JSON con URI para el reporte de errores, nombres de función para ExternalInterface, el nombre de la función callback y algo de datos no utilizados:

{“a”:”\/e.gif?ts=1743526585&r=10&data=”,”b”:”dUt”,”c”:”hML”,”d”:true,”x”:”\/x.gif?ts=1743526585&r=70&data=”}

Subsecuentemente, invoca un JS a través de ExtelnalInterface.call() que chequea la versión de Flash y se lo comunica al servidor vía la landing page. Esto es realizado a través de un parámetro URI cifrado de un pedido para un archivo GIF. El algoritmo de cifrado es simple, y utiliza el window.name del anuncio:

La respuesta es una imagen GIF de la cual los primeros bytes son descartados y el resto es descifrado usando el mismo algoritmo y luego pasado a Flash.

La respuesta es un JSON que contiene una letra que denota qué exploit utilizar (CVE-2015-8651, CVE-2016-1019 o CVE-2016-4117), una contraseña con el exploit correspondiente y un Shell code listo con el URI para el payload.

El shell code

El shell code es descifrado en la última etapa durante la fase de explotación. Intentará descargar un payload cifrado, el cual también está disfrazado como una imagen GIF. Pero antes, realiza otro chequeo en búsqueda de signos que pudieran sugerir que está siendo analizado.

Está particularmente interesado en la presencia de software que contenga los siguientes strings en su nombre de archivo:

• exe
• exe
• exe
• dll
• DLL
• exe
• exe
• exe
• exe
• exe
• exe
• exe
• eset*, kasper*, avast*, alwil*, panda*, nano a*, bitdef*, bullgu*, arcabi*, f-secu*, g data*, escan*, trustp*, avg*, sophos*, trend m*, mcafee*, lavaso*, immune*, clamav*, emsiso*, superanti*, avira*, vba32*, sunbel*, gfi so*, vipre*, microsoft sec*, microsoft ant*, norman*, ikarus*, fortin*, filsec*, k7 com*, ahnlab*, malwareby*, comodo*, symant*, norton*, agnitu*, drweb*, 360*, quick h

Si detecta algo sospechoso, no intentará descargar el payload.

El payload

Si el payload es recibido, los primeros 42 bytes del GIF son descartados, el resto es descifrado y guardado en un archivo, utilizando los siguientes métodos:

1. CreateFile, WriteFile
2. CreateUrlCacheEntryA(*” https://google.com/”,,,,), CreateFileA, CreateFileMappingA, MapViewOfFile, {loop of moving bytes}, FlushViewOfFile, UnmapViewOfFile

El payload es luego lanzado a través de regsvr32.exe o rundll32.exe.

Durante nuestra investigación, hemos visto los siguientes payloads descargados por el exploit kit Stegano:

Win32/TrojanDownloader.Agent.CFH

Win32/TrojanDownloader.Dagozill.B

Win32/GenKryptik.KUM

Win32/Kryptik.DLIF

Luego de un análisis detallado de los Downloaders y Kryptiks (estos últimos son las detecciones de ESET de variantes ofuscadas), hemos encontrado que contenían o descargaban los códigos maliciosos Ursnif y Ramnit.

Ursnif tiene una multitud de módulos para robar credenciales de email, contiene un backdoor, keylogger, hace capturas de pantalla, crea videos, inyecta código en Internet Explorer/Firefox/Chrome modificando el tráfico http, y puede robar archivos del equipo de la víctima. De acuerdo a los archivos de configuración encontrados en las muestras analizadas, parecen estar apuntando al sector corporativo, focalizándose en servicios e instituciones de pago.

Ramnit es un infector de archivos que también ha estado apuntándole al sector bancario, utilizando sus variadas capacidades tales como la exfiltración de información, la creación de capturas de pantalla, ejecución de código y mucho más.

Conclusión

El exploit kit Stegano ha estado intentando pasar desapercibido por lo menos desde 2014. Sus autores han puesto bastante esfuerzo en implementar varias técnicas para alcanzar el ocultamiento. En una de las campañas más recientes que detectamos, que pudimos rastrearla hacia comienzos de octubre de 2016, los atacantes estuvieron distribuyendo el kit a través de banners publicitarios utilizando la esteganografía y realizando varios chequeos para confirmar que no estaban siendo monitoreados.

Fuente:https://www.welivesecurity.com/