Big Brother

Parece que el desarrollo del módulo principal de SpyEyed se detuvo con la versión 1.3.48 lanzada en otoño, y esta es ahora la tendencia dominante de los programas maliciosos SpyEye.

Clasificación de SpyEye por versiones a partir del 1 de enero de 2012*
* Otros (7%) incluye: 1.2.50, 1.2.58, 1.2.71, 1.2.80, 1.2.82, 1.2.93, 1.3.5, 1.3.9, 1.3.25, 1.3.26, 1.3.30, 1.3.32, 1.3.37, 1.3.41, 1.3.44.

Pero el que los autores no sigan desarrollando esta plataforma no significa que SpyEye no siga adquiriendo nuevas funciones. El código central permite a cualquiera crear y adjuntar sus propios plugins (bibliotecas DLL). He estado analizando muestras de SpyEye desde principios de este año, y he contado 35 diferentes plugins. A continuación se puede ver una tabla con esos plugins y el correspondiente número de muestras en los que se encontraban:

Hace poco identifiqué un nuevo plugin por primera vez: flascamcontrol.dll. Su nombre me intrigó y me fijé para descubrir lo que hace. Resulta que se usa para controlar la cámara incorporada en un ordenador infectado. Este plugin tiene un archivo de configuración y una lista de nombres de sitios de bancos alemanes. La biblioteca flashcamcontrol.dll ajusta las autorizaciones de FlashPlayer, permitiendo que los documentos flash descargados desde determinados sitios en la lista de configuración usen la cámara incorporada y el micrófono sin que el usuario se entere de ello, tal como se muestra a continuación:

Así es como lo hace DLL. Usando el camino de configuraciones de FlashPlayer:

busca carpetas relacionadas con el banco por máscara “#“, y parcha el archivo “settings.sol” en esa carpeta:

activando las opciones “autorizar siempre” para la cámara incorporada y el micrófono.
Eso es todo lo que hace esta biblioteca. Obviamente, esto es sólo una parte del gran plan, pues hay mucho más. Descubrí algo más en la configuración de otro plugin SpyEye llamado webfakes.dll, en el que se especifican las siguientes reglas:

Si un usuario infectado visita el sitio de un determinado banco y el navegador que procesa la página solicita un documento flash vía un enlace desde la primera columna, el plugin webfakes.dll (que se ejecuta en un contexto del navegador) detecta la petición y la remplaza con una dirección de la segunda columna (esta dirección está controlada por los hackers). En consecuencia, el navegador cargará un documento malicioso desde el servidor del hacker (statistiktop.com) en lugar de un documento flash desde el sitio del banco.

Aquí, supuse que los bancos estaban usando las cámaras incorporadas en los ordenadores para ayudar a confirmar la identidad de sus clientes online, y que los ciberdelincuentes pretendían evitar esta nueva medida de seguridad. Mi primera suposición fue el reconocimiento facial. Esta idea ha estado dando vueltas por ahí durante bastante tiempo: durante el registro o inscripción, se le toma una fotografía al cliente, se guardan los parámetros biométricos en el servidor y cada vez que el usuario ingresa, una foto actualizada tomada por la cámara incorporada se compara con los parámetros archivados.

Sin embargo, aunque algunas organizaciones han desarrollado este método y lo han puesto en práctica, no es muy usado por los servicios de banca online. Nos pusimos en contacto con los bancos que estaban en la lista de los plugins de EyeSpy, y nos confirmaron que ninguno usa este método para identificar a sus clientes.

Además, los enlaces de webfake para descargar documentos flash desde los sitios de los bancos no funcionarían, porque el sitio no contiene este tipo de documentos. Pero sí existen los documentos falsos vinculados desde la segunda columna (es decir, en el servidor del hacker). Resultó que ambos documentos flash sólo crean una ventana con una imagen de la cámara. Uno de ellos envía un video stream al servidor del hacker:

El otro interviene si la lente de la cámara está cerrada. Alerta al usuario sobre un aparente problema y le aconseja (en ruso) que seleccione otra cámara. Ese documento, Camera_test.swf, se ha detectado en varios sitios diferentes. Entonces, puede tratarse de una conocida plantilla de prueba para usar Flash para controlar una cámara incorporada en el ordenador:

“¿No ves nada? Intenta seleccionar otra cámara de la lista”.

Esta no es la primera vez que los ciberdelincuentes que usan bancos online tratan de obtener secuencias de video y de voz de sus víctimas. Mi colega Dmitry Bestuzhev recuerda un caso en que un programa malicioso dirigido a clientes de un banco en Ecuador también tenía la función de grabar secuencias de video y voz en el ordenador infectado y enviarlas a los hackers. Esto tampoco tenía que ver con el reconocimiento óptico del cliente; el banco ecuatoriano no tenía implementada esta función.

De donde se desprende la pregunta: ¿Para qué filmar a la víctima? Por lo visto, los ciberdelincuentes miran la reacción del usuario cuando se está produciendo el robo. Como siempre, roban el dinero de la siguiente manera: el usuario ingresa sus datos en el sitio del banco, pero el programa malicioso ha modificado el código de la página directamente en el navegador, y después de la autorización, el usuario no ve la cuenta del banco sino que el programa malicioso crea una ventana que dice, por ejemplo, “Cargando…” Por favor espere…”. Al mismo tiempo, el código malicioso inyectado se prepara para enviar el dinero robado a la cuenta bancaria de un cómplice. Una vez hecho esto, y para confirmar la transacción, los ciberdelincuentes tienen que persuadir al usuario para que ingrese un código secreto, que se lo envían mediante un SMS. Aquí entra la ingeniería social: el programa del hacker pone una petición en la pantalla de la víctima, por ejemplo: “Estamos fortaleciendo nuestras medidas de seguridad. Por favor confirme su identidad ingresando el código secreto que hemos enviado a su teléfono”.

Este es el momento que les importa a los hackers: ¿cómo reaccionará el usuario ante el pedido inesperado de un código SMS? En el caso ecuatoriano, como explicaba Dmitry Bestuzhev, cuando un usuario solicita una transacción, es posible que el banco lo llame para confirmar el código secreto. Mediante el micrófono, el ciberdelincuente puede escuchar, y después puede llamar al banco, haciéndose pasar por el cliente cuyo código ha escuchado. Con este código es posible actualizar los detalles telefónicos y de ingreso para tomar el control total de la cuenta de la víctima.

Volvamos al esquema que usa EyeSpy. Como descubrimos, en los sitios bancarios no hay documentos flash para las cámaras. Entonces, ¿por qué tendría que solicitar estos documentos el navegador? Tiene que ver con otro mecanismo fundamental de SpyEye: inyecciones desde la web. Cuando un usuario visita un sitio donde la sección de inyección desde la web tiene su reglas listas para aplicar, SpyEye sigue estas reglas e inyecta un código maliciosos en el código original de ese sitio recien descargado. En este caso, se inserta un fragmento malicioso en el código de ciertas páginas del sitio del banco y ese fragmento supuestamente se vincula al hosting de documentos flash del banco.

Es así como funciona todo esto. Desde la conexión inicial al sitio hasta el ciberdelincuente que mira secuencias de video desde la cámara incrustada en el ordenador del usuario:

Y aquí vemos cómo los ciberpiratas no sólo se llevan nuestro dinero, sino también nuestras emociones.