Un singular bot “sin archivo” ataca a los visitantes de sitios de noticias

A principios de marzo un investigador independiente nos envió un informe sobre infecciones masivas en los ordenadores de una red corporativa después de que sus usuarios visitaran varios conocidos sitios de noticias en Rusia. Los síntomas eran los mismos en cada caso: el ordenador enviaba varias peticiones de red a recursos de terceras partes, tras lo cual, en algunos casos, aparecían en el disco duro varios archivos codificados.

El mecanismo de infección que usaba este programa malicioso resultó muy difícil de identificar. Los sitios web utilizados para propagar la infección estaban alojados en diversas plataformas y con distintas arquitecturas. Todos nuestros intentos por reproducir las infecciones fracasaron. Un rápido análisis de las estadísticas de KSN que podrían ayudarnos a identificar la conexión entre los recursos comprometidos y el código malicioso propagado tampoco produjo resultado alguno. Sin embargo, sí pudimos encontrar algo que los sitios de noticias tenían en común.

Fuentes de infección

Con el propósito de realizar un análisis, seleccionamos dos sitios de noticias que sabíamos que estaban propagando el programa malicioso: http://www.ria.ru/ (una importante agencia noticiosa rusa) y http://www.gazeta.ru/ (un popular periódico online). El almacenamiento regular de los contenidos de estos recursos no sirvió para identificar ningún script JS de terceras partes de ocasional aparición, etiquetas iframe, errores 302 ni ningún otro atributo que indicara que los recursos estuviesen comprometidos. Lo único que tenían en común era que ambos usaban los códigos AdFox del sistema de administración de banners, a través de los cuales se gestionaba el intercambio de teasers.

Código en la página principal de RIA.ru que se usa para descargar contenidos adicionales desde AdFox.ru

Descubrimos que el programa malicioso se descargaba a través de los teasers en AdFox.ru.
A continuación explicamos cómo se realizaba la infección. Un script JS para uno de los teasers descargados en el sitio incluía un iframe que desviaba al usuario hacia un sitio malicioso en el dominio .EU y que contenía un exploit Java.

Contenidos de un script JS infectado y uno limpio

El análisis del archivo JAR del exploit demostró que explotaba una vulnerabilidad de Java (CVE-2011-3544). Los ciberdelincuentes habían estado explotando esta vulnerabilidad desde noviembre mediante ataques dirigidos contra usuarios de MacOs y Windows. Los exploits para esta vulnerabilidad son de los más efectivos y están incluidos en los paquetes de exploits más comunes.
Sin embargo, el exploit utilizado en este caso era único y no había sido parte de ningún paquete de exploits: los ciberdelincuentes usaron su propia carga de datos en el ataque.

Parte de la carga de datos del archivo JAR

Programa malicioso “sin archivo”

Por lo general, el funcionamiento de un exploit de este tipo implica guardar en el disco duro un archivo malicioso, que suele ser un dropper o un descargador. Sin embargo, en este caso nos topamos con una sorpresa: no apareció ningún archivo nuevo en el disco duro.
Después de capturar todos los privilegios necesarios en el ordenador comprometido, el exploit no instala ningún programa malicioso en el disco duro mediante Java. En lugar de ello, usa su carga de datos para inyectar un archivo dll codificado desde la web directamente en la memoria del proceso javaw.exe. La dirección desde la cual se descarga la biblioteca está codificada en el iframe incluido en el script JS descargado desde AdFox.ru:

Una nueva sección RWE maliciosa en el proceso JAVAW.exe

Después de inyectar y ejecutar el código malicioso (dll), Java comienza a enviar peticiones a recursos de terceras partes; estas peticiones se parecen a las peticiones de búsqueda de Google: “search?hl=us&source=hp&q=%s&aq=f&aqi=&aql=&oq=”…

Las peticiones incluyen datos del historial de navegación tomado del navegador del usuario, así como información técnica adicional sobre el sistema infectado.

Es decir que nos enfrentamos a un programa malicioso muy raro, conocido como “sin archivo” (“fileless”, en inglés) que no existe como archivo en el disco duro, sino que opera únicamente en la memoria RAM del ordenador infectado. Los mejores ejemplos de estas amenazas son los gusanos CodeRed y Slammer que causaron infecciones masivas a principios de la década pasada.

Este tipo de programa malicioso funciona sólo hasta que se reinicia el sistema operativo, lo que parece no importarle a los autores de troyanos.

