Análisis de Flame parte I. El FAIL

Estándar

Hola a tod@s!

Esta semana dedicaré una serie de entregas al análisis del Malware Flame. Espero que estas engregas sirvan para guiar al analista en su investigación, y que no cometa los mismos errores que estoy cometiendo yo!

Desde principios de este mes se conoce de la existencia de un malware que está ocupando todas las portadas de los blogs más importantes dentro del panorama de la seguridad. Personalmente, me enteré de este “elemento” leyendo una entrada en Hispasec escrita por el genial Sergio de los Santos, y que me mantuvo entretenido buena parte de un trayecto en metro.

Como me picaba la curiosidad, esa misma noche, me puse a buscar alguna muestra del Malware, y fijar algún día en la agenda para “jugar” con la misma.

Antes siquiera de “jugar”, me encuentro con otra interesantísima entrada de Luis Delgado, en la que explica básicamente el funcionamiento del bicho, así como un script en python, el cual determina una infección, en base a consultas al registro, así como a ficheros residuales que deja el propio Malware.

Ese mismo día, y desde el blog de AlienVault, Jaime Blasco nos deleita con una interesantísima entrada, hablando esta vez, de la posible “edad” del Malware. La muestra analizada por Jaime (MD5:bdc9e04388bda8527b398a8c34667e18), coincide con la que me dispongo a utilizar yo.

Días más tarde, me vuelvo a encontrar con otra noticia del mismo elemento, pero esta vez escrita por mi querido y siempre mordaz Yago. En esta entrada, habla de Flame y los certificados digitales, lanzando una primera aproximación acerca de la función principal de esa firma digital.

Una vez leída y releída toda la documentación existente sobre el Malware Flame, me he dispuesto a realizar un pequeño análisis del mismo, sólo por morbosa curiosidad, y de momento, este es el resultado.

Según el documento “oficial”, en el que se explica los entresijos de este bicho, si se desea reproducir la infección en una máquina para su análisis, se pueden realizar dos operaciones, las cuales, ofrecerían el mismo resultado.

La primera, y la más rápida, es ejecutar el fichero a través de línea de comandos, registrando el OCX a través de la herramienta rundll32.

Imagen 1.- Intentando arrancar Flame

La otra manera de arrancar la muestra, es ayudando al Malware a auto-ejecutarse en el próximo reinicio. Para llevar a cabo esta acción, se indica en el documento que Flame se carga como un proveedor de autenticación, tal y como se puede ver en la siguiente imagen:

Imagen 2.- Detalles del Malware Flame

Para realizar esta acción, en el documento se especifica la clave de registro sobre la cual hay que adjuntar la muestra, para su posterior carga.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

La máquina sobre la que me dispongo a realizar las pruebas de infección es un Windows XP Service Pack 3 en español 32 bits. El método de infección que escojo es el primero, es decir, registrando el Malware a través de línea de comandos, a través de rundll32.

Una vez ejecutado el comando, la herramienta rundll32.exe, logra arrancar el OCX. Observando el comportamiento a través de Process Monitor, me encuentro con que la primera acción que realiza el Malware, es establecer un valor aleatorio en la clave SEED de la siguiente ruta de registro:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\RNG

El valor que reside en la clave SEED, es el valor que utiliza la CRYPTO API de Windows, a la hora de generar números aleatorios.

Las siguientes acciones derivan en la consulta de drivers instalados, así como consultas al directorio TEMP del Sistema.

Una vez que realiza todas estas consultas, el Malware genera un Log en el directorio Windows llamado Ef_trace.log. Un aspecto curioso de esta acción, me lo encuentro a la hora de comprobar cómo Flame cambia el Timestamp del fichero, lo que dificultaría su detección en un análisis forense, por ejemplo.

Imagen 3.- Cambio de timestamp de fichero

Acto seguido, realiza operaciones de escritura sobre el mismo, tal y como se puede comprobar en la siguiente imagen:

Imagen 4.- Escritura de fichero Ef_trace.log

A la hora de abrir este fichero, me encuentro con información cifrada, tal y como apuntan varios blogs de seguridad, que hacen mención al fichero en sí.

Imagen 5.- Datos cifrados en Ef_trace.log

El siguiente movimiento de Flame es preguntar por los proveedores de autenticación, fecha y hora del sistema, parámetros relativos al nombre de máquina y configuración de red. Y cuando ha obtenido toda la información…. SE PARA!!

Como os podréis imaginar, mi cara de FAIL era un poema. Así que empiezo a tirar de documentación, para comprobar si había errado en algún movimiento. Las siguientes 3 ejecuciones se comportan de la misma manera a lo descrito en anteriores párrafos.

Analizando cada entrada arrojada por Process Monitor, me encuentro con una que me parece sospechosa, la cual se encuentra ya documentada por anteriores analistas. Cuando se intenta inicializar Flame, éste realiza una consulta a un directorio concreto, para ver si se encuentra un fichero. En la siguiente imagen podréis comprobar cómo la consulta devuelve un resultado de NOT FOUND.

Imagen 6.- Consulta a controlador wavesetup3.drv

Como no sabía por donde tirar, elucubro la posibilidad de que pueda haber alguna incompatibilidad debida al idioma. Si el Malware está diseñado para Windows XP, puede haberla, ya que en versiones anteriores a Windows Vista, el idioma viene integrado en el Kernel.

Instalado el sistema en inglés, y ejecutando la muestra sobre éste, se comporta de la misma manera que el anterior. ¿En qué falla? ¿Qué estoy haciendo mal?

Tras una pausa (en la que me cagué en todo…), tiro de teléfono y llamo a Seifreed, buscando alguna orientación. Aprovecho para darle las gracias desde aquí, ya que en este paso fui mucho más rápido gracias a él.

Marc me comentó que él sí lo había podido lanzar sin ningún problema, y que su máquina de pruebas era un Windows XP SP2 en Spanish, lo cual me dejó totalmente sin ideas. En su ejecución, el malware había realizado conexiones y se había propagado con éxito en el equipo. Ni problema de idioma, ni Service Packs, ni hostias…..

Mañana publicaré la segunda parte de este relato, y descubriremos algunos mecanismos de seguridad que realiza Flame para poder ejecutarse en un entorno “controlado”….

Saludos a tod@s!!

Referencias

http://msdn.microsoft.com/en-us/library/windows/desktop/aa379942(v=vs.85).aspx

www.crysys.hu/skywiper/skywiper.pdf