El misterio de Duqu: Parte 2

Continuamos con nuestra investigación del programa malicioso Duqu. En nuestro informe anterior señalamos dos puntos:

• hay más controladores que los que creíamos;
• es posible que haya módulos adicionales.

Aparte de esos dos puntos relevantes, llegamos a la conclusión de que a diferencia de las masivas infecciones provocadas por Stuxnet, los ataques de Duqu se concentran en un número reducido de blancos.
Pero antes de informar sobre nuestros nuevos hallazgos, me gustaría rendir tributo al laboratorio húngaro de investigaciones Crysys por el trabajo que han realizado. Fueron los primeros en analizar los componentes de Duqu y elaboraron un brillante informe al respecto, que luego se proporcionó a los desarrolladores de antivirus y se convirtió en la base de las posteriores investigaciones (por desgracia, nuestra compañía no estuvo entre las primeras que recibieron este informe, pero ahora resulta incluso más interesante averiguar todo sobre Duqu).

Nuestros expertos continúan realizando detallados análisis de todos los componentes de Duqu y están encontrando más evidencias de similitudes existentes entre Duqu y Stuxnet. Estamos elaborando un informe completo con los resultados del análisis que nuestros expertos hicieron de los archivos y sus estructuras, el cual se publicará más adelante. Esta parte de nuestra investigación no es ni la más importante ni la más urgente. Para nosotros es mucho más importante comprender las razones y secuencia de los hechos, y es lo que vamos a discutir aquí.

Incidentes reales

En nuestra entrada anterior, mencionamos que en las 24 horas previas habíamos encontrado un solo incidente real después de haber añadido la detección de todos los componentes conocidos de Duqu a nuestra base de datos antivirus. Desde aquel incidente, hemos descubierto otros más, lo que nos permite llegar a algunas conclusiones sobre el vector del ataque en sí.
Debemos mencionar que no podemos confirmar ni negar ninguna información de otros fabricantes antivirus sobre incidentes conocidos en el Reino Unido, Estados Unidos, y quizás Austria e Indonesia. Tampoco hacemos ningún comentario sobre los incidentes en Hungría. Nos limitamos a concentrarnos en los casos que hemos descubierto gracias a la ayuda de Kaspersky Security Network.

Incidente 1: Sudán

Uno de los primeros casos reales de infección tuvo lugar en una región muy específica, como ya hemos confirmado. Sucedió en Sudán.

En este caso, encontramos un controlador completamente nuevo y totalmente distinto a las anteriores variantes, tanto en nombre como en MD5.

En base a nuestro descubrimiento de que el principal módulo de Duqu consta de tres componentes (controlador, biblioteca DLL y archivo de configuración), podemos especular que el paquete está compuesto por otros dos archivos. Pero no hemos observado ninguna detección en nuestra base de clientes con nuestra actual configuración de detección. Esto significa que estos archivos son diferentes a los ejemplos conocidos (netp191/192.pnf, cmi4432/cmi4464.pnf).

Por desgracia, no hemos logrado contactar con el usuario infectado para realizar una investigación más a fondo sobre este incidente. Tampoco tenemos una copia del controlador adp55xx.sys. Hasta ahora sólo conocemos su nombre, tamaño y la suma de control.

Incidente 2: Irán

Hasta este momento, el mayor número de incidentes relacionados con Duqu tuvieron lugar en Irán. Esto nos trae de vuelta a la historia de Stuxnet y plantea varios puntos. Pero primero, veamos algunos detalles.

Vemos la misma situación: un nuevo y único archivo (iraid18.sys), un tamaño de archivo ya conocido (24.960 bytes) y una nueva suma de control. Pero aparte de estas tres características estáticas del archivo, existen otras diferencias. No sólo hemos encontrado un nuevo controlador, sino también un nuevo archivo de configuración ird182.pnf. Sin duda alguna, es similar a los archivos conocidos (mismo tamaño: 6.570 bytes), pero es diferente en el contenido, ya que este archivo debe ser único. Guarda información sobre la fecha de la infección para controlar posteriores procesos de desinstalación.

Hay otro controlador que resulta incluso más interesante, aunque no hemos logrado restaurar su nombre original. Y, a pesar de que tiene el mismo tamaño que los anteriores controladores de Duqu, también es diferente a iraid18.sys, que se encontró también en el lugar de la infección. Es diferente a todos los controladores conocidos.

Hasta este momento, podemos ver un juego casi completo de módulos con nombres parecidos: iraid18.sys + ird182.pnf + principal biblioteca DLL desconocida (que sospechamos se llama ird181.pnf).

Incidente 3: Irán

Este incidente es uno de los más interesantes. Se trata de una infección de 2 sistemas conectados entre sí. Además de que estos sistemas son parte de una red, también se infectaron con el mismo controlador (nuevo, otra vez): igdkmd16b.sys. Hemos logrado obtener una copia de este archivo:

