Vamos a analizar varias características recientes que hemos detectado dentro de la labor continua de análisis que realizamos en el Laboratorio de Hispasec. Desde hace cosa de un mes venimos detectando ciertos cambios en el comportamiento de Dyre que, entre otros indicadores, nos muestra que es una familia que ha venido para darnos trabajo.

Dyre comenzó sus andadas orientándose a países de habla anglo-sajona, principalmente Estados Unidos, Reino Unido y Australia. Poco a poco, y debido a su éxito han ido expandiéndose por distintas localizaciones repartidas por todo el mapa como Alemania, Austria, Suiza, Hungría, Luxenburgo, Francia, Rumanía, Emiratos Árabes Unidos, Colombia y un largo etcétera, dentro del que, desafortunadamente, también se encuentran varias entidades de panorama financiero español.

Entre otras técnicas, Dyre utiliza la funcionalidad, ya «casi-por-defecto«, de inyección de código en el navegador(aka «Man in the Browser«) que cualquier malware bancario que se precie a día de hoy ha de incluir de base. Los creadores de malware, al desarrollar dicha funcionalidad han de estudiar el funcionamiento interno de cada navegador para, cuales cirujanos del ensamblador, inyectarse dentro de las rutinas de conexión a Internet. De esta manera pueden modificar el código fuente de la página de las entidades afectadas y permitirles evadir medidas de seguridad tanto del navegador como de la entidad financiera.

Como cabe esperar, entre los navegadores afectados nos encontraremos a aquellos que más «share» poseen en la parrilla de Internet. Empezando por Chrome, siguiendo con Firefox y, por supuesto, Internet Explorer. Sin embargo, los últimos movimientos sobre la nueva versión de Windows obligan a los creadores de malware a añadir una nueva víctima a la lista: Microsoft Edge. Edge entrará sí o sí en un buen porcentaje de hogares desplazando al viejo conocido Internet Explorer y, por ende, será utilizado para acceder a la banca online de muchas familias y empresas. Dyre no se escapa de esta tendencia.

Una de las diferencias que podemos observar dentro de Dyre con respecto a lo que habitualmente se veía en las principales familias de malware bancario, se encuentra en la rutina de inyección de código HTML/JS.Mientras lo normal era descargar las instrucciones para modificar la página web en el navegador de la víctima, Dyre envía la página web al completo a sus servidores para que éstos le devuelvan la misma web una vez ya inyectada tal y como se debe mostrar en el navegador.

En el siguiente fragmento podemos ver la configuración (censurada) descargada por Dyre. Esta configuración está conformada por patrones que son comparados con las URLs visitadas por la máquina infectada. En caso de producirse una coincidencia, Dyre enviará al servidor correspondiente la página enviada desde los servidores originales, devolviéndose el código HTML con las inyecciones pertinentes.

<rpci>
 *.com/pub/html/login.html*
 X.X.X.X/redirect.php
</rpci>
<rpci>
 www.paypal.com/myaccount/
 Y.Y.Y.Y:443/account/7
</rpci>
<rpci>
 *www.ZZ.fi*
 P.P.P.P/redirect.php
</rpci>

Dentro de la labor del departamento Antifraude de Hispasec se encuentra la labor de monitorización de tales infraestructuras para detectar su caída o su reactivación para proceder de nuevo a su cierre. Es aquí donde también hemos detectado novedades en su funcionamiento con el objetivo de dificultar las tareas de vigilancia de los laboratorios.

Hasta ahora lo normal venía siendo una respuesta 200 del servidor al realizar una petición a una URL del tipo «X.X.X.X/redirect.php» para obtener el código HTML inyectado. Sin  embargo, la última actualización de los servidores de la familia han pasado a devolver una respuesta 200 solo y exclusivamente cuando interesa realizar una inyección. Indicando un error 404 en caso contrario, lo que incluye peticiones de inyección de elementos web que no interesa modificar, tales como imágenes, hojas de estilo, etc. o peticiones «extrañas» hacia el servidor. ¿Y qué puede entenderse por una petición extraña? Pues las visitas realizadas con parámetros incorrectos o a través de un método no esperado (p.ej.: GET) como la visita que posiblemente realice un administrador de sistemas al que se le haya notificado alguna anomalía en su servidor.

Vemos como peticiones sucesivas al mismo recurso, con distinto contenido, devuelven códigos de error diferentes.

Javier Rascón Mesa