¡Que alguien llame a los bomberos!: apagando las llamas de los servidores C&C de Flame

El domingo 27 de mayo de 2012, el MAHER CERT anunció el descubrimiento de un nuevo ataque dirigido llamado “Flamer”. El lunes 28 de mayo de 2012, a las 9 am EST, después de una investigación solicitada y apoyada por la Unión Internacional de Telecomunicaciones, Kaspersky Lab y CrySyS Lab de Hungría anunció el descubrimiento de Flame (también conocido como Skywiper), una herramienta de ciberespionaje muy sofisticada que tiene como principal objetivo de sus ataques ordenadores en el Oriente Medio.

Unas horas después, hacia las 4 pm GMT, la infraestructura de comando y control de Flame, que había estado funcionando por años, dejó de funcionar.

Kaspersky Lab ha estado vigilando de cerca la infraestructura C&C de Flame durante las últimas semanas. Gracias a la colaboración de GoDaddy y OpenDNS logramos aislar gran parte de los dominios maliciosos que Flame utiliza como C&C y así conseguir una perspectiva única de la operación.

Antes de continuar, Kaspersky Lab quiere agradecer a “GoDaddy Network Abuse Department” y a William MacArthur por sus rápidas intervenciones e intenso apoyo en esta investigación. El equipo de investigación de seguridad de OpenDNS también ofreció asistencia muy valiosa durante la investigación.

A continuación te presentamos lo que descubrimos al analizar la infraestructura:

Introducción

Como parece que tanto Flame como Duqu atacan las misma regiones y se crearon con fines similares, mostraremos un análisis comparativo entre la infraestructura C&C de Duqu y la de Flame.

Kaspersky Lab ya había analizado la infraestructura C&C de Duqu , y descubrió mucha información importante, como la preferencia de los atacantes por CentOS, el uso de SharpSSH para controlar los servidores proxy y la gran cantidad de proxies alterados que se usaron para esconder la verdadera identidad de los atacantes.

Realizamos un análisis similar en el caso de Flame. En primer lugar, es interesante destacar que hay una gran diferencia entre Flame y Duqu: mientras que todos los proxies C&C de Duqu eran anfitriones CentOS de Linux, todos los C&C de Flame que se conocen hasta ahora funcionan con Ubuntu.

Es más, mientras que Duqu utilizaba un método ultra sigiloso para esconder la verdadera IP de su nave nodriza utilizando puertos de reenvío SSH, los scripts de Flame simplemente se ejecutan en sus servidores respectivos. Y esto es por una simple razón: el lunes 28 de mayo, todos los scripts de control comenzaron a mostrar errores 403/404. En el caso de Duqu, los verdaderos scripts del malware estaban en un servidor remoto y nunca se encontraron.

Desde este punto de vista, podemos decir que los atacantes de Duqu eran mucho más cuidadosos que los operadores de Flame en esconder sus actividades.

Esta es una comparación entre las infraestructuras C&C de Duqu y de Flame:

Cuando un ordenador está infectado con Flame, utiliza una configuración predeterminada que incluye 5 servidores de dominios C&C. Antes de ponerse en contacto con estos servidores, el malware valida la conexión a Internet tratando de acceder a www.microsoft.com, windowsupdate.microsoft.com y www.verisign.com con HTTPS. Si logra hacerlo, procede a comunicarse con los dominios C&C.

Además de su configuración estática, Flame mantiene una base de datos de servidores C&C adicionales. Hemos visto que la base de datos adicional, que se puede actualizar desde el mismo servidor C&C, contiene 5 o 6 dominios extra. En total, mientras se instala Flame, el programa puede utilizar una lista de alrededor de 10 dominios para tratar de ponerse en contacto con el C&C. Merece mencionar que Flame mantiene un registro de sus actividades que incluye informes de las conexiones a los servidores C&C con las marcas del momento en que ocurrieron.

Mientras analizábamos los ejemplares de Flame que se encontraron en Oriente Medio, notamos que intentaban ponerse en contacto con 5 dominios diferentes. Las configuraciones adicionales incluían otros 6 dominios. Conseguimos otros 5 dominios desde los registros de las actividades. Nuestro ejemplar de malware específico utiliza un total de 11 dominios únicos.

