La saga de Duqu continúa: presentamos al Sr. B. Jason y a Dexter, de la televisión

Como ya habíamos informado, hemos estado realizando una investigación sobre varios incidentes relacionados con una infección del troyano Duqu. Por suerte pudimos profundizar en algunos aspectos de Duqu y encontrar algunos de los componentes que no teníamos, sin los que habría sido muy difícil comprender la situación.

Ante todo queremos expresar nuestro más sincero agradecimiento a los especialistas de CERT Sudán. Nos han estado ofreciendo asistencia invaluable en nuestra investigación, y demostraron que tienen el más alto nivel de profesionalismo – en total concordancia con los valores y metas de todos los CERT del mundo. Seguimos trabajando en cooperación con el CERT de Sudán, y también analizaremos otros tres incidentes que afectan a este país.

Nuestro mayor logro ha sido en la investigación del incidente considerado N? 1, que describí en mi segunda entradasobre Duqu. No sólo pudimos localizar archivos de esta variante de Duqu que no se habían descubierto, también encontramos la fuente de infección y el archivo dropper que contiene el exploit para la vulnerabilidad en win32k.sys (CVE-2011-3402).

Comparando la información que descubrimos con la de otros analistas y empresas antivirus, encontramos varios rasgos comunes que revelan la cronología aproximada y los métodos generales que usaron los autores de Duqu.

Las fechas del incidente se correlacionan con la historia del descubrimiento en Irán de un virus llamado Stars. En aquel momento, los especialistas iraníes no compartieron muestras del virus descubierto con ninguna empresa antivirus y esto, debo decir, que dio lugar a todos los acontecimientos de esta saga. Lo más probable es que los iraníes hayan encontrado un módulo capturador de teclado (keylogger) que se había cargado en el sistema y contenía una foto de la galaxia NGC 6745. Esto explicaría que lo hayan llamado Stars.

Es posible que los especialistas iraníes encontraran solo el keylogger, mientras que el módulo principal de Duqu y el dropper (incluyendo los documentos que contenían la vulnerabilidad que todavía no se conocía) debieron pasar desapercibidos.

Etapa 1: Penetración, correo electrónico

El ataque se realizó en un blanco preseleccionado. No podemos revelar el nombre de la compañía atacada en el incidente N? 1 por razones obvias. El ataque se lanzó por correo electrónico, como también sucedió con el incidente que está investigando CrySys Lab.

Los criminales atacaron dos veces: el 17 y el 21 de abril de 2011
El primer intento fracasó (el correo de los atacantes acabó en la carpeta de spam), por lo que los usuarios malintencionados repitieron el ataque cuatro días después, cambiando un poco el asunto del mensaje.

El Sr. B. Jason fue muy dedicado y persistente. No fue un mensaje spam de envío masivo, ya que tanto el asunto del mensaje como el nombre del archivo mencionaban la compañía atacada de forma específica.

En ambos casos el correo se envió desde la misma dirección IP, ubicada en Seúl, Corea del Sur. Creemos que este ordenador ya estaba infectado con algún tipo de programa malicioso y se usó como un proxy sin el conocimiento de su dueño.

El segundo ataque tuvo éxito: el usuario atacado abrió el archivo .DOC adjunto que contenía el exploit para la vulnerabilidad y el instalador del troyano.

Los atacantes utilizaron un truco interesante en esta etapa. Cuando la víctima abrió el archivo, el exploit comenzó a trabajar: se volvió activo y se ubicó en la memoria, pero ¡no hizo nada! Mientras tanto, el archivo original y Word se pudieron haber cerrado.

Este periodo de inactividad duró alrededor de 10 minutos, después de los cuales el exploit esperó a que el usuario dejara de utilizar el ordenador (viendo que se detuviera la actividad del teclado y del ratón). Cuando esto sucedió, el dropper entró en acción.

La variante del dropper que encontramos nosotros es un poco diferente a la del dropper que encontró el laboratorio húngaro Crysys y Symantec describió. Estas diferencias tienen que ver principalmente con los tamaños y fechas de creación del componente en un pequeño cambio en el código.

La organización general en esta etapa era así:

Exploit -> kernel -> controlador en el kernel -> cargador dll en services.exe -> big pnf en services.exe -> big pnf instalándose desde lsass o AV process.

El shellcode del exploit estaba en un font integrado procesado por el sistema win32.sys. El font se llamaba Dexter Regular, y decía que sus creadores eran de Showtime Inc.