Una razón para ello es que este programa malicioso “sin archivo” funciona como un bot: después de enviar una serie de peticiones al servidor de comando y de recibir las respuestas, el exploit usa varios métodos diferentes para desactivar el UAC (User Account Control). A continuación, el bot procede a instalar el troyano Lurk en el equipo infectado. Vale la pena remarcar que la decisión sobre la instalación de Lurk en el sistema se la toma en el servidor de los ciberdelincuentes.

La segunda razón es que las probabilidades de que el usuario vuelva al sitio web infectado después de que se reinicia el sistema, son altas. Esto resultaría en una re-infección, y el bot volvería a la memoria RAM del equipo capturado.

Puesto que ningún archivo se guarda en el disco duro, es muy difícil detectar el problema mediante una solución antivirus. Si no se logra detectar el exploit, el bot puede cargarse en la memoria RAM, volviéndose prácticamente invisible.

Lurk

El programa malicioso Trojan-Spy.Win32.Lurk puede instalarse mediante los comandos “regsrv32” y “netsh add helper dll” o a través de la rama ShellIconOverlayIdentifiers del registro del sistema. Lurk instala sus módulos adicionales como archivos dll codificados.

Parte del código Lurk responsable de la descarga de los módulos adicionales
El análisis de los módulos adicionales de Lurk nos ha dado una visión de la funcionalidad de este programa malicioso: roba los datos confidenciales del usuario para acceder a los servicios de banca online de varios bancos rusos. Kaspersky Lab detectó este programa malicioso en julio de 2011. En base a nuestro análisis del protocolo usado por Lurk para comunicarse con los servidores de comando, logramos determinar que en un periodo de siete meses, estos servidores procesaron peticiones de hasta 300.000 equipos infectados.

Razones detrás del incidente

Después de aclarar el aspecto técnico del problema, notificamos a la administración de AdFox sobre el incidente. Los responsables tomaron medidas oportunas que resultaron en la detección y eliminación del programa malicioso del banner infectado.

En el transcurso de la investigación determinamos que los ciberdelincuentes habían usado la cuenta de un usuario de AdFox para cambiar el código de los banners con titulares de noticias añadiendo un iframe que desviaba a los usuarios hacia el sitio malicioso.

Tras modificar el código en uno de los banners, pudieron atacar no sólo a los usuarios del sitio de noticias, sino también a los visitantes de otros sitios que llevaban el mismo banner. Como resultado, la cifra de usuarios atacados podría ser dedecenas de miles. Sin embargo, los banners de otros clientes de AdFox no contenían el código malicioso.

Conclusión

Se trata de un ataque muy singular porque los ciberdelincuentes usaron su propio archivo descargador PE (carga de datos) que puede funcionar sin crear archivos maliciosos en el sistema infectado, operando por completo dentro de un proceso confiable de Java.

El uso de una red teaser es uno de los métodos más efectivos de los ciberdelincuentes para instalar códigos maliciosos, ya que produce una enorme cantidad de sitios populares vinculados al código.

Este ataque estaba dirigido contra los usuarios rusos. Sin embargo, no podemos descartar que este mismo exploit y el mismo bot “sin archivo” vuelvan a usarse contra usuarios en otras partes del mundo: pueden propagarse a través de redes similares de banners o teasers en otros países. Es probable que otros programas maliciosos, no sólo Trojan-Spy.Win32.Lurk, se usen para este fin.

Respecto a la protección contra esta amenaza, recomendamos encarecidamente a todos los usuarios que instalen el parche que repara la vulnerabilidad CVE-2011-3544 en Java. Actualmente, es la única forma de evitar una infección. Como ya hemos mencionado, los exploits para la vulnerabilidad CVE-2011-3544 son los más efectivos que existen y pueden usarse para instalar una variedad de programas maliciosos.

Además, se debe usar en todo mamento una solución de seguridad que incluya funciones antivirus web. También recomendamos a los usuarios de Kaspersky Lab que activen la función Geo Filter que ofrece el control manual sobre el acceso del navegador a los recursos en diferentes dominios geográficos y bloquea conexiones a sitios en la zona .eu, a menos que para el usuario sea esencial acceder a ellos. Hemos estado detectando varios recursos maliciosos en este dominio, incluyendo los descritos arriba, así como los servidores usados para propagar el troyano Hlux, al que nos referimos en una reciente entrada (El dónde y por qué de Hlux).

P.D. Nuestro sentido agradecimiento al investigador independiente, que desea permanecer anónimo, por su inestimable ayuda en la preparación de esta publicación.