Descripciones de malware

Ice IX: nada del otro mundo

Mi colega Jorge Mieres encontró hace poco un servidor C&C de una botnet perteneciente a un programa malicioso llamado Ice IX. Como se anunció en varios foros de usuarios, Ice IX es un bot creado usando el código fuente de ZeuS 2.0.8.9, que se puso a disposición del público en mayo. El autor del nuevo bot dijo que el programa incluye mejoras substanciales, lo que debe interesar mucho a aquellos cibercriminales que roban dinero a los usuarios con la ayuda de troyanos bancarios.


Figura 1. Descripción del bot

Como pueden ver en la captura de pantalla, la descripción del nuevo programa se concentra en las mejoras que supuestamente se introdujeron al código original de ZeuS. Estas incluyen burlar los cortafuegos, evadir la protección proactiva de los programas de seguridad y evitar la detección de los trackers. Es obvio que la última se refiere a Zeus Tracker https://zeustracker.abuse.ch, que ha estado complicando la vida de los cibercriminales. El autor del programa cobraba 600 $ por cada versión del bot con una URL que no es modificable, a la que el bot debía conectarse después de la infección (la dirección C&C), y 1.800 $ por una versión sin una dirección C&C hardcoded.

Por desgracia, no pudimos conseguir ninguna muestra de la versión mejorada de Ice IX, tal vez porque nadie la había comprado. Lo más probable es que esta versión incluya un mecanismo similar al que implementaba ZeuS al principio, con su versión 2.1. Así es como funcionaba en ZeuS: el bot incluía una llave que se utilizaba en combinación con la fecha actual para generar 1.020 nombres de dominio a diario. El bot buscaba en esta lista para encontrar su servidor C&C.

Pero también parece que alguien ha probado la versión base del paquete del bot. Analizamos estas muestras para encontrar diferencias con las muestras de ZeuS originales que se usaron como base para el bot Ice IX.

Debo confesar que esperaba más. El autor publicitó el programa como si fuese algo especial, y había un comentario que decía que el autor debía obtener crédito por evadir las protecciones proactivas porque era una mejora muy importante, y llegaba a la conclusión de que este sin duda era un nuevo bot superior a ZeuS…, pero, de hecho, eran un montón de mentiras. No hay mejoras importantes en comparación con ZeuS 2.0.8.9, la versión que se puso a disposición del público.

Estas son las diferencias que encontré:

1) Zeus puede encontrar las credenciales de correo electrónico que se guardan en el sistema infectado. El bot envía todos los datos que encuentra al operador de la botnet, dándole acceso a la cuenta de correos de la víctima. Sin embargo, la sección del código responsable de encontrar y procesar las credenciales de correo electrónico no tiene comentarios en el código fuente de ZeuS. El autor de Ice IX simplemente eliminó las marcas de comentarios de este código, así que los módulos que no estaban incluidos en ZeuS 2.0.8.9 estaban presentes en su bot.

2) El bot ZeuS 2.0.8.9 puede ejecutarse con los siguientes argumentos: -f, -n, -v, -i. No voy a comenzar a explicar lo que significa cada uno de ellos. Pero quisiera mencionar la llave –i: si la muestra de ZeuS 2.0.8.9 se ejecuta con esta llave, se muestra una ventana con información sobre el bot:


Figura 2. Ventana de información de ZeuS 2.0.8.9

El autor de Ice IX simplemente eliminó el fragmento que procesa esta llave del código. Por ende, el ejemplar Ice IX no acepta este argumento.

3) Se ha identificado una función modificada asociada con la lectura de datos del registro. Hay una pequeña probabilidad de que esto pruebe que se implementaron “mejoras” para evadir la protección proactiva de los productos de seguridad. Pero también podría ser solo una consecuencia de una optimización del compilador, el resultado de compilar el código del bot puede haber sido un poco diferente al del código original de ZeuS por los cambios que se introdujeron a Ice IX, por pequeños que fueran. En el código de ZeuS 2.0.8.9, la función que lee datos del registro incluye todas las funciones API requeridas para esta tarea, es decir, RegOpenKeyEx, RegQueryValueEx and RegCloseKey:


