Hace mes y medio David Barroso y yo nos fuimos de visita a casa de un usuario de banca electrónica que vivía en un pueblo de Navarra. David extrajo un archivo de su teléfono móvil y yo recuperé algunos archivos relacionados con dos infecciones de ZeuS. Este fue el inicio del llamado ZeuS MitMo.

Cuando ZeuS inyecta código HTML, normalmente solicita al usuario que ingrese la clave de firma o las posiciones de la tarjeta de coordenadas para poder realizar transferencias fraudulentas, pero a veces esta información no es suficiente. Algunos bancos solicitan además un código, enviado a través de SMS, que el usuario (o el criminal) deberá introducir para completar la transacción. Cuando el MitMo no existía, esta segunda autenticación era un éxito, pero no a partir de aquel día. El grupo responsable de esta nueva oleada de infecciones se había preocupado de modificar las inyecciones HTML para solicitar, además de los datos habituales, el número de teléfono móvil. Ya lo habíamos visto anteriormente, pero hasta el momento nunca se había usado para cometer el fraude. En esta ocasión, una vez introducido el número de teléfono, los delincuentes enviaron un SMS a la víctima donde se incluía un enlace y se instaba al usuario a instalar un “certificado”. Cuando el usuario lo hizo, una aplicación maliciosa comenzó a monitorizar los mensajes entrantes en busca de los remitidos por el banco en cuestión, y reenviándolo a los criminales. De esta forma, tenían en su poder toda la información necesaria para poder realizar la transacción de forma satisfactoria.

Además de incluir código para solicitar el número de teléfono, este archivo de configuración tenía otra peculiaridad. Cuando el usuario visitaba la URL del banco ZeuS añadía un elemento script en la página legítima apuntando a una URL, evitando así almacenar todo el código HTML en el archivo de configuración. Tampoco era algo nuevo, pero sí el hecho de que el elemento src no apuntara a una URL absoluta sino relativa:

¿Pero entonces dónde estaba el archivo Javascript? Leyendo cuidadosamente el archivo de configuración descifrado vimos que cuando el navegador intentara cargar la URL (regexp: */.Rx.x.xR./*) era redirigido a otro dominio. Este dominio resolvía a la misma dirección IP que la que se incluía en el enlace del SMS malicioso. Pero obtener el código no era tan fácil como visitar http://dominio_malicioso.info/es/mibanco.js, ya que había filtros que lo impedían. En este servidor existía un archivo htaccess que redirigía todas las peticiones al directorio es y a la URL de la aplicación maliciosa hacia un archivo PHP cifrado con Zend. Tras descifrar el archivo se podía ver que existía un nivel más de redirección, ya que el archivo PHP estaba solicitando los archivos a otro panel de ZeuS, incluyendo en la cabecera Referer una clave RC4:

El binario relacionado con este archivo de configuración era una versión 2.0.8.11 que en el momento del análisis tenía una tasa de detección baja por parte de los antivirus. El comportamiento general del troyano era el mismo que otras muestras de la rama 2.0.x, pero añadía un pequeño detalle en la comunicación con el panel de control. Para poder descargar el archivo de configuración del servidor era necesario añadir la cadena X-Tag/53F54B2D en la cabecera User-Agent de la petición HTTP. Si este parámetro no estaba presente el archivo no se descargaría.

Quizá los rumores sobre la fusión del código de ZeuS y Spyeye sean ciertos, pero creo que tendremos que esperar bastante tiempo hasta que esta nueva creación campe a sus anchas, sin ningún desarrollo paralelo de sus antecesores. Al fin y al cabo, ¿por qué comprar un nuevo troyano si el actual funciona perfectamente?
 

Nota: Publicado originalmente en el blog de S21sec