La semana pasada estuvimos analizando un troyano que fue encontrado en servidores de 4 países de Latinoamérica y que afectaba a usuarios de redes sociales rusas. En esta oportunidad, continuaremos con el análisis, abordando los temas que quedaron inconclusos.
Recapitulando el análisis previo, "¿Qué pasó ayer en el Laboratorio? Analizando una muestra que recorre Latinoamérica", recordamos que el troyano, detectado como Win32/Bicololo.A, aparentaba ser un archivo de imagen, pero al descargarlo se obtenía un archivo ejecutable. Cuando el mismo era ejecutado escribía otros archivos en el disco, entre los cuales se encontraba un ejecutable batch y dos scripts de Visual Basic. El batch modificaba el archivo hosts, realizando pharming local a una serie de redes sociales y servicios de correo rusos, y luego lanzaba ambos scripts con Microsoft Windows Script Host, o WScript.exe.
Si observamos los cambios que se producen en el sistema luego de la ejecución de los scripts con Process Monitor, obtendremos la imagen que se muestra a continuación. Vemos en la primera línea que cmd.exe, que está ejecutando turtsia.bat, crea un proceso que lanzará el primer script. Este script realiza algunas acciones, y luego se lanza el otro script en un nuevo proceso.
El primer script que se ejecuta es soex.vbs. En la captura de eventos hemos aplicado filtros para ver los archivos escritos en el disco, y las claves del registro de Windows que han sido creadas, pero para el primer script no observamos nada que llame demasiado la atención con estos filtros. Sin embargo, se tuvo acceso al código del script, el cual se expone a continuación:
Se observa que el código parece confuso por los nombres de las variables, sin embargo es relativamente simple ya que lo importante se encuentra al principio y al final del mismo. Lo que hace es concatenar cadenas para armar la ruta hasta el archivo hosts. Luego le asigna el valor 2 a los atributos del mismo, lo que significa que será un archivo oculto. Y luego utiliza una función para abrir un archivo "hists", el cual, al no existir, es creado en la misma carpeta que hosts, como se puede ver a continuación:
Si ahora se analiza el segundo script, just_do_iti.vbs, veremos que este sí escribe un archivo nuevo a disco, en la carpeta "Archivos Temporales de Internet". El código del mismo es mucho más corto y no se encuentra ofuscado, y lo que hace es solicitar una página web, mediante un GET, a un servidor cuya dirección está en el mismo script. Así, si se analiza una captura de tráfico al momento de ejecutarse el script, aparece lo siguiente:
Observamos que se envía una solicitud de información a un determinado servidor, y que se obtiene como respuesta un "ok", además de una cookie de sesión y otras variables. También notamos que la comunicación en el servidor es hacia el puerto 1212, el cual no es un puerto común para una solicitud http que usualmente usa 80. Por último, debemos mencionar que el servidor al cual se redirigen las direcciones incluidas en el archivo hosts y este servidor con el que se comunica el script son dos servidores distintos. Es probable que este servidor sea utilizado para almacenar los nombres de usuario y contraseña robados.
Por último, analizaremos cómo es la experiencia al tratar de acceder a los sitios que han sido redirigidos al servidor falso. Para empezar, vemos que al hacer ping a dos sitios distintos, se resuelve la misma dirección, la del servidor malicioso.
Luego, si accedemos a uno de los sitios afectados, no notamos cambios con respecto al original, excepto por ciertos detalles. En primer lugar, la opción de cambiar de idioma no funciona, mientras que en el sitio original sí. En segundo lugar, y quizás más importante, si en la barra de direcciones de la máquina infectada escribimos la dirección del sitio con https en lugar de http, veremos que obtenemos la misma página, sin información de certificado:
Por su parte, si hacemos lo mismo en una computadora no infectada, accederemos a la versión https del sitio sin problemas. Esto lo podemos observar en la siguiente imagen, donde se muestra el sitio:
Del análisis de este caso hemos obtenido muchas oportunidades para aplicar técnicas de análisis de malware. Nuevamente, se puede notar la simpleza con que se ha programado la amenaza, y sin embargo su efectividad es bastante alta al momento de infectar al usuario y realizar el ataque de pharming local. Por eso, desde ESET recomendamos siempre la utilización de una solución de seguridad para poder prevenir este tipo de ataques y evitar un inminente robo de credenciales.
Matías Porolli
Especialista de Awareness & Research
