Stuxnet/Duqu:parte VII (Volviendo a Stuxnet)

Por dos meses hemos estado estudiando el troyano Duqu, explorando cómo surgió, dónde se distribuyó y cómo funciona. A pesar del considerable volumen de datos que hemos obtenido (la mayor parte aún no se ha publicado), todavía nos queda responder a la pregunta fundamental: ¿Quién está detrás de Duqu?

Además, hay otros temas, sobre todo relacionados con la creación del troyano o con la plataforma que se usó para implementar Duqu y Stuxnet.

En términos de arquitectura, la plataforma que se usó para crear Duqu y Stuxnet es la misma. Se trata de un archivo controlador que carga un módulo principal diseñado como una biblioteca codificada. Al mismo tiempo, existe un archivo de configuración independiente para todo el complejo malicioso y un bloque codificado en el mismo registro que define la ubicación del módulo que se carga y el nombre del proceso para la inyección.

Arquitectura de la plataforma convencional para Stuxnet y Duqu

Esta plataforma suele llamarse “Tilded” ya que sus autores parecen inclinados, por alguna razón, a usar nombres de archivos que empiecen con “~d”.

Creemos que Duqu y Stuxnet eran proyectos simultáneos realizados por el mismo equipo de desarrolladores.

Se han descubierto varios detalles más que sugieren la posibilidad de que hubo por lo menos otro módulo spyware basado en la misma plataforma en 2007-2008, y varios programas cuya funcionalidad no estaba clara entre 2008 y 2010.

Estos hechos desafían de manera significativa la existencia de una historia “oficial” de Stuxnet. Trataremos de explicarlos en este artículo, pero primero recapitulemos la historia hasta este punto.

La historia “oficial” de Stuxnet

Empecemos con una interrogante:¿cuántos archivos controladores de Stuxnet se conocen? Hasta la fecha, la respuesta correcta sería cuatro. Veamos a continuación más información sobre ellos.

La primera modificación del gusano Stxnet, creado en 2009, usaba un solo archivo controlador (mrxcls.sys) sin firma digital.

En 2010, los autores crearon el segundo controlador, mrxnet.sys, (para esconder los archivos componentes del gusano en unidades USB) y equiparon los controladores mrxnet.sys y mrxcls.sys con certificados digitales de Realtek. El controlador mrxnet.sys no tiene mayor importancia en nuestra historia, ya que se trata de un módulo separado no incorporado en la arquitectura general de la plataforma.

El 17 de julio de 2010, ESET detectó otro controlador en Internet (jmidebs.sys) que era muy similar al ya conocido mrxcls.sys, pero que había sido creado apenas tres días antes de su descubrimiento. Este controlador venía respaldado con un nuevo certificado, esta vez de Jmicron.

Hasta hace poco no quedaba claro cuál era el propósito de este archivo, pero la opinión general era que estaba vinculado con Stuxnet. Una teoría sostiene que el centro de comando y control de Stuxnet estaba intentando reemplazar la versión antigua con el certificado de Realtek por una nueva. En el intento, los diseñadores del gusano esperaban evitar que los programas antivirus lo detecten o reemplazar un certificado que estaba bloqueado.

Por desgracia, esta teoría no ha sido confirmada; Jmidebs.sys nunca ha sido detectado en ninguna parte. Tampoco se ha detectado ninguna nueva versión de Stuxnet que sea capaz de instalar el archivo.

Esta es la historia oficial de Stuxnet. Sin embargo, como mencionamos más arriba, en el transcurso de nuestra investigación hemos descubierto nueva evidencia que trataremos a continuación.

Controladores previamente desconocidos

rtniczw.sys

Mientras analizábamos el incidente de un usuario relacionado con Duqu, descubrimos algo nuevo, algo que podría afectar toda la historia conocida de Stuxnet.

En el ordenador de la víctima se descubrió un extraño archivo que nuestro antivirus detectó como Rootkit.Win32.Stuxnet.a. Se supone que este veredicto correspondía al archivo conocido mrxcls.sys descrito más arriba, ¡pero el nombre del archivo detectado y la suma de verificación eran diferentes¡

El archivo era rtniczw.sys, de 26.872 bytes, MD5 546C4BBEBF02A1604EB2CAAAD4974DE0.

