ZeuS, análisis del archivo de configuración que atacó la banca por internet

Hace algunos días se propagó un malware por internet, este malware pertenece a la gran familia de botnets creadas con el Toolkit de Zeus. 

 
Toolkit ZeuS es un software que permite a cualquier usuario con conocimientos básicos en cómputo crear un rebaño de equipos zombies para realizar ataques masivos, robar credenciales de redes sociales, robar cuentas de correo electrónico y en éste caso específico el robo de información de usuarios de la banca electrónica. Este Toolkit es conocido como crimeware y es ofrecido en foros underground e incluso por correo electrónico a precios muy accesibles.

El kit de crimeware contiene los siguientes módulos:
  1. Una interfaz web para administrar y controlar la Botnet (ZeuS admin Panel) 
  2. Una herramienta con la cual se crean troyanos binarios y pueden ser cifrados con un archivo de configuración (azul)
  3. Un archivo de configuración (rojo)
  4. Un archivo binario el cual contiene la más reciente versión de ZeuS (verde)
  5. Un archivo de webinjects para usuarios avanzados (amarillo) 
 
La banca en línea inmediatamente comenzó a mandar notificaciones a sus usuarios advirtiéndoles acerca de una presunta actualización o la solicitud de datos para ingresar a sus cuentas. 
 
 
El UNAM CERT obtuvo el archivo de configuración, dicho archivo es necesario cargarlo en la herramienta ZeuS Builder (punto 2 del kit crimeware mencionado anteriormente) para la creación de binarios troyanos. 
 
El archivo proporcionado no estaba bien creado por lo que fue necesario agregar líneas para poder cargarlo en el Builder, a continuación se explicará la función de cada módulo.
 
1) Configuraciones estáticas. Describe las acciones que ZeuS directamente realiza en el equipo sin la inyección de otras herramientas o interferencia del usuario. Las acciones pueden ser, robar contraseñas alojadas en el equipo, robar información del caché, correos electrónicos, conversaciones de chat y mucho más. Dentro de esta sección se encuentra la opción url_config el cual es muy importante ya que a partir de esta dirección IP es posible cambiar la configuración dinámica que se mencionará más adelante.
a.timer_logs. Intervalos de tiempo para subir los logs al servidor
b.timer_stats. Intervalos de tiempo para subir estadísticas de infecciones al servidor
c.url_config. URL del servidor donde estará leyendo los archivos de configuración
d.encryption_key.Llave de cifrado para la comunicación entre la máquina zombi y el servidor C&C
 
 
2)Configuración dinámica. La configuración dinámica se refiere a las acciones que ZeuS realizará mientras interactúa con el usuario. Por ejemplo puede ser la automatización de la descarga de un archivo y ejecutarla en el equipo, inyectar códigos en páginas de bancos robando las credenciales de acceso o utilizando técnicas de ataque “man in the middle” inyectando contenidos dinámicos. ZeuS necesita del url loader donde por lo regular se encuentra la más reciente versión de los binarios  y del url server donde direccionará el trafico descargado por el mismo, conocido como “Command and Control Server”.
a.url_loader. URL donde se encuentra la última versión de la botnet ZeuS
b.url_server. Servidor C&C
c.file_webinjects. Parámetro que debe contener el nombre del archivo para la inyección de código HTML en las páginas Web
d.AdvancedConfigs. URL donde buscará una copia del archivo de configuración
 
 
 
3)Webfilters. Contiene una lista de URLs que pueden ser monitoreadas para capturar y robar credenciales. 
 
 
4)TANGrabber. TAN (Transaction Authentication Number) Grabber es una característica de Zeus que permite especificar a la botmaster sitios bancarios para monitorear patrones específicos en busca de transacciones bancarias en sitios web. Zeus buscará estos patrones y los enviará al C&C Server.
 
 
5)DNSMap. Direcciona las peticiones a un sitio especificado. En este caso el autor del archivo de configuración direcciona todas las peticiones a sitios antivirus al equipo local (127.0.0.1).
 
 
En la sección DynamicConfig se tiene el apartado de file_injects, donde se hace hace referencia a un archivo llamado webinjects.txt  que se encuentra en el mismo directorio, este archivo contienen el código que será inyectado en las páginas web para realizar el robo de credenciales. 
 