Esta es otra broma pesada de los autores de Duqu, ya que Showtime Inc. es la empresa de cable a cargo de la serie de televisión Dexter, que trata de un doctor de escenas del crimen que en realidad es un asesino en serie que se venga de los criminales en una especie de perversión post-mortem al estilo del personaje de Charles Bronson en la película Death Wish.

La fecha de compilación del controlador que carga el exploit en el kernel del sistema es 31 de agosto de 2007. El controlador análogo que se encontró en el dropper de CrySys estaba fechado el 21 de febrero de 2008. Si esta información es correcta, ¡los autores de Duqu deben haber estado trabajando en este proyecto por más de cuatro años!

El controlador cargó en el proceso una biblioteca services.exe, que estaba también en el cuerpo del exploit, el módulo principal del dropper, y ejecutó su código.

En esta etapa, el dropper busca la siguiente llave en el registro:
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionInternet SettingsZones4″CF1D”“CF1D”

Hay que recalcar que el documento publicado por Symantec menciona una llave CFID; pero es posible que sea una errata.

El dropper recupera de su cuerpo los contenidos de la sección “.init”, donde hay un encabezado con el identificador mágico CIGH, además de configuraciones adicionales, un PNF (.DLL) y un controlador que se instala en el sistema. Después de decodificar los contenidos de la sección, se realiza una prueba para ver si la fecha concuerda con el rango de fechas que se encuentra en el encabezamiento de la sección “.init” del dropper. Si la fecha no está dentro del rango permitido, el troyano no se instala.

En nuestra variante, este rango era desde el 17 de agosto de 2010 hasta el 18 de julio de 2012. El ejemplar del dropper que encontró CrySys tenía un rango diferente: del 17 de agosto de 2005 al 2 de noviembre de 2023.

Después, el dropper carga la parte PNF (DLL) y transfiere el control a la función exportada como N? 4. Esta función se encarga de las instalaciones en el sistema y de ejecutar el controlador del troyano y biblioteca codificada (PNF DLL), además del archivo de configuración. El archivo de configuración contiene la fecha de infección y el periodo de trabajo del troyano en el sistema (que es de 30 días por defecto, pero este periodo puede cambiar dependiendo de lo que ordene el centro de control).

En este incidente, como dijimos antes, se utilizó un conjunto de archivos único, lo que difiere de los grupos de archivos que se conocían antes. La diferencia más importante es que la fecha de creación del módulo principal del troyano (el archivo PNF DLL) era 17 de abril, el mismo día del primer ataque a la víctima. Este hecho demuestra que los autores construyen conjuntos de archivos separados para cada una de las víctimas, y lo hacen justo antes de atacar.

Los archivos que descubrimos conforman la siguiente colección:

Las diferencias de tamaño del DLL principal (se encontraron en diferentes ordenadores en un mismo incidente) se explican por el hecho de que, en la primer variante del DLL, el componente que interactuaba con el centro de control se guarda en el PNF DLL como un recurso numerado 302; en la segunda variante, este componente se incluye en la sección comprimida “.zdata” de la biblioteca de un cargador que se guarda como recurso 302. Asumimos que la compresión se llevó a cabo después de formar el conjunto para atacar a diferentes ordenadores de la red.

El servidor de control (C2) que usa este conjunto también difiere de otros que se habían descubierto antes en India y Bélgica. En este incidente, el centro de control estaba en otro país, pero no podemos publicar información más específica porque la investigación sigue en curso. Además, sabemos que existe otro centro de control se utilizó en un incidente diferente; esto también se está analizando. Esta información se publicará pronto. Esto también puede indicar que los atacantes utilizaron un C&C separado para cada ataque único.

Etapa 2: Recolectar información

Durante nuestra investigación del incidente definimos que se habían comprometido dos ordenadores en una organización. El primero fue la fuente de infección desde el 21 de abril; el segundo se comprometió más tarde, a finales de mayo. La infección del segundo ordenador ocurrió mediante la red local.

Después de la infección del sistema y de haber establecido la relación con el servidor de control, se cargó e instaló un módulo adicional conocido como keylogger, que puede recolectar información sobre el sistema, capturar imágenes de la pantalla, buscar archivos, registrar contraseñas, etc. Hasta ahora, se ha confirmado la existencia de por lo menos dos variantes de este módulo: la descubierta por CrySys Lab (fecha de compilación del 1 de junio de 2011) y la que encontró Symantec (fecha de compilación del 10 de agosto de 2011). No hemos podido encontrar un módulo similar en este incidente, pero podemos afirmar que ya existía en mayo de 2011.