Figura 3. La función en ZeuS que lee los datos del registro

Cuando se necesitaba leer un valor del registro, se hacía de la siguiente manera:


Figura 3a. Llamando a la función que lee del registro en ZeuS

En el ejemplar Ice IX, hay algunos cambios en los lugares en los que se llama la función. La función API RegOpenKeyEx se eliminó de la función que lee datos del registro:


Figura 4. La función en ZeuS que lee datos del registro

Como resultado, cuando se necesitaba leer un valor del registro, se llamaba primero a la función API RegOpenKeyEx para abrir la llave del registro (es decir, HKEY_CURRENT_USER o HKEY_LOCAL_MACHINE) antes de llamar a la verdadera función de lectura del registro:


Figura 4a. Llamando a la función para leer desde el registro en Ice IX

Debo admitir que algunos productos antivirus podrían detectar ZeuS basándose en la presencia de la función de lectura del registro de arriba. Es posible que esta función esencial esté presente en todos los ejemplares de ZeuS sin importar su versión; también es posible que su código identifique de forma única esta familia de malware entera. ¿Por qué no? En este caso, modificar esta función (p. ej., eliminar RegOpenKeyEx) ayudaría a prevenir la detección que depende de ella.

No probé todos los productos antivirus en ejemplares de Ice IX, así que no puedo decir si algún producto dejaría de detectarlo a causa de este cambio. Sólo escaneé la muestra con KIS 2012 utilizando bases de datos antivirus de junio, cuando todavía no se sabía nada de Ice IX. Como el bot se estaba ejecutando, KIS 2012 detectó actividad peligrosa y bloqueó la ejecución del programa. No es ninguna sorpresa: tomando en cuenta la larga historia y extensa funcionalidad de ZeuS, hay bastante información que ayuda a KIS y KAV a detectar el código malicioso de esta familia de malware.

Ahora pasemos a los cambios más significativos que distinguen a Ice IX de Zeus 2.0.8.9, al menos hasta cierto punto.

3) El archivo de configuración de ZeuS contiene una sección llamada “Filtros Web”, en la que el operador de la botnet define cómo debe responder el bot cuando el usuario visita ciertos sitios web. Esto se hace usando los caracteres especiales “!”, “@”, “-“, “^”.