Este archivo era un poco más grande que mrxcls.sys que tenía una firma digital de Realtek. Esto significaba que rtniczw.sys también tenía una firma digital. Logramos obtener una copia del archivo y quedamos sorprendidos al descubrir que usaba el mismo certificado de Realtek, pero la fecha de firma del archivo mrxcls.sys era diferente: rtniczw.sys se firmó el 18 de marzo de 2010, mientras que mrxcls.sys se había firmado el 25 de enero del mismo año.

Además, rtniczw.sys usaba una llave de registro y un bloque de fecha de configuración que Stuxnet no utilizaba. Stuxnet utilizaba la llave “MRxCls” y el valor “Data”, mientras que en el caso de rtniczw.sys, la llave era “rtniczw” y el valor era “Config”.

Un detallado análisis del código detectado en rtniczw.sys no revelaba otras diferencias respecto al controlador de “referencia”. Se trataba del mismo archivo mrxcls.sys, creado el mismo año, el mismo día y a la misma hora: 1 de enero de 2009.

Buscamos información adicional sobre otros usuarios que tuvieran el mismo archivo, pero no logramos encontrar nada. Además, no pudimos encontrar ninguna información sobre el nombre del archivo (rtniczw.sys) o su MD5 en ningún motor de búsqueda. El archivo se había identificado una sola vez: se lo había enviado para su análisis a Virus Total desde China en mayo de 2011.

Al parecer, el sistema que estábamos estudiando se había infectado a fines de agosto de 2011. Hay que remarcar que no detectamos ninguna infección de Stuxnet en el sistema: no se encontró ningún archivo adicional del paquete Stuxnet. Sin embargo, sí encontramos archivos de Duqu.

Llegamos a la conclusión de que podrían existir otros archivos controladores similares al archivo de “referencia” mrxcls.sys que no estaban entre las variantes conocidas de Stuxnet.

rndismpc.sys

Una verificación en nuestra colección de programas maliciosos nos ayudó a identificar otro interesante archivo que estaba incluido en la colección hace más de un año. El archivo se llama rndismpc.sys, con 19.968 bytes, MD5 9AEC6E10C5EE9C05BED93221544C783E.

Este archivo resultó ser otro controlador, con una funcionalidad casi idéntica a la de mrxcls.sys excepto por:

1. rndismpc.sys usa una llave de registro distinta a las de mrxcls y rtniczw – la llave “rndismpc” con el valor “Action”;
2. usa una llave codificadora distinta a la de mrxcls/rtniczw – 0x89CF98B1;
3. la fecha de compilación del archivo es el 20 de enero de 2008, es decir, un año antes de la creación de mrxcls/rtniczw.

Al igual que rtniczw.sys, el archivo rndismpc.sys nunca se había detectado en los equipos de los usuarios. Desconocemos qué programa malicioso instalaba o con qué módulo principal se suponía que funcionaba.

El vínculo de unión: mrxcls.sys —> jmidebs.sys —>Duqu drivers

Los datos obtenidos y la información disponible sobre los controladores que usaba Duqu (ver el Misterio de Duqu, Partes I y II ) pueden resumirse en la siguiente tabla:

*Los controladores conocidos de Duqu tienen nombres de archivo únicos para cada una de las variantes. Sin embargo, su funcionalidad es idéntica.

Según nuestros análisis, jmidebs.sys es el vínculo conector entre mrxcls.sys y los controladores más recientes de Duqu.

El código de los controladores mrxcls y jmidebs es muy similar. Algunas pequeñas diferencias pueden deberse a distintas configuraciones y a cambios mínimos en el código fuente, pero el código permanece inalterado.

Sin embargo, pueden encontrarse cambios más significativos en varias funciones:

1. La función servicio que obtiene direcciones de funciones API: La versión en mrxcls usa la función MmGetSystemRoutineAddress para este propósito y los respectivos nombres de texto de las direcciones de funciones API entrantes. La versión en jmidebs llama sus propias funciones para obtener direcciones API usando hash-sums con sus nombres. Las mismas funciones se usan en los controladores de Duqu, pero la lista de funciones de hashes es el doble de extensa.
2. La función que crea stubs para inyectar PNF DLL en procesos: La versión mrxcls usa un stub de 6.332 bytes de tamaño total. Los controladores de jmidebs y Duqu usan stubs con un tamaño total de 7.061 bytes. El código que se usa en los módulos stub para estos controladores es idéntico, pero tiene fechas de compilación diferentes.