De manera general el archivo webinjects consta de tres secciones:
1)set_url. Indica la página a la cual se realizará la inyección de código html
2)data_before. Indica antes de que texto inyectará el nuevo código html
3)data_after. Indica después de qué texto inyectará el nuevo código html
4)data_inject: Código inyectado.
 
Un ejemplo sencillo para explicar lo anterior que fue tomado del archivo de configuración proporcionado es el siguiente:
 
 
En este caso al visitar el sitio banking.*/cgi/finanzstatus.cgi* (el signo * representa cualquier texto o número), antes del texto “<body” y después del texto “>” inyectará el texto style=”visibility:hidden”. 
 
El archivo webinjects proporcionado tiene 69 inyecciones de código a los siguientes bancos:
 
*.de/portal/portal/*
*bankinter.com*utils.js*
*bankinter.com*gzinflate.js.php*
*bankinter.com/www/es-es/cgi/*+home
http*caixacatalunya*Home*html
*cajaespana.net*
*ruralvia.com/isum/*login*
 
Estos archivos son cargados por el ZeuS builder para crear los binarios ejecutables.
 
 
Carga del archivo webinjects.
 
 
Sin embargo no fue posible para nosotros terminar de crear el ejecutable ya que no contamos con la interfaz Web.
 
Analizando el archivo Web Injects
 
En el archivo Web Injects encontramos inyecciones de código complejas y ofuscadas como el que se mencionara a continuación, así como inyecciones de código html sencillas.
 
La primera inyección de código html es realizada contra el banco HSBC de México. El código inyectado estaba tres veces ofuscado para no ser detectado. 
 
 
La primera sección de ofuscamiento se vuelve en texto claro en la función eval(xkxBlu), esta fución evalúa el contenido de la variable xkxBlu y la ejecuta, se sustituyó el la función eval por document.write, para ver el contenido de dicha variable.
 
El resultado de lo anterior fue un nuevo código ofuscado que genera la variable xmvEDf y la cual es evaluada y ejecutada con la función eval(xmvEDf).
 
 
Fue necesario igualmente sustituir la función eval(xmvEDF) por un document.write(xmvEDF) para ver el contenido en texto claro.
 
El resultado final fue la visualización de las funciones, sin embargo esas funciones se encontraban escritas en hexadecimal.  Se sustituyo totalmente el código ofuscado por el código desofuscado como se muestra a continuación, los cuadros rojos muestran algunos códigos en hexadecimal que el autor escribió.
 
 
Comenzamos a verificar el contenido de cada uno de los códigos para ir sustituyéndolos por código ASCII, lo anterior lo realizamos con un script en perl que iba leyendo el código en Hexadecimal y lo traduce a código ASCII.
 
 
 
Durante la traducción es posible ir leyendo los textos “Por favor introduzca los datos completos.” , y “Muchas gracias, la información de su OTP ha sido reciba y está en proceso de sincronización es muy importante que para que su OTP sea sincronizado satisfactoriamente no intente acceder a su cuenta HSBC durante los próximos 90 minutos, Gracias”
 
Ademas el autor validaba que estuviera en el sitio se hsbc para mostrar la pagina. Es posible ver esto en el código location.href.indexOf("https://www.hsbc.com.mx/1/2/!ut/p/kcxml/ y document.title ===   "HSBC M\u00E9xico - Home Banca Personal por Internet (HUBMIGRATION)"
 
La página se muestra a continuación.
 
 
Otros sitios en los cuales también se está realizando la inyección de HTML para robar información.