La exitosa historia del cierre de una red zombi: Cómo Kaspersky Lab logró desactivar la red zombi Hlux/Kelihos

A principios de esta semana, Microsoft publicó una nota sobre la desactivación de una peligrosa red zombi (botnet) que fue responsable de envíos de spam, robo de información financiera confidencial, fraudes bursátiles del tipo inflar y tirar, y de sitios web que promocionaban la explotación sexual infantil.
Kaspersky Lab tuvo un rol fundamental en la clausura de esta red criminal, habiendo encabezado las acciones para aplicar ingeniería reversa al programa malicioso de la red, decodificado su protocolo de comunicación y desarrollado las herramientas para atacar esta infraestructura de tipo peer-to-peer. Trabajamos estrechamente con la unidad de delitos criminales de Microsoft (DCU, por sus siglas en inglés), compartimos la información relevante y les permitimos el acceso a nuestro sistema de rastreo de redes zombi en tiempo real.

Un aspecto clave de esta tarea fue el socavamiento (sinkholing) de la red mediante la técnica que consiste en desviar el tráfico destinado al servidor malicioso hacia el servidor de los analistas. Es importante comprender que la red aún existe, pero está bajo el control de Kaspersky Lab. El socavamiento de la red se hizo paralelamente a la iniciativa de Microsoft de recurrir a la corte de los EE.UU. para desactivar los dominios. En este momento tenemos 3.000 ordenadores host que se conectan a nuestro sinkhole cada minuto. Esta entrada describe el funcionamiento interno de la red zombi y el trabajo que realizamos para suspender sus operaciones.

Comencemos con algunos antecedentes técnicos: Kelihos es el nombre de Microsoft para lo que Kaspersky denomina Hlux. Hlux es una red zombi peer-to-peer con una arquitectura similar a la usada en la red zombi Waledac. Consiste en capas de diferentes tipos de nodos: controladores, routers y trabajadores. Los controladores son máquinas supuestamente operadas por los delincuentes que manejan la red zombi. Envían instrucciones a los bots y supervisan la estructura dinámica peer-to-peer de la red. Los routers son máquinas infectadas con direcciones IP públicas. Dirigen el bot en modo de router, alojan servicios proxy, participan en un colectivo fast-flux, y otras acciones. Por último, los trabajadores son, en pocas palabras, máquinas infectadas que no se ejecutan en modo de router. Se usan para enviar spam, recopilar direcciones de correo, husmear los credenciales de los usuarios desde el flujo de la red, etc. A continuación mostramos un esquema de la arquitectura en capas, con un nivel superior de cuatro controladores y nodos de trabajadores (en verde).

Figura 1: Arquitectura de la red zombi Hlux

Nodos de trabajadores

Muchos ordenadores que pueden infectarse con programas maliciosos no tienen una conexión directa con Internet. Están escondidos detrás de pasarelas, proxis u otros dispositivos que realizan la traducción de direcciones de la red. En consecuencia, no se puede acceder a estos ordenadores desde el exterior, a menos que se recurra a medidas técnicas especiales. Este es un problema para los bots que organizan equipos infectados en las redes peer-to-peer, ya que son necesarios servicios de hosting a los que otros equipos puedan acceder. Por otra parte, estos ordenadores proporcionan gran potencia de computación y ancho de banda de red. Un ordenador que ejecuta el bot Hlux verificará si es accesible desde el exterior, y si no lo es, funcionará en modo de trabajador. Los trabajadores mantienen una lista de peers (otros equipos infectados con direcciones IP públicas) a los quw solicita realizar algunas tareas. Una tarea puede incluir instrucciones para enviar spam, o participar en ataques de denegación de servicio. También puede ordenar al bot que descargue una actualización y se reemplace por la nueva versión.

Nodos de routers