Se encontraron rastros de las actividades de un módulo espía en ambos ordenadores, es decir, archivos llamados ~DFxxxxx.tmp (e.g., ~DF1EF83.tmp) y ~DQx.tmp (e.g., ~DQ2C6.tmp).

El formato del nombre del archivo ~DF[cinco dígitos hexadecimales] es diferente al de los nombres de los archivos temporales que crea MS Word, que emplea el formato ~DF[cuatro dígitos hexadecimales].

Los archivos ~DF contienen un identificador comprimido del sistema infectado y comienzan con la línea ABh91AY&SY. Los archivos ~DQ contienen la información recolectada (lista de procesos, capturas de pantalla, información sobre aplicaciones). Estos archivos también se comprimen y contienen un marcador similar; sólo se diferencia de ~DF en una letra: AEh91AY&SY .

Por el momento no sabemos qué módulo crea los archivos ~DF (el módulo espía que se descubrió crea los archivos ~DQ), o cuál es su blanco específico. En el primer ordenador, estos archivos estaban fechados el 27 de abril, tres días antes de la fecha de infección.

El 25 de mayo de 2011, el módulo espía creó el archivo ~DQ181.tmp.

Este archivo contiene información sobre el entorno de red del primer ordenador en infectarse. Al día siguiente, el 26 de mayo de 2011, se registró la infección del segundo ordenador en la red. Allí se creó el identificador de archivos ~DF.

Lo interesante de esto es el hecho de que más tarde se creó otro archivo ~DF en el segundo ordenador. Esto ocurrió el 2 de junio de 2011. Esta fecha coincide con la de compilación del conocido módulo espía (1 de junio de 2011). Es posible que en el periodo de entre el 1 y 2 de junio, los autores de Duqu hayan instalado esta nueva versión del módulo en todos los ordenadores infectados mediante el servidor C&C.

Los rastros del trabajo de este módulo se pueden ver en la existencia del archivo ~DQ4.tmp, creado el 29 de junio.

Encontramos tres archivos tipo ~DQ, creados el 25 de mayo, el 29 de junio y el 24 de agosto. Notamos que las tres fechas son miércoles. Esto podría ser sólo una coincidencia, pero también podría no serlo. Aun así, basándonos en esta “coincidencia”, podríamos bautizar al grupo de autores de Duqu como “El equipo de los miércoles” 🙂

El troyano estaba presente en la infección de los sistemas desde el 21 de abril hasta el final de octubre de 2011. Sus archivos de configuración estuvieron instalados durante por lo menos 121 días; la reinstalación del módulo principal se realizó a finales de junio de 2011.

Los atacantes instalaron nuevos módulos de forma periódica durante todo este tiempo, infectaron otros ordenadores de la red y recolectaron información.

Conclusión

Como parte de la investigación de este incidente establecimos los puntos de entrada para penetrar los sistemas, fechas de los acontecimientos y varios hechos sobre la conducta de los atacantes. Esta información nos permite fechar una de las olas de ataque entre mediados y finales de abril de 2011. Los descubrimientos clave incluyen:

• Se creó un conjunto separado de archivos de ataque para cada víctima;
• Cada conjunto de archivos único utilizaba un servidor de control separado;
• Los ataques se realizaron mediante correo electrónico con un archivo .DOC adjunto;
• El envío de correos se realizó desde cuentas anónimas, probablemente mediante ordenadores comprometidos;
• Se conoce por lo menos una dirección que envió los correos electrónicos: bjason1xxxx@xxxx.com;
• Se creó un archivo DOC separado para cada víctima;
• El exploit de la vulnerabilidad estaba dentro de un font llamado “Dexter Regular”;
• Los atacantes cambiaron el shellcode, y variaron el rango de fechas para las posibles infecciones;
• Después de ingresar en el sistema, los atacantes instalaron módulos extra e infectaron ordenadores vecinos;
• La presencia de los archivos ~DF.tmp y ~DQ.tmp en el sistema indica que sin duda había una infección de Duqu.

No podemos compartir la fuente del archivo .DOC con otras personas por razones de privacidad y para proteger la identidad de la víctima.

Tampoco podemos publicar la dirección del servidor de control de esta variante de Duqu, al menos por ahora; pero creemos que ya ha dejado de funcionar y los atacantes ya han borrado toda la información crítica que contenía. Este también es el caso de más de un servidor de control que hemos descubierto. Después se publicará más información sobre los servidores de control.

Podemos confirmar que por ahora conocemos por lo menos 12 conjuntos únicos de archivos Duqu. La variante de la que hablamos en esta entrada es la variante F. Más adelante se publicará información detallada sobre las otras variantes.