Hesperbot – Análisis técnico 2 de 2

El siguiente artículo es una traducción y adaptación del publicado por nuestro compañero Robert Lipovsky en el blog oficial de ESET WeLiveSecurity.

Win32/Spy.Hesperbot es un nuevo troyano bancario que ha estado afectando a usuarios de banca online en Turquía, la República Checa, Portugal y el Reino Unido. En este tercer post revisaremos la parte más intrigante del malware: la manera en la que intercepta el tráfico de red. Las campañas de propagación del malware y sus víctimas y una visión general técnica de la arquitectura del malware, su componente móvil y otras características han sido descritas en el primer y segundo post.

Intercepción del tráfico de red e inyecciones web

Otros conocidos troyanos bancarios como Zeus y SpyEye son capaces de interceptar y modificar el tráfico HTTP y HTTPS anclándose en las funciones WinSock (send, WSASend, etc.) y en funciones de nivel superior WinInet (HttpSendRequest, InternetReadFile, etc.). Como en las inyecciones web, el robo de datos desde formularios y otros engaños realizados por estos troyanos bancarios tienen lugar en el navegador afectado, conociéndose este método como el ataque “Man-in-the-Browser”. No obstante, Win32/Hesperbot toma una aproximación diferente no muy común pero que ha sido, de hecho, usada por el troyano bancario Gataka. Un buen análisis técnico de Win32/Gataka realizado por nuestro compañero Jean-Ian Boutin puede encontrarse aquí.

La interceptación del tráfico de red y la funcionalidad de inyección HTML en Win32/Spy.Hesperbot se consigue por el trabajo conjunto de los módulos de los plugin nethk, httphk y httpi.

Imagen 1– Relaciones entre los módulos de interceptación de red

A continuación mostramos una breve descripción del propósito de cada uno de los módulos:

Nethk: utilizado para configurar un proxy local, anclar funciones del socket para conducir las conexiones a través del proxy y anclar las funciones de verificación del certificado SSL del navegador. También maneja el descifrado y cifrado del tráfico HTTPS que circula a través del proxy.

• httphk – utilizado para analizar el tráfico HTTP interceptado por el proxy.
• httpi – utilizado para tomar capturas de pantalla, vídeos, recopilación de información desde formularios e inyecciones web de acuerdo con el fichero de configuración.

Ahora echémosle un vistazo de cerca a cómo los módulos trabajan juntos y cumplen sus tareas. Tal y como hemos mencionado anteriormente, los módulos exponen sus funciones en una vtable para que puedan ser usadas por otros módulos. El programa fluye entre los módulos al tiempo que cada solicitud HTTP o respuesta es interceptada a través de funciones callback.Nethk

Nethk es el primer módulo del complemento en ser cargado por el módulo core. Win32/Spy.Hesperbot realiza un ataque man-in-the-middle creando un proxy local a través del cual dirige todas las conexiones desde el navegador.

Imagen 2 – Direcciones IP locales en el código del Hesperbot

Imagen 3 – Internet Explorer conectado a través del proxy de Hesperbot

Para conseguir esto, el módulo nethk del troyano crea un proxy en un puerto aleatorio en la dirección 127.0.1.1 y ancla las siguientes funciones en la librería mswsock.dll, la librería de bajo nivel Winsock SPI:

• ·         WSPSocket
• ·         WSPIoctl
• ·         WSPConnect
• ·         WSPCloseSocket

Los punteros a estas funciones son modificados en WSPPROC_TABLE. Para comprender cómo funciona la redirección del proxy, echemos un vistazo a la función anclada WSPConnect.

Imagen 4 – API WSPConnect anclada

El socket del navegador, cuando intentamos conectarnos a un sitio web seguro de banca online, por ejemplo, se conecta en su lugar al proxy creado por Hesperbot. En otro hilo, la conexión legítima se establece con el sitio web.

Imagen 5 – Vista general de la interceptación del tráfico HTTPS a través del proxy de Hesperbot

Una httphk-callbak es lanzada cada vez que el proxy intercepta una solicitud desde el navegador, antes de pasarla al servidor real. De la misma forma, otra httphk-callback es lanzada cada vez que el proxy intercepta una respuesta desde el servidor real, antes de enviársela al navegador. A continuación, el módulo httphk analiza el tráfico.

Hay una diferencia entre el manejo del tráfico HTTP y el HTTPS. En caso del HTTP, la solicitud o datos de respuesta es simplemente enviado al httphk. En el caso de HTTPS, nethk primero se “encarga del cifrado”. Cuando se intercepta una solicitud HTTPS del navegador (cifrado usando su propio certificado SSL y explicado a continuación) esta es descifrada, y los datos descifrados son enviados a httphk a través del callback y luego cifrados usando el certificado real del servidor (p.ej. sitio web de un banco) para, seguidamente, ser enviados a su destino real. Recíprocamente, cuando una respuesta HTTPS se recibe desde el servidor, es descifrada usando el certificado real mientras los datos cifrados son enviados de nuevo al httphk y luego cifrados usando el certificado falso de Hesperbot antes de ser enviados al navegador.

En efecto, a través del proxy man-in-the-middle, Win32/Spy.Hesperbot puede acceder a las comunicaciones salientes HTTPS de la víctima antes de que se cifre y sus comunicaciones entrantes HTTPS después de ser descifradas. El mismo efecto se consigue con las técnicas de Man-in-the-Browser de los malware Zeus y SpyEye, pero esta nueva aproximación es ligeramente más sigilosa.