Los routers forman la columna vertebral de las capas en la red zombi Hlux. Cada router mantiene una lista de peers con información sobre otros peers, tal como sucede en el caso de los nodos de trabajadores. Al mismo tiempo, cada router funciona como un proxy HTTP que canaliza las conexiones entrantes hacia uno de los Controladores. Los routers también pueden realizar algunas tareas, pero su función específica es la de proveer la capa proxy delante de los controladores.

Controladores

Los nodos de controladores son la capa superior visible de la red zombi. Los controladores alojan un servidor nginx HTTP y atienden los mensajes de tareas. No participan en la red peer-to-peer, por lo que nunca aparecen en las listas de peers. Suelen ser seis, distribuidos en pares en diferentes rangos de IP, en varios países. Las dos direcciones IP de un par comparten una llave SSH RSA, de manera que es posible que en realidad haya una sola casilla detrás de cada par de direcciones. De vez en cuando, algunos controladores se reemplazan por otros nuevos. Justo antes de que se neutralizara la red zombi, la lista contenía los siguientes registros:

193.105.134.189
193.105.134.190
195.88.191.55
195.88.191.57
89.46.251.158
89.46.251.160

La red peer-to-peer

Cada bot guarda unos 500 registros de peers en una lista local de peers. La lista se guarda en el registro de Windows bajo el nombre de HKEY_CURRENT_USERSoftwareGoogle junto a otros detalles de la configuración. Cuando un bot funciona por primera vez en un equipo infectado, inicializa su lista de peers con algunas direcciones tipo hard-code incluidas en el ejecutable. La última versión del bot tenía un total de 176 registros. La lista local de peers se actualiza con la información de peers recibida de otros ordenadores host. Cuando un bot se conecta al nodo de routers, envía hasta 250 registros desde su actual lista de peers, y el peer remoto responde con 250 de sus propios registros. Al intercambiar listas de peers, las direcciones de los nodos de routers en actividad se propagan a través de la red zombi. Un registro de peers contiene la información que se muestra en el siguiente ejemplo:

m_ip: 41.212.81.2
m_live_time: 22639 seconds
m_last_active_time: 2011-09-08 11:24:26 GMT
m_listening_port: 80
m_client_id: cbd47c00-f240-4c2b-9131-ceea5f4b7f67

La arquitectura peer-to-peer implementada por Hlux tiene la ventaja de ser muy resistente contra los intentos de neutralización. Su estructura dinámica le permite rápidas reacciones cuando se detectan irregularidades. Cuando un bot quiere asignar tareas, nunca se conecta directamente con un controlador, aunque esté en modo de trabajador o de router. Las asignaciones de tareas siempre se envían a través de otro nodo de routers. Entonces, aunque todos los nodos de controladores estén fuera de línea, la capa peer-to-peer permanece activa y proporciona un medio para anunciar y propagar un nuevo conjunto de controladores.

La red de servicio Fast-Flux

La red zombi Hlux también atiende a varios dominios fast-flux que están registrados en el sistema de nombres de dominios con un valor TTL de 0 para evitar su detección. La búsqueda de uno de los dominios devuelve una simple dirección IP que pertenece a un ordenador infectado. Los dominios fast-flux proporcionan un canal alternativo que pueden usar los bots para volver a acceder a la red zombi en caso de que ninguno de los peer de su lista local estuviese disponible. Cada versión de bot contiene un dominio alternativo individual tipo hard-code. Microsoft anuló el registro de estos dominios y desactivó el canal alternativo con eficacia. A continuación mostramos un juego de nombres DNS que estaban activos antes del cierre, en caso de que desee chequear su resolución de DNS. Si algún ordenador solicita más de un DNS, es posible que esté infectado con Hlux, por lo que debería someterse a una desinfección.

hellohello123.com
magdali.com
restonal.com
editial.com
gratima.com
partric.com
wargalo.com
wormetal.com
bevvyky.com
earplat.com
metapli.com

Además, la red zombi utilizaba cientos de sub-dominios de ce.ms y cz.cc que pueden registrarse gratuitamente. Pero estos sólo se usaban para distribuir actualizaciones y no como un vínculo de reserva a la red zombi.