Al ver las direcciones IP en las que se alojaban los servidores, identificamos otros 30 dominios alojados en los mismos equipos. Cuando revisamos el historial de IPs de los dominios adicionales, descubrimos otros 40 dominios que parecían conectados. En total, descubrimos más de 80 dominios diferentes que creemos que pertenecen a la infraestructura C&C de Flame.

Los dominios C&C de Flame estaban registrados con una impresionante lista de identidades falsas y una gran variedad de titulares que se remonta hasta 2008. En general, cada identidad falsa registró entre 2 y 3 dominios, pero en algunas ocasiones una misma identidad registró hasta 4.

El paquete más grande de dominios C&C de Flame se registró con GoDaddy.

Estas son algunas de las identidades falsas que se utilizaron para registrar los dominios: Adrien Leroy, Arthur Vangen, George Wirtz, Gerard Caraty, Ivan Blix, Jerard Ree, Karel Schmid, Maria Weber, Mark Ploder, Mike Bassett, Paolo Calzaretta, Robert Fabous, Robert Wagmann, Romel Bottem, Ronald Dinter, Soma Mukhopadhyay, Stephane Borrail, Traian Lucescu, Werner Goetz y Will Ripmann.

Muchas de estas identidades falsas tienen direcciones inventadas en Alemania y Austria, en particular en Viena. No sabemos por qué los atacantes se sintieron tan atraídos por Viena.

Veamos con más detalle los registros falsos. Tomemos como ejemplo el dominio “chchengine.com”, uno de los que utiliza el malware. Está registrado por un tal “Karel Schmid”, cuya dirección es “rue dizerens 7, Ginebra”. Esta es en realidad la dirección de un hotel llamado “Appart’Hotel Residence Dizerens”:

Este es otro ejemplo, un dominio registrado por alguien llamado “Ivan Blix”.

La dirección del dueño del dominio aparece como “Koninginneweg 93, Oslo”. Al buscar esta dirección, descubrimos que no existe este lugar en Oslo. Pero sí existe uno en Amsterdam. En este caso, también es la dirección de un hotel, llamado “Apple Inn”:

Todas las demás identidades falsas utilizaron direcciones de hoteles, tiendas, organizaciones, consultorios médicos o simplemente direcciones que no existen.

Al recolectar información sobre la infraestructura C&C de Flame, pudimos crear una imagen más completa y clara de esta operación tan compleja. La cantidad de dominios y servidores que se usaron en esta operación concuerda con nuestra opinión previa sobre la complejidad de este malware:

Por ahora, el número total de dominios conocidos que utiliza Flame como C&C y dominios relacionados supera los 80. Se han registrado entre 2008 y 2012. Durante los últimos 4 años, servidores que alojaban la infraestructura C&C de Flame se estuvieron trasladando por Hong Kong, Turquía, Polonia, Malasia, Letonia y Suiza, entre otros. Así de grande es esta operación.

Después de ver la gran variedad de dominios falsos, nos pusimos en contacto con GoDaddy y le pedimos que redirija todos los dominios de malware a nuestro sinkhole. El equipo de seguridad de OpenDNS también nos ayudó a redirigir los dominios maliciosos a nuestro sinkhole para proteger a los usuarios de OpenDNS.

Los servidores C&C de Flame

Si contamos las direcciones IP que utilizan los dominios C&C de Flame durante los últimos 4 años, sin tomar en cuenta las IPs de los servidores de alojamiento conocidos que se utilizaron de forma temporal durante el registro, se llega a un total de 22 servidores IP diferentes.

Desde que se descubrió Flame, pudimos estudiar 5 de sus servidores. Todos tienen abiertos los puertos 22, 443 y 8080. Parece que están ejecutando Ubuntu Linux, si es que confiamos en los encabezados de Apache y SSH. Uno de ellos también tenía el Puerto 80 abierto, pero lo cerró después de que se anunciara el descubrimiento de Flame.

Los certificados SSL que utiliza el C&C Flame tienen firma propia; parece que el certificado del último dominio activo (en Holanda) se generó el 18 de mayo de 2012.