Hay que hacer notar que antes de este incidente, nunca habíamos visto un archivo con un tamaño de 25.088 bytes; sólo habíamos visto controladores con un tamaño de 24.960 bytes (sin firma digital) o de 29.568 bytes (con firma digital).

Además, hemos encontrado otros dos archivos en uno de los sistemas (por desgracia no hemos logrado obtener una copia de estos archivos). El primero es un archivo de configuración con el nombre netq795.pnf, y el segundo es un controlador desconocido del mismo tamaño de 25.088 bytes, pero con una suma de control diferente.

Como sucedió en el incidente 2, aquí también tenemos un nuevo juego casi completo de módulos: igdkmd16b.sys + netq795.pnf + principal biblioteca DLL desconocida (que sospechamos se llama netq794.pnf).

Incidente 4: Irán

Como ha sucedido en todos los incidentes descritos arriba, existe un controlador único diferente a los anteriores tanto en nombre (bpmgs.sys) como en tamaño (24.832 bytes). Por desgracia, no hemos logrado obtener una copia del archivo y su contenido sigue siendo un misterio. Podemos decir lo mismo del correspondiente archivo de configuración.

Al mismo tiempo, hemos dado con un hecho que quizás no esté relacionado con este caso de Duqu.
Pero, este equipo sufrió repetidos ataques de red hace no mucho: el 4 y el 16 de octubre. Ambos ataques usaron un exploit dirigido a la vulnerabilidad MS08-067 (también usado por Kido y Stuxnet).
La dirección IP del atacante es 63.87.255.149(en ambos casos). Pertenece a ‘MCI Communications Services Inc.’, una subdivisión de ‘Verizon Business’.

Entonces, imaginaos la situación. Dos ataques en 12 días desde una sola dirección IP. ¿Cuál es la probabilidad de que Kido haya realizado este ataque de forma automática? Es posible si se tratase de un solo ataque. Es imposible en el caso de dos ataques. Entonces, podríamos sugerir que estos ataques no fueron por accidente, sino adrede. Es posible que el atacante no sólo haya usado el exploit MS08-067, sino también otros que no llegaron a rastrearse.

Hechos y conclusiones

1. Hemos registrado incidentes sólo en Sudán e Irán.
2. No contamos con información sobre la relación de las víctimas con el programa nuclear de Irán, CAs o industrias.
3. Es obvio que cada incidente de Duqu es único, con sus propios y únicos archivos con diferentes nombres y sumas de control.
4. Duqu se usa contra objetivos específicos cuidadosamente seleccionados. Aquí estaba el término APT pero lo taché porque no me gusta.
5. Sabemos que existen al menos 13 archivos diferentes (y sólo hemos obtenido seis).
6. No hemos detectado el uso de ningún módulo “keylogger”. Es posible que nunca se haya usado en esta serie de incidentes en particular o que se lo haya codificado o eliminado de los sistemas.
7. El análisis del controlador igdkmd16b.sys reveló que existe una nueva llave de codificación, lo que evidencia la inutilidad de los actuales métodos de detección de los archivos PNF conocidos (principal componente de la DLL principal). Es obvio que para cada ataque la DLL se codifica de forma diferente.
8. Los actuales métodos de detección de la mayoría de los fabricantes antivirus son capaces de detectar los controladores de Duqu. Pero la probabilidad de fallar en la detección del principal componente de DLL (PNF) es de casi el 100%.
9. Duqu es un marco multifuncional capaz de funcionar con cualquier número de cualquier tipo de módulos. Duqu es altamente ajustable y universal.
10. La biblioteca principal (PNF) es capaz (export 5) de reconfigurar y reinstalar el paquete por completo. Puede, entre otras cosas, instalar controladores y crear componentes adicionales, y registrar todo. Esto significa que si existe una conexión a servidores activos de comando y control, se puede cambiar por completo la infraestructura de Duqu en un determinado sistema.
    Los autores de Duqu pudieron instalar módulos actualizados en los sistemas infectados justo antes de la publicación de la información sobre este programa malicioso, porque seguimos descubriendo nuevos controladores de Duqu creados el 17 de octubre. No descartamos el hecho de que también hayan logrado cambiar el servidor de comando y control.

11. Tampoco descartamos que el servidor de comando y control en India se haya usado sólo en el primer incidente conocido (ver informe original de Crysys Lab), y que haya servidores de comando y control únicos para cada objetivo, incluyendo los que hemos detectado.
12. Los informes que señalan que Duqu funciona en sistemas infectados sólo durante 36 días, no son completamente correctos. Incluso este aspecto es ajustable: sólo jminet7.sys/netp191.pnf usa un contador de 36 días. El conjunto de módulos cmi4432.sys/cmi4432.pnf se autoelimina después de 30 días.