Neutralización

Un bot capaz de formar parte de la red peer-to-peer no resolverá ninguno de los dominios alternativos; no tiene por qué hacerlo. En realidad, nuestro monitor de bots no ha registrado ni un solo intento de acceso al canal alternativo durante los siete meses que estuvo operando, ya que siempre había disponible al menos un peer.

La comunicación para los comandos de arranque y recepción utiliza un protocolo especial propio que implementa un formato estructurado de mensaje, la decodificación, compresión y serialización. El código del bot incluye un despachador de protocolos para canalizar los mensajes entrantes (mensajes de arranque, tareas, comunicación por SOCKS) hacia las funciones apropiadas mientras atiende todo en un solo puerto. Aplicamos ingeniería reversa en este protocolo y creamos algunas herramientas para decodificar el tráfico al interior de la red zombi. Al poder rastrear los mensajes de arranque y las tareas en un ordenador intencionalmente infectado pudimos ver lo que estaba sucediendo en la red zombi, cuándo se distribuían las actualizaciones, qué cambios se efectuaban en su arquitectura, e incluso saber, hasta cierto punto, cuántos equipos infectados conformaban la red zombi.

Figura 2: Peticiones por minuto en la suplantación

El lunes comenzamos a propagar una dirección especial de un peer. Muy pronto, esta dirección se convirtió en la más importante de la red zombi, logrando que los bots se comuniquen con nuestro ordenador, y sólo con él. Los expertos conocen esta acción con el nombre de suplantación o sinkholing, es decir, cuando los bots se comunican con un ordenador suplantado en vez de hacerlo con sus verdaderos centros de administraci’on. Al mismo tiempo, distribuimos una lista especialmente elaborada de servidores de tareas para reemplazar la original con las direcciones antes mencionadas, a fin de evitar que los bots realicen peticiones. A partir de este punto, la red zombi ya estaba fuera del control de sus dueños. Y puesto que ahora los bots se están comunicando con nuestro ordenador, podemos, por ejemplo, realizar una minería de datos y rastrear infecciones por país. Hasta el momento, hemos identificado 49.007 diferentes direcciones IP. Kaspersky trabaja con los proveedores del servicio de Internet para informar a los propietarios de redes sobre las infecciones.

Figura 3: Direcciones IP suplantadas por país

¿Y ahora qué?

Ahora, la pregunta principal es: ¿qué viene después? Es obvio que no podemos seguir suplantanto el centro de administración de Hlux de forma indefinida. Estas medidas son sólo una solución temporal, pero no son suficientes para resolver el problema, ya que la única solución verdadera sería desinfectar todas las máquinas infectadas. Esperamos que la cantidad de equipos afectados por la suplantación disminuya progresivamente con el tiempo a medida que se desinfecten y reinstalen. Microsoft señaló que su Centro de protección contra programas maliciosos ha añadido el bot a su Herramienta de eliminación de programas maliciosos. Dada la difusión de su herramienta, se espera un inmediato impacto en las cifras de la infección. Sin embargo, en las últimas 16 horas hemos detectado todavía 22.693 direcciones IP únicas. Esperamos que esta cantidad pronto será mucho menor.

Cabe resaltar que existe una opción teórica para acabar de una vez por todas con Hlux: sabemos cómo funciona el proceso de actualización del bot. Podríamos valernos de este conocimiento y publicar nuestra propia actualización que elimine las infecciones y se autodestruya. Sin embargo, esto sería ilegal en muchos países, por lo que sigue siendo algo teórico.

Reconocimiento

Llevar a cabo la suplantación del centro de administración de una red zombi capaz de manejar una gran cantidad de conexiones demanda recursos idóneos. Queremos agradecer a SURFnet por su colaboración en la operación, y especialmente por haber provisto una infraestructura perfecta para operar la suplantación.