Análisis de una campaña de troyanos bancarios en Perú

Mauricio Velazco de Open-Sec nos envía un completo análisis de una campaña de troyanos bancarios en Perú que, por supuesto, tenemos el gusto de postear:

Troyanos Bancarios en Peru I : Operacion Bambi ? (1 y 2)

Hola.

Hace unos días recibí un correo electrónico, como ustedes también seguramente suelen recibir, con la típica postal de amor adjuntada a un mensaje cursi sobre un diseño visiblemente falso. Normalmente desecho estos correos pero ahora que dispongo de algo de tiempo me propuse hacerle un simple análisis para descubrir algo sobre su funcionamiento, sus creadores o lo que sea que pueda averiguar. Debo admitir que es algo que quiero hacer hace tiempo. El área de análisis de malware es realmente bastante interesante y puede llegar a ser muy compleja al jugar con debuggers y el binario. Sin embargo, dada mi calidad de newbie en este tema, este análisis será algo más superficial. Para hacerlo más interesante, separare este post en partes.

Ok, veamos el correo.

Al ver el código del correo puedo visualizar que todo está armado alrededor de una imagen hosteada en http://i55.tinypic.com/yyyy.jpg. Una imagen jpg, tal vez le pueda sacar algo de metadata con la siempre funcional Foca. Luego de ir al servicio online de la herramienta obtengo el siguiente resultado:

Interesante, según la Foca la imagen fue creada con Photoshop. Ahora para ser delincuente hay que saber de todo, hasta de diseño ! Otro dato interesante es la última fecha de modificación: el 26 de Octubre del 2010 a las 21:05 horas lo que nos brinda información sobre cuando empezó la campaña. Seguimos.

El link que descarga la "postal" apunta a http://xxx.com/Gusanito/Amor/Postal-Amor. Si ingresamos con el navegador, al instante vemos un pop up preguntando si deseas descargar el binario "Postal.exe". Hacer esto con un navegador no nos brinda la información que realmente queremos ver.

Utilizaremos netcat para ver más allá de lo evidente y ver la respuesta del servidor Web cuando hagamos el requerimiento a este recurso a través de HTTP.

El servidor responde con el código HTTP 302 que es una redirección. En la cabecera Location: podemos ver el nuevo destino: http://yyy.com/mjimenez/config.php . El malware no esta hosteado en www.xxx.com, tan solo es utilizado como un puente para llegar a él. Me pregunto porque el atacante lo ideo de esta manera, tal vez intenta implementar algo de seguridad para protegerse ? . Luego de las cabeceras HTTP se puede ver un Warning en un script php que además nos brinda una ruta del servidor (Path Disclosure). Por un momento pensé que estaba viendo un error originado en un servidor del atacante e incluso que ya había descubierto su nombre.

La emoción duró poco. Luego de analizar la respuesta concluyo que el atacante además de forzar una redirección desde http://xxx.com/Gusanito/Amor/Postal-Amor llama a un script hosteado también en el servidor comprometido : www.xxx.com/contador.php (que contiene un error al utilizar la función preg_match() y por eso el warning ). Infiriendo por el nombre, asumo que es usado para determinar cuántas personas ya han bajado su malware y llevar algo de estadística de esta campaña de ataque.

Vamos por el siguiente recurso http://yyy.com/mjimenez/config.php

Ok, el servidor responde con la cabecera Content-Disposition. Esta cabecera no me es familiar, estoy mas acostumbado a ver tan sólo Content-type en las respuestas. Luego de preguntarle a san Google descubro que cuando la cabecera Content-Disposition tiene como valor attachment, se fuerza al navegador a descargarse un fichero del servidor web, en este caso, el binario Postal.exe que espera ser ejecutado para infectar al usuario.

Al enviar el requerimiento por HTTP y ver el dump del binario en texto encuentro cosas interesantes (ver siguiente imagen). Primero observo una ruta de una instalación de Microsoft Visual Studio lo que nos da una luz sobre cómo fue creado este binario. Pero lo que mas llama mi atención es lo que parece ser la ruta del directorio donde el atacante estaba programando el malware. Viendo la extensión del archivo casa.vbp confirmamos el uso de Visual Studio además podemos afirmar que se trata de un proyecto de Visual Basic. Lo intrigante es el por qué del nombre de directorio "bambi". Será que el creador tiene una fascinación con el pequeño ciervo de cola blanca o es simplemente un nombre aleatorio? . De cualquier forma, este ataque ahora será conocido como La Operacion Bambi.

Hasta este punto tenemos conocimiento de 2 servidores vulnerados como parte de esta campaña que pertenecen a empresas que brindan servicios hosting. El primero www.xxx.com hostea el recurso Gusanito/Amor/Postal-Amor que al momento de ser requerido hace una redirección hacia el recurso /mjimenez/config.php del segundo servidor http://yyy.com donde finalmente se fuerza al navegador a descargar el fichero Postal.exe.
Luego de descargar el binario, aprovecho la genial herramienta online Virustotal para hacerle un análisis. Según sus resultados tan sólo 5 antivirus de 43 (11.6%) reconocen a Postal.exe como un malware variante de Kanzi. Pueden ver el reporte de Virustotal aqui.

Ahora veremos el funcionamiento del malware una vez ejecutado por la victima. El escenario : la víctima recibe el correo, confía en el título, descarga el archivo Postal.exe y lo ejecuta.