Veamos cómo se utiliza el carácter “@”. Se coloca antes de la URL (p. ej., @*/login.osmp.ru/*) para ordenarle al bot que tome capturas de pantalla cuando el usuario visite cualquier dirección especificada y pulse en el botón izquierdo del ratón, y envíe las imágenes al cibercriminal. Este mecanismo permite al cibercriminal reconstruir los datos que el usuario ingresa en el sitio web usando el teclado virtual. Otros símbolos también definen acciones específicas que el bot debe realizar. Todo lo que hizo el autor de Ice IX fue asignar diferentes caracteres a las mismas funciones: las letras “N”, “S”, “C” y “B” reemplazaron a “!”, “@”, “-“ y “^”, respectivamente.

4) La última característica distintiva es un método ligeramente modificado que el bot utiliza para descargar el archivo de configuración. En su código, ZeuS incluye una URL “hard-coded” de un archivo de configuración que cualquier persona puede descargar, p.ej., http://www.example.com/files/config.bin. El autor de Ice IX da a entender que el hecho de que sea tan fácil acceder a los archivos de configuración es el mayor problema con los trackers. ¿Cómo solucionan este problema? Esto es lo que hacen. Ya no puedes descargar el archivo de configuración desde la URL. En vez de eso, debes enviar una solicitud POST especial a cierta dirección (que en realidad es una URL hardcoded en el bot en la misma ubicación que en ZeuS 2.0.8.9). La solicitud debe incluir un par de parámetros: “id=&hash=”, por ejemplo:

id=TEST_WIN_XP_B5DF77116522DF69&hash=DC0D2CAB39D49FC3D5E467501A2682C5

id es el identificador del bot que se calcula con el mismo algoritmo que en ZeuS 2.0.8.9. Se utiliza para las comunicaciones directas del bot con el C&C.

El identificador es el nombre del ordenador con un número hexadecimal único de 16 dígitos agregado. Desde el punto de vista del C&C, tanto el nombre del ordenador como el número de 16 dígitos puede ser arbitrario. Este identificador se codifica con el algoritmo RC4 (que ZeuS utiliza todo el tiempo para codificar datos) en combinación con una S-box que también está hardcoded en el bot. Se calcula el MD5 checksum para los datos codificados y se envía como una variable hash. Como el identificador del bot puede ser arbitrario (como máximo necesita cumplir con el formato COMPUTERNAME_16CHARSHEXNUMBER), el único dato necesario para obtener el archivo de configuración es el S-box, que se necesita para codificar el identificador del bot. Pero…, un momento. El archivo de configuración también está codificado usando el mismo algoritmo RC4 con el mismo S-box. El archivo de configuración sin el S-box es una secuencia de bytes inútil y sin sentido. Lo valioso está dentro del archivo.

Así que a fin de cuentas todo consiste en esto:

Bot Lo que se necesita para obtener datos útiles del archivo de configuración
Ice IX S-box
ZeuS S-box

La cuestión es: ¿qué se supone que complica la vida de los trackers? Y la respuesta obvia es “prácticamente nada”. Puede que tome una media hora más ejecutar una muestra, hacer una entrega e identificar los cambios realizados a un código conocido. Y eso es sólo si uno va a hacer el análisis y descargas masivas de los archivos de configuración de diferentes bots. Pero hay una forma más fácil: obteniendo los parámetros de la solicitud POST del tráfico del ordenador infectado, que sólo toma unos minutos. ¡Después de tanto bombo, no lo esperaba!

Hay un dicho sobre deportes que se puede aplicar a esta situación: un atleta debe dar un salto de 9 metros para ganar las Olimpiadas, no 9 atletas dar saltos de 1 metro. Aquí es lo mismo: no interesa cuántas veces y cuántos valores estén codificados utilizando el mismo algoritmo y la misma llave; más iteraciones de codificación no forman un algoritmo de codificación mucho más fuerte con los mismos datos fuente. Pero parece que esto no es lo que el cibercriminal estaba buscando, y la simple realidad es que su negocio entero es un fraude. Alguien decidió que quería ganar dinero fácil vendiendo malware supuestamente mejorado con funcionalidades que ya están disponibles al público.

Ice IX: nada del otro mundo

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

 

Informes

MosaicRegressor: acechando en las sombras de UEFI

Encontramos una imagen de firmware de la UEFI infectada con un implante malicioso, es el objeto de esta investigación. Hasta donde sabemos, este es el segundo caso conocido en que se ha detectado un firmware malicioso de la UEFI usado por un actor de amenazas.

Dark Tequila Añejo

Dark Tequila es una compleja campaña maliciosa que tiene por objetivo a los usuarios ubicados en México, con el propósito principal de robar información financiera, así como credenciales de acceso a sitios populares que van desde versionado de código fuente a cuentas de almacenamiento de archivos en línea y de registro de dominios web.

De Shamoon a StoneDrill

A partir de noviembre de 2016, Kaspersky Lab observó una nueva ola de ataques de wipers dirigidos a múltiples objetivos en el Medio Oriente. El programa malicioso utilizado en los nuevos ataques era una variante del conocido Shamoon, un gusano que tenía como objetivo a Saudi Aramco y Rasgas en 2012.

Suscríbete a nuestros correos electrónicos semanales

Las investigaciones más recientes en tu bandeja de entrada