A lo largo de los últimos años, los malware bancarios (también conocidos como “bankers”) han visto disminuida su popularidad entre los cibercriminales. Una de las razones para explicar esta realidad puede deberse a que tanto las compañías desarrolladoras de soluciones de seguridad, como los desarrolladores de navegadores, están continuamente ampliando el campo de acción de sus mecanismos de protección contra ataques de troyanos bancarios. Esto hizo que los fraudes mediante malware bancarios sean más difíciles de realizar, lo que trajo como resultado que los creadores de estos códigos maliciosos se enfocaran más en el desarrollo de otros tipos de malware más rentables y fáciles de desarrollar, como ransomware, mineros de criptomonedas o códigos maliciosos para robar criptomonedas.
Sin embargo, recientemente descubrimos una nueva familia de malware bancario que utiliza una técnica innovadora para manipular el navegador: en lugar de usar métodos complejos de inyección de procesos para monitorear la actividad del navegador, el malware coloca hooks para interceptar eventos específicos del bucle de mensajes de Windows, de tal modo que pueda inspeccionar los valores de las ventanas en busca de actividades bancarias.
Una vez que la actividad bancaria es detectada, el malware inyecta un JavaScript malicioso en el sitio web, ya sea a través de la consola JavaScipt del navegador o directamente en la barra de dirección. Todas estas operaciones son realizadas sin que el usuario se entere. Si bien se trata de un truco aparentemente sencillo, logra vencer los mecanismos avanzados de protección contra ataques complejos en navegadores.
INTRODUCCIÓN
En enero de este año notamos por primera vez al grupo detrás de este malware bancario propagando sus primeros proyectos; siendo uno de ellos un malware que robaba criptomonedas reemplazando la dirección de las billeteras en el portapapeles. El grupo se focalizó en malware de clipboard durante unos meses, hasta que finalmente introdujo la primera versión del malware bancario, detectado por ESET como Win32/BackSwap.A, el 13 de marzo de 2018.
En la imagen a continuación se puede apreciar un alarmante pico en la tasa de detección en comparación con los proyectos previos. Los autores han estado muy activos en el desarrollo del banker y han estado introduciendo nuevas versiones casi que a diario; tomando descansos solamente los fines de semana.
Imagen 1. Visión general de las detecciones del malware bancario Win32/BackSwap.A y proyectos previos relacionados.
DISTRIBUCIÓN Y EJECUCIÓN DEL MALWARE BANCARIO
El banker es distribuido mediante campañas de spam maliciosas a través del correo, que contienen como adjunto un downloader JavaScript, fuertemente ofuscado, de una familia comúnmente conocida como Nemucod. De acuerdo a lo que vimos, las campañas de spam están dirigidas principalmente contra usuarios polacos.
Frecuentemente, las máquinas de las víctimas también están comprometidas por el popular downloader Win32/TrojanDownloader.Nymaim, el cual parece propagarse utilizando un método similar. Hasta el momento, no sabemos si esto se trata de una coincidencia o si estas dos familias tienen conexión directa.
El payload es enviado como una versión modificada de una aplicación legítima que está parcialmente sobrescrita por el payload malicioso. Asimismo, van cambiando la aplicación que modifican de manera regular (ejemplos de apps que fueron trastocadas con un propósito malicioso incluyen, por ejemplo, TPVCGateway, SQLMon, DbgView, WinRAR Uninstaller, 7Zip, OllyDbg, y FileZilla Server). Por otra parte, la app es manipulada para que salte hacia el código malicioso durante su inicialización. Una de las técnicas utilizadas para lograr esto es agregando un puntero al payload malicioso en la tabla de funciones _initterm(), la cual es una parte interna del entorno de ejecución de C que inicializa todas las variables globales y otras partes del programa que necesitan inicializarse antes de que se llame a main().
Imagen 2. – Array de punteros initterm de una aplicación legítima con puntero hacia los shellcode bankers al final.
Este método puede parecer una reminiscencia de una “troyanización”, pero la diferencia es que la aplicación original deja de funcionar, y una vez que el control es traspasado hacia el malware, nunca volverá al código original. Por lo tanto, la intención no es engañar a los usuarios y hacerlos creer que están ejecutando la aplicación original, sino más bien aumentar la capacidad de camuflaje del malware para que pase desapercibido frente a posibles análisis y detecciones. Esto hace que el malware sea difícil de identificar para un analista, ya que varias herramientas de ingeniería inversa, como IDA Pro, presentarán a la función principal original como el legítimo inicio del código de la aplicación y lograrán que en un primer momento un analista no detecte nada sospechoso.
El payload es una pequeña porción de código con todos sus datos embebidos en él, que no presenta direccionamiento fijo. Las cadenas de caracteres están almacenadas en texto plano, lo cual arruina el pequeño rastro que dejaba el malware, ya que todas las API de Windows que se necesitan son buscadas mediante hash en tiempo de ejecución. El malware empieza por copiarse a sí mismo dentro de la carpeta de inicio para asegurarse la persistencia y luego proceder con su funcionalidad.
MÉTODO DE INYECCIÓN CONVENCIONAL
Para robar dinero de la cuenta de una víctima a través de una interfaz de online banking, los típicos malware bancarios se inyectarían a sí mismos o su módulo bancario especializado en el espacio de direcciones del proceso del navegador. Por muchas razones, esta no es una tarea sencilla, ya que como mencionamos anteriormente, la inyección podría ser interceptada por una solución de seguridad. El módulo inyectado también necesita coincidir con la versión del navegador- un módulo de 32 bits no podría ser inyectado en un navegador 64 bits y viceversa. Esto hace que los troyanos bancarios tengan que transportar ambas versiones de un módulo para poder soportar ambas versiones del navegador, tanto en 32 como 64 bits.
Cuando es inyectado de manera satisfactoria, el módulo bancario necesita encontrar las funciones específicas del navegador y colocar hooks. El malware busca funciones que son responsables de enviar y recibir solicitudes HTTP en texto plano antes del cifrado y después del descifrado, respectivamente. La dificultad de encontrar estas funciones varía según el navegador ─en el caso de Mozilla Firefox, las funciones son exportadas a través de la librería nss3.dll y sus direcciones pueden ser buscadas sin esfuerzo por sus conocidos nombres. Por el otro lado, en Google Chrome y otros navegadores basados en Chomium estas funciones están escondidas y son implementadas en el interior del binario, lo que hace que sea muy difícil de encontrarlas. Esto obliga a los autores del malware utilizar métodos especializados y patrones que solo funcionan para la versión específica del navegador. En este sentido, una vez que se lanza una nueva versión, nuevos métodos y patrones deben implementarse.
Si las funciones correctas son encontradas y los hooks son instalados de manera satisfactoria (nótese que los hooks pueden llegar a ser detectados por soluciones de seguridad), el troyano bancario puede comenzar a modificar el tráfico HTTP o redireccionar a la víctima hacia un sitio web que aparente ser el de un banco, falsificando un certificado de validación. Técnicas similares son incorporadas por troyanos bancarios de alto nivel y actualmente activos, como Dridex, Ursnif, Zbot, Trickbot, Qbot y muchos otros más.
NUEVA TÉCNICA DE MANIPULACIÓN DE NAVEGADORES
Win32/BackSwap.A tiene un abordaje completamente diferente. Manipula todo al trabajar con elementos de la GUI de Windows y simulando el accionar de un usuario. Esto puede parecer trivial, pero es de hecho una muy poderosa técnica que soluciona muchos “problemas” asociados a la inyección de navegadores convencionales. Primero que nada, el malware no interactúa en ningún punto con el navegador a nivel de procesador, por lo tanto, no requiere de privilegios especiales y anula cualquier fortalecimiento del navegador por parte de terceros; que generalmente se enfocan en métodos de inyección convencionales. Otra ventaja para los atacantes es que el código no depende ni de la arquitectura del navegador ni de su versión, y que un único patrón de código funciona para todos los navegadores.
El malware monitorea la URL que se está visitando mediante la instalación de hooks de eventos para un rango específico de eventos relevantes y disponibles a través del bucle de mensajes en Windows, como EVENT_OBJECT_FOCUS, EVENT_OBJECT_SELECTION, EVENT_OBJECT_NAMECHANGE y algunos otros. El hook buscará patrones de URL al revisar los objetos para líneas que comiencen con “https” recuperadas al llamar al método get_accValue desde la interfaz de eventos IAccessible.
Imagen 3. Técnicas utilizadas para recuperar del navegador direcciones web que fueron actualmente visitadas. Estas direcciones con recuperadas mediante la revisión de la cadena [ht]tp[s] (en color rojo).
El malware en ese momento buscará URLs específicas del banco y títulos de ventanas en el navegador que indiquen que la víctima está por realizar una transferencia bancaria.
Imagen 4. Los bankers buscan una cadena de caracteres específica –la primera línea corresponde al título de una ventana, la segunda es parte de una URL.
Una vez identificadas, el banker carga el JavaScript malicioso apropiado para el banco correspondiente y lo inyecta en el navegador. La inyección del script es realizada de una manera simple, pero efectiva.
En muestras más antiguas, el malware inserta el script malicioso en el portapapeles y simula digitar la combinación necesaria para abrir la consola de desarrolladores (CTRL+SHIFT+J en Google Chrome, CTRL+SHIFT+K en Mozilla Firefox) seguido por CTRL+V, que pega los contenidos del portapapeles y luego envía ENTER para ejecutar los contenidos de la consola.
En las nuevas variantes del malware, este enfoque fue actualizado –en lugar de interactuar con la consola de desarrolladores, el script malicioso se ejecuta directamente desde la barra de dirección a través del uso del protocolo JavaScript, una función poco utilizada que ofrecen la mayoría de los navegadores. El malware simplemente simula presionar CTRL+L para seleccionar la barra de dirección seguida por la función DELETE para eliminar el campo, luego “digitar” en “javascript:” mediante el llamado SendMessageA en un bucle, y luego pegar el script malicioso con la combinación CTRL+V. Luego ejecuta el script mediante el envío de la tecla ENTER. Al final del proceso, la barra de dirección es limpiada para remover cualquier rastro de la intrusión.
En la figura 5 podemos ver una parte del código de inyección de la consola: primero, el malware determina el navegador al chequear el nombre de clase de la ventana en primer plano (marcada en azul). El JavaScript malicioso es copiado en el portapapeles (marcado en rojo). Luego, la opacidad de la ventana del navegador es cambiada a 3, convirtiéndola en invisible (marcado en púrpura). En color verde se marca la parte de la función ToggleBrowserConsole que activa o desactiva la consola de los navegadores.
Imagen 5. Técnica de inyección del script.
Win32/BackSwap.A soporta ataques contra Google Chrome, Mozilla Firefox y en versiones recientes sus autores también agregaron soporte para Internet Explorer. Sin embargo, este método funcionará para la mayoría de los navegadores actuales, siempre que esté disponible una consola JavaScript o que ejecuten JavaScript desde la barra de direcciones, ambas funciones estándar en los navegadores actuales.
Cada uno de los tres navegadores cuenta con una función de seguridad interesante, que fue diseñada originalmente como contramedida frente a ataques de ingeniería social como Self-XSS. Cuando usuarios intentan pegar texto que comience por “javascript” en la barra de direcciones, el prefijo del protocolo es removido y los usuarios necesitan escribirlo manualmente en la barra de direcciones para ejecutar el script. Win32/BackSwap.A evade la contramedida simulando el tipeo del prefijo en la barra de direcciones, letra por letra, antes de pegarlo en el script malicioso.
Otra contramedida implementada por Mozilla Firefox es deshabilitar el pegado de scripts en la consola por defecto y en su lugar muestra un mensaje de advertencia para los usuarios sobre riesgos potenciales, forzándolos a tipear primero las palabras “permitir pegado”. El malware anula esto al ejecutar el comando por consola que se muestra en la figura 6, el cual modifica la configuración del archivo prefs.js y elimina la contramedida.
Imagen 6. El shell command utilizado para remover la protección de pegado de script en la consola de Firefox.
JAVASCRIPT MALICIOSO
El banker implementa un script específico para cada banco, ya que cada sitio bancario es diferente y presenta un código fuente distinto. Estos scripts son inyectados en páginas en las que el malware identifica una solicitud de inicio de transferencia bancaria, como el pago de una cuenta. El script inyectado de manera secreta reemplaza el número de cuenta del destinatario con uno diferente y cuando la víctima decide enviar la transferencia bancaria, el dinero será enviado en su lugar al atacante. Cualquier medida de seguridad contra pagos no autorizados, tales como doble factor de autorización, no será de ayuda en este caso dado que el propietario de cuenta está enviando la transferencia voluntariamente.
Win32/BackSwap.A ha tenido scripts maliciosos dirigidos a un total de cinco bancos polacos, como son: PKO Bank Polski, Bank Zachodni WBK S.A., mBank, ING and Pekao. Sus autores retiran algunos bancos de la lista de blancos y en sus versiones más recientes dejaron, por ejemplo, solo tres bancos: PKO BP, mBank and ING. En versiones anteriores, los atacantes estaban almacenando los números de sus cuentas bancarias receptoras en servidores C&C que estaban alojados en páginas de WordPress comprometidas. En la versión reciente, almacenaron estos números de cuentas directamente en el script malicioso. Los números de cuentas bancarias maliciosas cambian de manera muy frecuente, y prácticamente todas las campañas tienen uno nuevo.
Como podemos apreciar en la imagen más abajo, el banker solo robará dinero si el monto de la transferencia bancaria está dentro de cierto rango – generalmente eligen como blancos pagos que estén entre los 2.800 y los 5.600 USD. El script reemplaza la cuenta bancaria receptora original y también reemplaza el campo de entrada para esos números con uno falso que muestra la cuenta bancaria original, para que de esta manera el usuario vea el número válido y no sospeche de nada.
Imagen 7. Parte del JavaScript Malicioso. Las áreas marcadas en rojo muestran la confirmación del monto de la transferencia bancaria y el reemplazo del número de cuenta receptora.
CONCLUSIÓN
Win32/BackSwap.A nos muestra que en el transcurso de la batalla entre la industria de seguridad y los autores de malware bancario, las nuevas técnicas maliciosas no necesitan ser altamente sofisticadas para ser efectivas. Pensamos que en la medida de que los navegadores estén más protegidos ante la inyección de códigos convencionales, los autores de malware atacarán los navegadores de diferentes formas. En este sentido, Win32/BackSwap.A simplemente nos mostró una de las posibilidades.
Fuente: Noticiasseguridad.com