Un dato interesante es que el sábado 2 de junio de 2012, a las 20:40 GMT, varios dominios C&C de Flame que solían dirigir a un servidor en Holanda (91.203.214.*) se redirigieron a un servidor en Alemania (78.46.253.*).

El nuevo servidor se desactivó el domingo 3.

Estadísticas de Kaspersky Security Network

Kaspersky Security Network (KSN) es la infraestructura en la nube que utilizan los productos Kaspersky Lab para informar sobre telemetría y entregar protección instantánea como listas de rechazados y reglas heurísticas para atrapar las amenazas más recientes.

Utilizamos KSN para rastrear Flame, basándonos en el hecho de que utilizaba algunos nombres de archivos que, de otra manera, eran únicos en el proyecto. Después obtuvimos una muestra del código de malware y lo utilizamos para rastrear la distribución del malware en el mundo.

Estadísticas actuales de KSN sobre Flame

:

Es obvio que la gran mayoría de los objetivos de Flame están en el Oriente Medio. Es importante notar que algunas de las víctimas pueden haber usado servicios VPN/proxy. En aquellos casos, por ejemplo, un ordenador infectado podría aparecer con una dirección IP europea aunque en realidad esté en el Oriente Medio. Además, algunas “víctimas” podrían ser en realidad otros investigadores. Pero, en general, las estadísticas reflejan la verdadera distribución geográfica de las infecciones.

Aquí se puede ver su distribución geográfica:

¿Y qué pasa con los sistemas operativos infectados por Flame? Esta es una representación de las infecciones desde el punto de vista de la versión específica de Windows en la que se encontró Flame:

La gran mayoría de las infecciones de Flame son ordenadores que ejecutan Windows 7 de 32 bits. Le sigue Windows XP. Es importante notar que Flame no se ejecuta en Windows 7 de 64 bits, lo que habíamos recomendado como una buena solución contra las infecciones de otros programas maliciosos.

Estadísticas de Sinkhole / OpenDNS:

Nuestro colaborador, OpenDNS, elaboró una cronología de los registros de dominios C&C de Flame durante los últimos años: http://blog.opendns.com/2012/06/01/unique-insight-into-flame-malware/.

Puedes ver su cronología animada en este sitio: https://www.opendns.com/flame-timeline/

Durante la semana pasada, nuestro sinkhole registró múltiples entradas de usuarios infectados, abajo puedes verlos organizados por ubicación. Es importante notar que los productos antivirus ya han limpiado la gran mayoría de las infecciones, así que lo que estamos viendo son víctimas que no tienen instalados productos antivirus o los tienen desactualizados.

Además, hemos detectado algunas infecciones en compañías de seguridad del Reino Unido, España, Rusia y Rumania.

Estos son los 10 dominios que utilizan los ordenadores infectados con mayor frecuencia para contactar con nuestro sinkhole:

En la actualidad, los siguientes 28 dominios relacionados con Flame están en un sinkhole de Kaspersky Lab:

flashupdates.info, nvidiadrivers.info, nvidiasoft.info, nvidiastream.info, rendercodec.info, syncstream.info, videosync.info, dnslocation.info, dnsmask.info, dnsportal.info, dnsupdate.info, flushdns.info, localgateway.info, pingserver.info, serveflash.info, serverss.info, autosync.info, bannerspot.in, bannerzone.in, micromedia.in, mysync.info, newsync.info, syncdomain.info, synclock.info, syncprovider.info, syncsource.info, syncupdate.info y ultrasoft.in.

Datos enviados al sinkhole

Flame hace una solicitud POST identificándose cada vez que se conecta al sinkhole. Después envía un bloque más grande de datos, que contiene mucha información “interesante” como la versión del malware, su configuración, un historial de las actividades del sistema, datos extraídos de documentos, etc.

Se utiliza la misma contraseña, “LifeStyle2”, en todas las configuraciones que hemos visto. La contraseña se guarda en el archivo de configuración de Flame y se puede cambiar.

Los paquetes de datos que se envían al sinkhole contienen registros codificados y otra información comprimida. Al decodificar los datos, se puede encontrar la versión específica de Flame que se está comunicando con su dueño.

Esta es la distribución de las versiones de Flame que se conectan a nuestro sinkhole:

La mayoría de las víctimas tiene la versión 2.242, que también es la versión que descubrimos primero y estamos analizando. Parece que esa es la variante más popular. Lo interesante es que no es la más reciente, ¡ya hay una víctima infectada con la versión 2.243!

La versión 2.080 también es interesante; es un “mssecmgr.ocx” de mucho menor peso (unos 890 K) que no tiene muchos de los módulos de las variantes de 6 MB. Tenemos una copia de esta modificación y la estamos analizando al mismo tiempo que a la versión más grande.

También hay algunos casos muy interesantes entre los ordenadores que se conectan a nuestro sinkhole: tres ordenadores están en Líbano, Irak e Irán. Durante la operación sinkhole, cambiaron las versiones de Flame en estos equipos; lo que da a entender que Flame se actualizó a sí mismo en el proceso. Por ejemplo, en dos ocasiones, la versión 2.212 se convirtió en 2.242. Esto indica la presencia de C&Cs desconocidos que operaban a la vez que el sinkhole, o algún mecanismo de actualización desconocido.

Los atacantes parecen muy interesados en los dibujos AutoCAD que encuentran entre los datos que extraen de los sistemas. Este es un dato interesante, porque se sabe que los dibujos AutoCAD también eran un objetivo del malware Duqu. Además de los archivos DWG, que es el formato específico de los archivos de AutoCAD, el malware busca archivos PDF, de texto y otros documentos y realiza resúmenes cortos en texto. También busca correos electrónicos y otro tipo de archivos “interesantes” (valiosos) que se especifican en la configuración del malware.

Los datos que se envían al servidor C&C se codifican con un sencillo cifrado XOR combinado con un cifrado de apoyo. Además, muchos bloques de dentro se comprimen usando las bibliotecas de compresión zlib y ppdm.

Los datos que se envían al sinkhole se dividen en paquetes de 8192 bytes. Es probable que haga esto para recuperación de errores: se sabe que el Internet del Oriente Medio es muy lento y no es de fiar.

Otra característica importante de Flame es que utiliza conexiones SSH para filtrar los datos. Aunque no hemos podido reproducir este comportamiento, parece que, cuando Internet funciona pero no se pueden alcanzar los servidores C&C mediante SSL, se utiliza una conexión SSH.

La conexión SSH se establece por medio de una biblioteca totalmente integrada basada en Putty. Hasta el momento no se conoce la dirección IP del servidor ni el nombre de usuario y contraseña que se usa. Es probable que se los actualice desde el C&C en algún momento y sólo se los utilice si aparecen problemas temporales en SSL. Una de las razones para utilizar conexiones SSH puede ser que en países como Irán es común que se bloquee el tráfico SSL/HTTPS. Si SSL no está funcionando, el malware también puede utilizar SSH para ponerse en contacto con el C&C.

Durante la semana pasada, Kaspersky Lab se puso en contacto con CERT en muchos países para darles información sobre los dominios C&C de Flame y las direcciones IP de los servidores maliciosos. Queremos darles las gracias por su apoyo en esta investigación.

Si eres parte de una institución GovCERT y quieres recibir más información sobre los dominios C2, por favor escríbenos a theflame@kaspersky.com.

Resumen y conclusiones:

• La infraestructura de comando y control de Flame, que ha estado operando durante años, dejó de funcionar en cuanto anunciamos la existencia del malware la semana pasada.
• Identificamos alrededor de 80 dominios en total, que creemos pertenecen a la infraestructura C&C de Flame.
• Los dominios C&C de Flame estaban registrados con una impresionante lista de identidades falsas y con una gran variedad de registrantes desde 2008.
• Parece que los atacantes tienen mucho interés por documentos PDF, Office y dibujos AutoCad.
• La información que se sube al C&C está codificada con algoritmos relativamente simples. Los documentos robados se comprimen con un Zlib de distribución abierta y reciben una compresión PPDM modificada.
• Flame está utilizando conexiones SSH (además de SSL) para filtrar más datos. La conexión SSH se establece por una biblioteca basada en Putty totalmente integrada.
• Parece que Windows 7 de 64 bits, que ya habíamos recomendado como una buena solución contra las infecciones de otros programas maliciosos, también es efectivo contra Flame.