¿Existe una interconexión entre Gauss y otros malware como Stuxnet, Duqu o Flame?

El siguiente post es una traducción y adaptación realizada por nuestros compañeros de ESET Latinoamérica de la publicación Interconnection of Gauss with Stuxnet, Duqu & Flame escrita por nuestro investigador y colega de ESET, Eugene Rodionov.

La semana pasada se informó de la aparición de Gauss, un nuevo y complejo código malicioso que atrajo la atención de los medios debido a su vínculo con Stuxnet y Flame, además de la propagación geográfica que ha logrado. Los países más afectados en orden decreciente son El Líbano, Israel y Palestina. En este artículo, se analizarán las similitudes y conexiones de programación entre Stuxnet, Duqu, Flame y Gauss. Lo primero que uno puede observar cuando analiza Gauss es la abundancia de estructuras orientadas a objetos que dificultan el estudio de este malware y sus funcionalidades. Los ejemplos más claros de amenazas que emplean este enfoque orientado en objetos son Stuxnet, Duqu y Flame. Debido a la compleja lógica tras estos códigos maliciosos, utilizar una programación orientada a objetos parece una forma razonable de implementar las funcionalidades que incorporan. Stuxnet, Duqu y Flame utilizan marcos de trabajo específicos que se detallan a continuación:

Si se compara la complejidad de la implementación de Gauss con por ejemplo Flame, se puede observar  que el primero es más sencillo que el segundo. Incluso si se considera el tamaño del módulo principal de Gauss (wmiqry32.dll), se puede establecer que aproximadamente el 30% de su tamaño y código están destinados a rutinas de librerías estándar, como se puede apreciar en la siguiente imagen:

Con Flame este número es considerablemente menor. Si ordenamos estos códigos maliciosos de acuerdo a su complejidad en forma creciente, obtenemos el siguiente esquema (no se considera el payload cifrado de Gauss, debido a que aún no se determina su contenido):

A pesar de que Gauss comparte algunas características con Stuxnet y Flame, existen algunas evidencias que demuestran que este malware es nuevo y no está basado en Stuxnet o Flame. Esta conjetura se basa en el análisis binario realizado a los módulos que componen a Gauss, y a lo largo de este post se explicarán más argumentos que respaldan esta hipótesis. En las tablas uno y dos se puede observar una comparación de varios módulos de Gauss con respecto a otros de Stuxnet y Flame. Esta información fue obtenida mediante el uso del plugin BinDiff para IDA Pro, lo que nos permite estimar qué tan similares son estos módulos con respecto a otros.

Tabla 1

Tabla 2

De la información obtenida de las tablas anteriores se puede concluir que Gauss parece estar más relacionado con Stuxnet que con Flame. Estos datos también fueron corroborados a través de un análisis manual de los códigos maliciosos. Por ejemplo, se encontró que Gauss y Stuxnet utilizan la misma cadena de manejo de objetos, búfer de memoria y streams, entre otros elementos. En cambio, Flame utiliza una estructura diferente para trabajar con los elementos mencionados anteriormente. De acuerdo al análisis binario realizado, lo único que comparte Gauss con Flame es el modo en que ambos cifran las cadenas dentro de cada módulo binario; sin embargo, el método de descifrado que utilizan los dos difiere. A continuación se comparan los algoritmos de descifrado de Gauss y luego de Flame.

Otras características de Gauss, como las técnicas de inyección de código o el lugar de almacenamiento de la información de configuración, entre otros, difieren absolutamente. Stuxnet y Flame utilizan un mecanismo de inyección bastante complejo que les permite eludir programas de seguridad creando la ilusión de un módulo cargado legalmente que es capaz de engañar software que implemente algún HIPS. En cambio, Gauss emplea una técnica de inyección más sencilla y directa asignando un búfer de memoria en el espacio de dirección de un proceso específico, para luego copiar la ruta de acceso hacia el módulo y así producir la inyección. La siguiente imagen muestra el método de inyección de código utilizado por Gauss:

Después crea un hilo remoto a través del llamado de la API CreateRemoteThread que ejecuta solo la rutina LoadLibtatyW, como se muestra en la siguiente imagen:

Otro factor diferenciador es que Flame implementa un complejo sistema para almacenar información de configuración. En el caso de Gauss esto es distinto, ya que este tipo de datos son almacenados en el valor de registro TimeStampForUI en la clave HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Reliability en forma de información binaria, lo que lo convierte en algo fácilmente parseable.

A continuación se muestra el marco de trabajo de Flame:

No se encontró este tipo de arquitectura en ninguno de los módulos de Gauss que se han analizado. El único módulo que contiene un trozo de código que implementa estos objetos de forma similar, lo hace rudimentariamente, y es winshell.ocx. Sin embargo, nuevamente no existe implementación de un marco de trabajo comparable al de Flame. Como conclusión, se puede decir que Gauss es un código malicioso nuevo, aunque eso no significa que el autor no esté, de algún modo, relacionado con los desarrolladores de Stuxnet o Flame. Gauss posee algunas características similares a estos, pero no son suficientes como para poder afirmar que su desarrollo se basó en el marco de trabajo de Stuxnet o Flame.

Josep Albors

@JosepAlbors