Heloag no tiene amigos, sólo tiene un amo

José Nazario de Arbor Networks publicó un análisis de Trojan.Heloag en su blog hace poco, donde mencionaba que es posible que parte de su comportamiento se deba a su funcionalidad Peer-to-Peer de comando y control. Pero el análisis de José era sólo dinámico, y cuando lo contacté admitió que no estaba seguro de los resultados. Como me interesan las redes zombi Peer-to-Peer (ej. Stormfucker: Adueñándose de la red zombi Storm [Video MP4]), necesitaba analizar el tema con mayor profundidad.

Los binarios de Heloag que analicé (6ede527bb5aa65eae8049ac955b1018d que dejó d9b14a7bc0334458d99e666e553f0ee0) ¡no tenían ninguna funcionalidad Peer-to-Peer de comando y control! El programa en realidad utiliza un simple protocolo TCP que permite dictar las siguientes órdenes (codificadas como el primer byte del paquete):

• Lanzar ataques DDoS a otro servidor empleando diferentes técnicas:
  • TCP DDoS, connect(..)based (no envía datos)
  • UDP DDoS, sendto(..)based (envía algunos datos al azar)
  • HTTP DDoS requesting / with User-Agent “helloAgent”, InternetOpenUrlA based
  • HTTP DDoS crawling links from / with User-Agent “Google page”
• Descargar y ejecutar un URL de hasta 0xA4 bytes, URL “zero-padded”
• Enviar el nombre actual del ordenador
• Detener el comando DDoS que se está ejecutando
• Desconectar del servidor corriente y conectar al nuevo servidor de comando y control (C&C)

Desmontar para la función 4

Esto significa que aunque durante el análisis dinámico se detectaron muchos servidores C&C, es sólo una especie de traspaso a otros servidores que se pueden utilizar para balancear cargas o alquilar los programas robot. Como el programa robot sólo puede estar conectado a un servidor a la vez, esto no aumenta mucho la resistencia a los ataques para desmontarlo (¡fiuf!).

Aún así, este es un ejemplar interesante en cuestiones de autoría del programa malicioso. Lo que salta a la vista es que hay sólo un byte de control para la mayoría de los comandos, pero todos los comandos DDoS están codificados en el mismo byte. El ataque adicional de estos comandos controla qué DDoS se lanza y dónde. En vez de usar bytes de control de un solo tipo de bytes, el código utiliza diferentes bytes booleanos en el ataque para controlar los tipos de DDoS. Además, el código DDoS relacionado utiliza mucho C++ std::string mientras que el resto del código principal emplea wsprintf para manejar las secuencias. Es claro que dos personas trabajaron juntas en este proyecto, o por lo menos que una compró parte de la fuente a la otra.

Es muy posible que este programa malicioso provenga de China. Primero, porque el uso de wsprintf indica que se presta atención a los caracteres que no son occidentales, algo que, por supuesto, es raro ver en los programas maliciosos de origen occidental. Además, hay una dirección IP china incrustada en el código binario, que el DDoS no puede atacar sin importar qué orden se le dé al programa robot (y esto se revisa después de la resolución DNS).