Por supuesto, está redirección maliciosa vía proxy debe realizarse por un certificado inválido para un sitio web HTTPS. Los autores de Hesperbot también pensaron en esto. El módulo nethk lleva sus propios certificados SSL autofirmados y estos sustituyen a certificados legítimos.

Imagen 6 – Certificados SSL dentro del binario nethk

Imagen 7 – Ejemplo de certificados falsos en uso de Hesperbot. En un sistema limpio, el certificado de Google se mostraría aquí.

Para poder engañar al navegador y que crea que el certificado es válido y evite mostrar un mensaje de alerta, el módulo malicioso también secuestra las funciones responsables de la verificación de los certificados. La implementación difiere dependiendo del navegador. La siguiente tabla muestra que navegadores son soportados por Win32/Spy.Hesperbot y que funciones son secuestradas.

Imagen 8 – Funciones de verificación del certificado secuestrado por Hesperbot para diferentes navegadores

Una característica interesante de este código malicioso es que los autores han usado hashes en lugar de usar  nombres de procesos del navegador directamente,para así complicar el análisis y, más importante, para proteger el malware de la detección por firmas de los antivirus.

Imagen 9 – Ofuscación de código en Win32/Hesperbot. Se utilizan hashes en lugar de nombres de procesos

La imagen a continuación muestra el código de CertVerifyCertificateChainPolicy.

Imagen 10 –  API de CertVerifyCertificateChainPolicy

En el caso del proceso de verificación de la política en cadena de un cliente/servidor SSL (otros tipos son rechazadas y enviados a la función original), la función secuestrada simplemente devuelve un resultado indicando que se comprobó la revisión de la política.

Httphk

El modulo httphk sólamente se hace responsable de interceptar los datos del protocolo HTTP. Cuando se lanza el httphk-callback, intercepta las cabeceras HTTP y los datos para rellenar una estructura interna. Esta estructura será accedida por el módulo httpi.

De nuevo, httphk expone dos funciones callbak para invocar httpi: httpi_request_callback and httpi_response_callback.

Httpi                          

Este es el módulo principal que realiza la modificación de los datos HTTP, de acuerdo con el fichero de configuración.

Cuando se llama a httpi_request_callback se realizan las siguientes acciones:

• Captura de pantallas y vídeos: el módulo lee el fichero de configuración y revisa la URL solicitada. Si se especifica en la configuración, la captura de pantalla y vídeo se empieza a realizar.
• Recopilación de formularios: el módulo revisa si existe una solicitud POST a través del esquema HTTP y si el tipo de contenido es “application/x-www-form-urlencoded” o “text/plain”. Si se cumplen estas condiciones, es probable que el usuario haya enviado un formulario. Si el fichero de configuración especifica que la URL debe ser monitorizada, estos datos se guardan en un registro.

Cuando se llama a httpi_response_callback ocurre lo siguiente:

• Inyección HTML: lo primero que hace el troyano es revisar si el código de respuesta HTTP es 200. A continuación, lee el fichero de configuración y, si existen entradas de inyección web para la página web que responde, se introducen en el contenido HTML.

La imagen a continuación muestra un fichero de configuración descifrado utilizado en la botnet portuguesa. Puede observarse que el primer grupo de dominios (ignorados por httpi) son de poco interés para los operadores de la botnet. A pesar de que las credenciales robadas de sitios como Google o Facebook serían consideradas como valiosas para otro software espía, esto demuestra que los creadores de Hesperbot solo están interesados en los datos relacionados con banca online. Las páginas web  objetivo se listan a continuación de las ignoradas. El resto del fichero de configuración contiene códigos HTML que se supone deben inyectarse en los sitios web bancarios.

Imagen 11 – Fichero de configuración descifrado de la inyección web usado en la botnet portuguesa.

Parece que las personas que escribieron los scripts de la inyección web hablaban ruso, tal y como se deduce de los comentarios en el código fuente. No obstante, observamos que los scripts podrían ser o no escritos por las mismas personas que crearon el malware Win32/Spy.Hesperbot y/o manejan la botnet. Los scripts de inyección web son normalmente compartidos y reutilizados. Esto es posible cuando se utiliza un formato similar en varias familias de malware y la especialización entre los cibercriminales es algo común.

Authores:
Anton Cherepanov
Robert Lipovsky

Listado de MD5s
3d71bc74007a2c63dccd244ed8a16e26
ce7bcbfad4921ecd54de6336d9d5bf12
f8ef34342533da220f8e1791ced75cda
1abae69a166396d1553d312bb72daf65
83b74a6d103b8197efaae5965d099c1e
91c5a64e6b589ffcfe198c9c99c7d1f0
ae40a00aad152f9113bc6d6ff6f1c363
27d8098fe56410f1ac36008dbf4b323e
8a9cb1bb37354dfda3a89263457ece61
ff858b3c0ea14b3a168b4e4d585c4571
1243812d00f00cef8a379cb7bc6d67e7
1e1b70e5c9195b3363d8fb916fc3eb76
4cf7d77295d64488449d61e2e85ddc72
5410864a970403dae037254ea6c57464
64a59d4c821babb6e4c09334f89e7c2d
1f7b87d5a133b320a783b95049d83332
028a70de48cd33897affc8f91accb1cd
4cc533ef8105cbec6654a3a2bc38cb55
59427cfb5aa31b48150937e70403f0db
c8ee74ada32ea9040d826206a482149e
d3c7d6d10cd6f3809c4ca837ba9ae2e8