Antes de empezar, es importante recalcar que si reciben un archivo sospechoso NO LO EJECUTEN, apliquemos la política del implicit deny. Todo lo que parece extraño, lo desechamos y solo leeremos y abriremos correos de contactos conocidos. Ademas tengan en cuenta tener siempre un antivirus actualizado. Por otro lado, si lo que quieren hacer es jugar con el malware para ver lo que hace, utilicen una maquina virtual para probarlo. Aunque algunos tipos de malware reconocen si están corriendo sobre una maquina virtual y no ejecutan su payload, pero eso para otro día.

Ok, una vez ejecutado el malware lo primero que notamos es tráfico de red inusual. Utilizamos un analizador de paquetes como Wireshark para ver más allá de lo evidente.

En los paquetes 1y2 se observa una resolución DNS de un dominio .com. Al revisar el host, vemos que es de una empresa de latinoamérica cuyo servidor probablemente ha sido vulnerado como parte de la campaña. En 3,4 y 5 vemos el establecimiento de una sesión TCP el famoso SYN - SYN-ACK - ACK hacia el puerto 80 del server mencionado. A partir del paquete número 6 vemos lo mas interesante, un requerimiento HTTP con el método GET hacia un recurso localizado en /images/bg.jpg

Al ver el contenido de esta supuesta imagen las primeras lineas nos develan la naturaleza del ataque.

Al final del archivo, vemos lo mas interesante.

En su totalidad, este es el famoso archivo hosts. Para los que no saben que es, una breve descripción. Como sabemos, los equipos en internet utilizan su dirección IP para comunicarse entre ellos. Dado que sería imposible para un ser humano acordarse de los números IP de todos los dominios que visita, se invento el protocolo DNS para resolver una dirección IP a un nombre de dominio. Claro, es mas fácil para un usuario acordarse de www.google.com que de 74.125.226.115.

Sin embargo, el sistema operativo, antes de mandar una consulta al servidor DNS, lo primero que hace es revisar el archivos hosts. Este es un simple fichero localizado en el sistema de archivos del equipo (en Windows: C:\Windows\System32\drivers\etc\hosts En linux: /etc/hosts ) que contiene entradas con la estructura Direccion IP : Dominio. En resumen, cuando escribes en tu navegador www.google.com lo que hace el sistema operativo primero es buscar en el archivo hosts si existe alguna entrada para ese dominio (www.google.com). De existir, toma la dirección IP del archivo e intenta conectarse al mismo. Es decir, ya no hace la consulta DNS y confía en el archivo hosts.

Este ataque es conocido como Pharming. Lo que hace el malware primero es descargar un archivo hosts modificado maliciosamente y sobreescribe el archivo original del equipo por el descargado, de manera que cuando el usuario intente conectarse a cualquiera de esos dominios (todos de ellos bancos peruanos) en realidad se estará conectando a la IP del atacante quien configura un servidor Web en el equipo para que a la víctima se le presenta una Web idéntica a la de su banco y de esta forma podrá obtener las credenciales para luego hacer transacciones fraudulentas.

Como vemos, una única dirección IP es utilizada para todos los dominios. Al analizar el registro de esa dirección IP en la base de datos Whois de ARIN podemos observar que le pertenece a la empresa Turnkey Internet Inc localizada en Norteamérica. Esta empresa brinda servicios de hosting y servidores dedicados. Luego de realizar un DNS reverso y un escaneo de puertos, concluimos que el atacante adquirió un VPS (Virtual Private Server) de la compañía que tiene un costo que varia entre 39 y 129 dólares al mes. Ya saben lo que dicen, para ganar dinero hay que gastarlo. Habrá comprado el atacante este servicio son su propia tarjeta de crédito o con una robada ? De ser lo primero entonces Turnkey Internet Inc tiene la identidad real de nuestro atacante en su base de datos...

Viendo el escaneo de puertos vemos una típica instalación por defecto de un VPS, con un CPanel y Plesk para su fácil administración. SMTP, POP3, POP3S, IMAP, IMAPS, DNS, muchos servicios innecesarios lo que nos muestra que el atacante no hizo un hardening de su servidor y que nos puede dar una luz respecto a su perfil. Lo mismo si ingresamos al servidor Web sin suplirle una cabecera HOST, vemos algunos archivos por defecto de una instalación de apache.

Jugando un poco con las aplicaciones Web falsas me asombra el nivel de detalle que el atacante le ha añadido (todo en php). Incluso implementa la tarjeta de coordenadas utilizadas por muchos bancos para que las víctimas no sospechen. Probando algunas cosas, logro forzar un error PHP en el servidor lo que nos brinda un Full Path Disclosure y podemos averiguar el usuario con el que el atacante maneja su servidor: PEPITOCO. Al googlear este nick, vemos varios resultados pero no encontramos nada relevante.

Lamentablemente cuando quise darle más tiempo para analizar esta campaña, el servidor del atacante había sido dado de baja por el proveedor.

Con esto terminamos. Hemos visto a grandes rasgos el funcionamiento de un troyano bancario desde su propagación hasta su ejecución. Algo importante es que este malware apunta exclusivamente a bancos peruanos. Alrededor de 3 meses después de iniciada la campaña el servidor del atacante fue dado de baja. En ese tiempo, cuántas víctimas habrán ingresado sus credenciales en esos portales falsos ?

No lo olviden, desechar todo correo extraño. No está de más revisar si su archivo hosts no tiene algo extraño. Lo pueden encontrar en :
C:\Windows\System32\drivers\etc\hosts

Saludos.
MVelazco
http://twitter.com/mvelazco