Análisis de troyano Qhost con datos encirptados (por Laboratorio de Investigación de ESET en la ORT)

A lo largo del 2012 conformamos el primer Laboratorio de Investigación externo de ESET Latinoamérica en el Instituto de Tecnología ORT. El mismo tenía como fin capacitar a los alumnos en técnicas de análisis y seguimiento de amenazas para luego realizar un proyecto de investigación con malware vigente. Fue así como los miembros del equipo comenzaron a investigar sobre amenazas de tipo Qhost que afectaban a Latinoamérica. Finalmente, Agustin Ivan Scolieri y David E. Cortelezzi realizaron un informe sobre un troyano detectado por ESET NOD32 Antivirus como MSIL/Qhost.Banker.U trojan. El informe demuestra cómo los alumnos fueron capaces de comprender el completo funcionamiento de la amenaza analizada e incluso utilizar su ingenio para desarrollar una herramienta que les facilitara el análisis estático de la misma. A continuación el informe armado por los alumnos:

INTRODUCCIÓN

El motivo del análisis es el de interpretar las acciones sobre el sistema que el software malicioso provoca. Para ello se usaron distintas técnicas de análisis dinámico y estático.

RESUMEN

El software malicioso analizado actúa como un servicio en segundo plano que descarga modificaciones hacia el archivo hosts del sistema para, de esta manera, facilitar el phishing de distintos sitios bancarios y poder robar información sobre nombre de usuarios y contraseñas. La amenaza viene disfrazada con el nombre de un generador de claves, con el símbolo de una importante compañía de telefonía celular. Al ejecutarse queda como un servicio en segundo plano que cada cierto tiempo baja información para modificar el archivo hosts del sistema.

El archivo se ejecutó en un entorno virtualizado con Windows XP. No obstante, el análisis de la muestra nos llevó a la conclusión que también está preparado para entornos Vista o Windows 7, ya que se encontraron referencias a acciones sobre claves de registro del UAC y Windows Defender. En base a lo que se pudo observar, la muestra parece estar inactiva ya que una vez se pudieron identificar las direcciones de donde sacaba la información para modificar el archivo hosts, al explorar esas direcciones no se encontró información relevante.

ANÁLISIS

En primer lugar, se procedió a hacer un análisis dinámico con herramientas para rastrar tráfico de red y ver acciones sobre el registro; debido a que el entorno de prueba no estaba conectado a Internet no se pudo encontrar mucha información con este método, la muestra no realizaba mayores modificaciones al sistema.

Posteriormente, investigando la muestra, se descubrió que fue programada usando la tecnología .Net de Microsoft. Los programas hechos con este tipo de lenguaje se pueden desensamblar fácilmente pudiéndose ver el código fuente del programa de una manera legible como puede ser C# o VB.Net, en vez de verlo directamente en leguaje assembler. Esto nos permitió entender con mayor precisión lo que la muestra hacía usando técnicas de análisis estático.

Analizando el código en cuestión descubrimos que el desarrollador en vez de declarar las variables que contienen direcciones web y claves de registro con los valores correspondientes directamente prefirió declararlas encriptadas, dificultando el análisis de la amenaza.

Strings codificadas

Investigando un poco más el código de la muestra, pudimos encontrar la forma exacta que usa para desencriptar los valores en tiempo de ejecución.

Función encriptar

Esto nos llevó a descubrir que el desarrollador cifró las direcciones URL y demás información con TripleDes, usando como clave el resultado MD5 de una cadena de strings con el contenido: ABCDEFGHIJKLMÑOPQRSTUVWXYZabcdefghijklmnñopqrstuvwxyz y después al resultado de toda esa operación le aplicaba Base64. Es por ello que procedimos a simular dicho algoritmo, y desarrollamos un programa a medida para poder desencriptar toda esa información, llamado “Bad guy decripter”:

Bad Guy Decripter

A continuación se pueden observar los resultados luego de desencriptar cada una de las cadenas de strings que el desarollador utilizó:

Strings decodificadas

Por otra parte revisando la lógica principal del programa y la manera en la que fue hecha llegamos a la hipótesis que el desarrollador quería complicar de la mejor manera posible el análisis estático de la muestra. Adicionalmente, analizando el código y tipo de caracteres que este utilizó, pudimos deducir que es probable que el desarrollador malicioso sea de habla española, posiblemente latinoamericano (aunque también podría ser de España).

Código ofuscado

Lo que se puede deducir de la imagen anterior es que se implementó un ciclo iterativo utilizando los “ticks” de un control timer de .NET y dependiendo del estado de la iteración se iban ejecutando distintas porciones del código.

CONCLUSIÓN

Aunque la muestra en este momento ya parece ser inofensiva, por el hecho que los sitios que utilizaba para descargar información ya no contienen más información relevante, la investigación nos permitió entender cómo algunos desarrolladores maliciosos intentan complicar de cierta manera el código para hacer el análisis de los investigadores más difícil.

Agustin Ivan Scolieri, Alumno de la ORT.
David E. Cortelezzi, Alumno de la ORT.

Material realizado con la colaboración y revisión de Joaquín Rodriguez Varela, Coordinador de Laboratorio de ESET Lationamérica.

Autor , ESET

Síguenos