El siguiente post es una traducción y adaptación de la publicación Win32/Gataka banking Trojan – Detailed analysis escrita por nuestro investigador y colega de ESET, Jean-Ian Boutin. Asimismo, la amenaza analizada aquí es detectada por los productos de ESET como Win32/Gataka.B.

Gataka es un troyano bancario diseñado para robar información y alterar todo el tráfico web que se genera en una computadora infectada. De este modo, la amenaza es capaz de modificar el balance o estado de cuenta de la víctima para ocultar transacciones fraudulentas. La arquitectura de funcionamiento de este código malicioso es modular y parecida a la de SpyEye, en donde la mayoría de las funcionalidades son implementadas y llevadas a cabo a través de plugins. En nuestra publicación anterior Win32/Gataka: ¿Troyano bancario listo para despegar? Explicamos algunos aspectos y características tipo botnet que presenta esta amenaza, además de incluir casos recientes de campaña de propagación de esta. En esta segunda entrega, se analizará en profundidad dos componentes de Gataka: la inyección de código web (Webinject) y el plugin Interceptor. A continuación se muestra la arquitectura que caracteriza a Win32/Gataka. Para saber qué hace cada plugin, por favor consultar la publicación anterior.

Estructura de plugins de Gataka

Plugin Interceptor

Este plugin crea un servidor proxy local en la computadora infectada con el fin de poder examinar todo el tráfico de red entrante y saliente. En el caso de tráfico HTTPS, se intercambian entre el cliente y el servidor proxy, certificados falsos que se encuentran embebidos dentro de los recursos del plugin. La funcionalidad que implementan los navegadores para comprobar la validez de un certificado también es alterada por este código malicioso con el fin que el usuario no observe que se está utilizando un certificado falso. Este plugin debe ser utilizado en conjunto con otros para permitir que un botmaster robe información personal de la víctima. Por ejemplo, el plugin Webinject determina filtros específicos a través del plugin NextGenFixer, esto permite una inyección de código que posibilita que sitios específicos sean modificados con fines maliciosos. En la siguiente imagen se muestra el funcionamiento del módulo Interceptor.

Funcionamiento del plugin Interceptor- En cuanto se ejecuta un navegador, el malware comienza a inyectar rutinas maliciosas dentro de este, parchea la funcionalidad de comprobación de certificados, y utiliza un hook a las API de conexión para poder interceptar las comunicaciones web.

- En este ejemplo, el usuario intenta conectarse a un sitio de un banco que aparece especificado en el archivo de configuración de Webinject que descarga el troyano de Internet. Cuando el navegador intente conectarse al servidor del banco utilizando las API de conexión, la llamada será interceptada por Gataka y el hook que realizó anteriormente. El mecanismo de hook de API empleado es bastante estándar: inserta en el principio de la llamada un salto hacia el código del malware con el objetivo de redireccionar todas las llamadas hacia esa API. Los primeros bytes parcheados de la función son almacenados en un búfer separado para poder llamar a la API original cuando sea necesario.

- A partir de este momento Gataka se conecta al servidor del banco utilizado los datos suministrados por el usuario, actuando de proxy entre ambos.

- El banco se comunica de vuelta con el troyano.

- El malware le transmite la información al usuario. Es en este punto en donde es posible engañar a la víctima porque el código malicioso utiliza certificados falsos para comunicarse con el navegador. Como la función de comprobación de certificado es parcheada, el browser cree que la transacción es una sesión legítima de SSL/TLS. Los certificados falsos se encuentran embebidos dentro de los recursos del plugin Interceptor:

Ambos certificados son falsosAmbos certificados son inválidos: el de la izquierda expiró y el de la derecha no fue emitido por una entidad certificado de confianza (CA). Los siguientes navegadores y sus rutinas de comprobación de certificados son parcheadas por Gataka:

  • Firefox
  • Internet Explorer
  • Netscape Navigator
  • Opera
  • Maxthon

Existen algunos strings que hacen referencia a Chrome, sin embargo, este navegador no es soportado aún. Es curioso que un navegador menos común como Maxthon sea soportado y no Chrome. Sin embargo, esto se explica porque la rutina de parcheado utilizada para Internet Explorer es la misma que para Maxthon. Por otro lado, Firefox es afectado en todas sus versiones incluyendo la reciente 14.0.1. Esta fue lanzada el 17 de julio de 2012 y el módulo Interceptor fue compilado apenas dos días después para soportar esta última versión. Esto demuestra que Gataka está siendo activamente desarrollado.

Si miramos en profundidad la rutina de parcheado que utiliza esta amenaza para modificar la comprobación de certificados de Internet Explorer, encontramos que la rutina responsable de verificar si un certificado es válido o no es WinVerifyTrust() en wintrust.dll. De acuerdo a documentación de MSDN, si el proveedor de confianza verifica que el tema es de confianza para la acción especificada, el valor de retorno es cero. Por lo tanto, para poder alterar esta función, el plugin Interceptor busca la dirección de partida de la función y parchea los últimos bytes para que siempre devuelva cero.

