El siguiente post es una traducción y adaptación 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 reporto 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 Flamer, 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 la presente publicación, se analizarán las similitudes y conexiones de programación entre Stuxnet, Duqu, Flamer 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 empleen este enfoque orientado en objetos son Stuxnet, Duqu y Flamer. 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 Flamer 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 Flamer, 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 Flamer 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 encriptado de Gauss debido a que aún no se determina su contenido):
A pesar que Gauss comparte algunas características con Stuxnet y Flamer, existen algunas evidencias que demuestran que este malware es nuevo y no está basado en Stuxnet o Flamer. 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 Flamer. Esta información fue obtenida mediante el uso del plugin BinDiff para IDA Pro, lo que nos permite estimar qué tan similar 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 a Stuxnet que a Flamer. 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, streams, entre otros elementos. En cambio, Flamer utiliza una estructura diferente para trabajar con los elementos mencionados anteriormente. De acuerdo al análisis binario realizado, lo único que comparte Gauss con Flamer es el modo en que ambos encriptan las cadenas dentro de cada módulo binario, sin embargo, el método de desencriptado que utilizan los dos difiere. A continuación se compara los algoritmos de desencriptado de Gauss y luego Flamer.
Otras características de Gauss como las técnicas de inyección de código, el lugar de almacenamiento de la información de configuración, entre otros, difieren absolutamente. Stuxnet y Flamer 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 implementen 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 Flamer 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 HKLMSOFTWAREMicrosoftWindowsCurrentVersionReliability 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 Flamer:
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 implemente 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 Flamer. Como conclusión, se puede decir que Gauss es un código maliciosos nuevo aunque eso no significa que el autor no esté de algún modo, relacionado con los desarrolladores de Stuxnet o Flamer. 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 Flamer.
Traducido y adaptado por André Goujon.
Especialista de Awareness & Research.