Evolución del controlador

Hemos esquematizado los vínculos entre los controladores conocidos cuya evolución y etapas claves de desarrollo son fáciles de rastrear.

Evolución del controlador de 2008 a 2011

rndismpc.sys, rtniczw.sys y jmidebs.sys

Como puede verse en el diagrama, no se sabe qué programa malicioso interactuó con los siguientes tres controladores: rndismpc.sys, rtniczw.sys y jmidebs.sys. La pregunta obvia sería: ¿se usaron en Stuxnet? En nuestra opinión, la respuesta tendría que ser ‘no’.

En primer lugar, si se hubiesen usado en Stuxnet, habrían dejado rastros más grandes que los de los casos individuales que hemos detectado. En segundo lugar, no ha habido una sola variante de Stuxnet que sea capaz de interactuar con estos controladores.

El archivo rtniczw.sys se firmó el 18 de marzo de 2010, pero el 14 de abril de 2010, los autores de Stuxnet crearon una nueva variante del gusano que usaba la “referencia” mrxcls.sys. Es obvio que rtniczw.sys estaba diseñado para otro uso. Lo mismo puede decirse de jmidebs.sys. Creemos que estos tres controladores están sólo indirectamente relacionados con Stuxnet y pueden borrarse sin riesgo alguno de la historia de Stuxnet.

Entonces surge otra interrogante: ¿podrían estos controladores haber sido usados con Duqu?

No hay una respuesta clara. Aunque algunas variantes de Duqu datan del periodo de noviembre de 2010 a octubre de 2011, creemos que se trataba de versiones tempranas del troyano espía creadas para robar información. Los tres controladores en cuestión podrían fácilmente haber sido usados en versiones tempranas de Duqu o con otros troyanos basados en la misma plataforma de Stuxnet/Duqu. Al igual que Duqu, estos troyanos probablemente se usaron en ataques dirigidos antes de la aparición de Stuxnet (que data de, por los menos, 2008), mientras estaba activo y después de que se clausurara su centro de control y comando. Es posible que hayan sido proyectos paralelos, y Stuxnet se basó luego en esa experiencia acumulada y en el código que ya estaba escrito. Parece muy poco probable que este hubiera sido el único proyecto en el que participaron sus autores.

El proceso de creación del controlador

Tratemos de imaginar cómo es el proceso de creación del controlador. Varias veces al año los autores compilan una nueva versión de un archivo controlador, creando un archivo de referencia. El propósito fundamental de este archivo es cargar y ejecutar un módulo principal, que se crea de forma separada. Podría ser Stuxnet, o Duqu o algún otro.

Cuando es necesario utilizar un controlador para un nuevo módulo, los autores usan un programa dedicado para modificar la información en el archivo de “referencia” de los controladores, por ejemplo, su nombre e información de servicio, así como la llave de registro y su valor.

Es importante remarcar que retocan archivos ya hechos y no crean otro desde cero. Esto significa que pueden hacer tantos diferentes archivos controladores como deseen, cada uno con exactamente la misma funcionalidad y fecha de creación.

Según el objetivo del ataque y de la víctima del troyano, se pueden firmar diferentes archivos de controladores con certificados digitales legítimos cuyos orígenes siguen siendo desconocidos.

Conclusión

Según los datos con los que contamos, podemos afirmar con cierta seguridad que la plataforma “Tilded” se creo a fines de 2007 o principios de 2008 antes de someterse a significativos cambios en el verano/otoño de 2010. Estos cambios se debieron a avances en el código y la necesidad de evitar la detección de las soluciones antivirus. Hubo una serie de proyectos relacionados con programas basados en la plataforma “Tilded” durante el periodo 2007-2011. Stuxnet y Duqu son dos de ellos; podría haber otros que por ahora permanecen desconocidos. La plataforma continúa desarrollándose, lo que sólo puede significar una cosa: que posiblemente veremos más modificaciones en el futuro.