Kelihos/Hlux botnet vuelve con nuevas técnicas

Han pasado cuatro meses desde que Microsoft y Kaspersky Lab anunciaran la neutralización de Kelihos/Hlux botnet El metodo de drenaje que se uso tiene sus ventajas: es posible desactivar una red zombi con relativa rapidez sin tener que controlar la infraestructura. Sin embargo, como se vio en este caso en particular, no resulta muy efectivo si los dueños de la red zombi siguen en libertad.

Poco despues del desmantelamiento de Kehilos/Hlux, encontramos nuevas muestras muy similares a la version inicial. Despues de investigar el asunto, identificamos todas las diferencias entre ambas versiones. Este es un resumen de dicha investigación:

Comencemos con el nivel inferior, la calificación y empaquetado de los mensajes Kelihos/Hlux en el protocolo de comunicación. Por alguna razón, en la nueva versión, cambió el orden de las operaciones. Estos son los pasos del procesamiento de datos codificados para recuperar un mensaje de trabajo que esta organizado en una estructura de árbol:

Para codificar un mensaje, todas las operaciones deben realizarse en orden inverso. Sabemos que las cadenas de símbolos se comprimen mejor que los datos en simple formato binario. El arbol inicial incluye muchas cadenas como mensajes de correo, plantillas de spam, etc. Por lo tanto no tiene sentido usar la compresión zlib después de codificar un árbol en la nueva versión de Hlux/Kelihos: el tamaño del paquete aumenta pero sin ninguna ventaja. Parece ser que alguien obtuvo el código fuente de la red zombi y quiso que los futuros robots sean diferentes, cambiando el orden de las etapas de codificación.

En segundo lugar, cambiaron las llaves de codificación, lo cual era previsible. Tambien se cambiaron las llaves RSA que se usan para firmar las partes de un arbol con los IPs de los controladores y actualizar las URLs y las correspondientes llaves públicas RSA en los robots.

Como podemos ver, dentro de un árbol se usan dos llaves RSA diferentes lo que nos lleva a pensar que probablemente hay dos grupos diferentes que poseen cada una de las llaves y tienen el control de la red zombi.

En cuanto a la estructura de arbol, todos los campos y sus significados permanecen iguales. El cambio mas significativo es que ya no se usa el algoritmo hashing para los nombres de los campos. En su lugar, ahora a cada campo le corresponde un nombre de 1-2 simbolos.

Esta era una estructura de árbol del antiguo Hlux después de descodificar un paquete:

Esta es una estructura de árbol del nuevo Hlux:

Otra innovación de la nueva versión de Hlux consiste en un enfoque mas preciso en la formación de paquetes: ahora, cada paquete (de entrada y de salida) incluye la suma de control calculada de los datos en su encabezamiento.

Nuestra investigación revelo que la nueva versión apareció el 28 de septiembre, justo después de que Microsoft y Kaspersky Lab anunciaran la neutralización de la red zombi original de Hlux/Kelihos.
La lista de controladores en la nueva versión no tuvo casi ninguna modificación y fue cambiando poco a poco con el tiempo.

Esta red zombi sigue recibiendo ordenes de los spammers y sigue enviando spam en varios idiomas:

A continuación presentamos las principales conclusiones:

1. Es imposible neutralizar una red zombi controlando las maquinas controladoras o remplazando la lista de controladores sin realizar ninguna otra acción. El dueño de la red zombi puede conocer la lista de IPs routers activos, y puede conectarse directamente con ellos y volver a forzar la actualización del robot junto a la nueva lista de controladores.
2. Es posible neutralizar la red zombi mediante un drenaje pero recurriendo a tecnicas un poco diferentes a las que se usaron.
3. Es posible introducir una herramienta de actualización en los equipos infectados para neutralizar la red zombi. En este caso, el dueno de la red tiene que volver a infectar los equipos para construir otra red.
4. Creemos que el metodo mas efectivo para desactivar una red zombi es la identificación de quienes la controlan. Esperemos que Microsoft siga con su investigación hasta el final.

P.D. Nuestro agradecimiento a Alexey Borzenkov y Tillman Werner por brindarnos los detalles tecnicos.