- Una vez que el malware ha realizado todas estas etapas, puede interceptar todas las comunicaciones entre el usuario y su banco sin importar si este utiliza SSL/TLS. El descifrado del tráfico SSL/TLS es posible debido a los certificados falsos. Si la dirección URL del banco es especificada en el archivo de configuración de Webinject, este plugin registra una llamada de vuelta con Interceptor para poder inyectar y modificar contenido en la página que el usuario está visualizando. Esta modificación puede incluir nuevos campos en donde el usuario debe suministrar más información personal. Todo esto es efectuado a través de scripts capaces de modificar el balance de una cuenta para ocultar transacciones fraudulentas.

Plugin Webinject

Como pudo verse en la publicación anterior sobre Gataka, los ataques en contra de las instituciones financieras son realizados mediante la inyección HTTP. Esas inyecciones son configurables y enviadas al cliente empleando un formato predefinido. Para cada URL, es posible especificar en qué parte del código HTML del sitio se debe realizar la inyección, de este modo, es posible afectar a muchas entidades financieras. El plugin Webinject es el responsable de descargar el archivo de configuración e inyectar códigos en las páginas atacadas. Algo interesante de destacar es que el formato del archivo de configuración de Gataka es muy similar al utilizado en SpyEye y Zeus. La siguiente captura compara el formato de Gataka y SpyEye:

Comparación entre ambos archivos de configuración

Los tags utilizados para determinar dónde debe el script ser insertado son idénticos en Gataka y SpyEye. La única diferencia se ve en el uso de end_url por parte de Gataka. Esto permite que los ciberdelincuentes migren fácilmente de un código malicioso a otro, o que utilizando un mismo archivo de configuración, puedan operar botnets creadas con distintos malware.

Los archivos de configuración utilizados para inyectar contenido malicioso en determinados sitios son almacenados en una base de datos interna, la que es encriptada utilizando 3DES y se encuentra en la siguiente ruta:

Ruta de la base de datos

Para hacer las cosas más intrigantes, la contraseña para desencriptar la base de datos se encuentra en el mismo archivo y aparece como cfvsq ckj;ysq GfhjKm. Si eso es escrito utilizando la distribución de teclado cirílica, se obtiene самый сложный ПароЛь, lo que significa “la contraseña más compleja”.  Una vez que el archivo ha sido desencriptado, se observa que posee una estructura XML y esquema de codificación Base64.

Archivo desencriptado

El archivo de configuración es comprimido y mantenido entre <injdata>. Durante la inicialización del plugin Webinject, el archivo de la base de datos es leído y los filtros insertados donde corresponde para permitir inyecciones exitosas.

Ejemplo de campaña

Una de las campañas que seguimos estaba utilizando un tipo de inyección que enviaba automáticamente la información tipiada por el usuario a una URL específica. El archivo de configuración que descargó esta amenaza del C&C contiene un enlace hacia un script ubicado en un servidor remoto:

Script y servidor remoto

Cuando el usuario visita algún sitio afectado por este malware, el script que aparece arriba es inyectado y causa que la página descargue otro script de un servidor controlado por el operador por el botmaster. Este segundo script es el responsable de robar la información personal de la víctima. En este ejemplo, se inyectan campos que le solicitan al usuario información extra. Asimismo, se le menciona que debe ingresar dichos datos con el fin de poder desbloquear su cuenta. En la siguiente imagen se muestra la información que buscan estos cibercriminales:

Sitio modificado por Gataka para robar información

Los siguientes países sus propios mensajes personalizados:

  • Estados Unidos
  • Canadá
  • Reino Unido
  • Australia
  • España
  • Francia
  • Alemania

Cuando el usuario ingresa todo lo solicitado, se comprueba mediante el mismo JavaScript inyectado que todos los datos escritos sean válidos. Por ejemplo, el algoritmo de Luhn es usado para validar números de tarjetas de crédito. Esta información es enviada de vuelta al C&C a través de un enlace y una contraseña provista por el script descargado anteriormente.

Script previamente descargado

En este caso el enlace y la contraseña son almacenadas en texto plano en el JavaScript. En resumen, Win32/Gataka emplea técnicas interesantes para robar información valiosa a una víctima. Utilizando hooks de API, el plugin Interceptor es capaz de observar todo el tráfico entrante y saliente. Así, modifica e inserta nuevos contenidos y campos en los sitios afectados. Esto facilita que un cibercriminal inyecte scripts avanzados que intenten de forma automática sustraer todo el dinero de una cuenta o el robo de información personal. En una d elas campañas que se ha seguido observando, se pudo determinar que los ciberdelincuentes estaban utilizando archivos de configuración compatibles con otras amenazas. Este hallazgo permitió llegar a la conclusión de que algunos desarrolladores de códigos maliciosos se especializan en determinados aspectos. En este caso, los autores de archivos de configuración tienen la particularidad de poder vender este componente a larga lista de “clientes” más allá del malware que utilicen en cuestión. Al permitir que el script en sí mismo se pueda comunicar con el C&C hace más fácil implementar compatibilidad con otros códigos maliciosos diseñados para robar información.

Traducido y adaptado por André Goujon.
Especialista de Awareness & Research.