Autores
Existen muchas redes zombi (bots) con los que los delincuentes organizan ataques DDoS contra los servidores ubicados en Internet. Entre estos instrumentos, uno de los más populares es el llamado Black Energy. En el presente, Kaspersky Lab ha detectado más de 4.000 variantes de este programa malicioso. A mediados de 2008 los escritores de virus introdujeron cambios sustanciales en la versión inicial del bot. Así apareció el denominado Black Energy 2 (que Kaspersky Lab clasifica como Backdoor.Win32.Blakken). Es esta versión la que analizaremos en este artículo.
Paso a paso: los componentes del bot
En este bot el autor plasmó varias tareas: hacer que los antivirus no tengan acceso al código del programa, inoculación de los procesos del sistema y, como broche de oro, un flexible mecanismo de implementación de diferentes actividades nocivas en el equipo infectado según instrucciones enviadas por el centro de administración de la botnet. Cada uno de los componentes del programa malicioso responde de la ejecución de una tarea.
La envoltura protectora
Al igual que la mayoría de los programas maliciosos, Black Energy 2 tiene una envoltura protectora que oculta el contenido malicioso de los ojos del antivirus: cifrado, compresión del código y también puede utilizar métodos antiemulación.
Cuando el fichero ejecutable de Black Energy 2 se ejecuta en el ordenador del usuario, el programa malicioso reserva memoria virtual, donde copia el código del descifrador y le entrega el mando.
Como resultado de la ejecución del código del descifrador, en la memoria aparece un código con funciones de dropper, cuya ejecución conduce a la creación de un driver-descifrador con nombre aleatorio –por ejemplo, EIBCRDZB.SYS- en el catálogo del sistema “<WINDIR>system32drivers”. Acto seguido se crea y ejecuta un servicio ligado con este driver, que también tiene un nombre al azar:
Este driver, al igual que el fichero ejecutable que inicia el proceso de infección del ordenador, es en esencia una “envoltura” que contiene cosas mucho más interesantes.
El infector
En el código del driver-descifrador hay un bloque de datos cifrados y empaquetados:
Este bloque de datos tiene una estructura determinada:
Con la ayuda de la llave de este bloque se construye otra llave de 100h bytes, que se usa para descifrar el archivo. El algoritmo de cifrado es bien conocido, se trata de RC4. Si el tamaño del archivo coincide con el tamaño de los datos, eso significa que no se han archivado los datos. En caso contrario, se descomprime el archivo descifrado.
Los datos descifrados son un driver-infector, entre cuyas funciones está la de incrustar una biblioteca dll en el proceso svchost.exe del usuario. Para ejecutar el driver-infector, el driver-descifrador le asigna memoria, donde copia el código descifrado, lo ajusta al espacio de direcciones correspondiente y le entrega el control. La biblioteca dll maliciosa se almacena en la sección “.bdata” del driver-infector. Este bloque de datos también tiene la estructura descrita más arriba. El driver-infector encuentra el proceso svchost.exe, en su espacio de direcciones se asigna memoria, a la cual se copia el dll malicioso, que a su vez se ajusta a la dirección de la memoria asignada. El código de la biblioteca incrustada se ejecuta desde el régimen de núcleo de la siguiente manera:
Aquí se usa el procesamiento de la cola APC. Primero se inicia el APC con la dirección de la función DllEntry de la biblioteca incrustada y después se pone en la cola el APC con la ayuda de KeInsertQueueApc. Cuando svchost.exe está listo para el procesamiento de la cola APC (lo que ocurre casi de inmediato), en su contexto se ejecuta un flujo desde la dirección DllEntry.
La dll incrustada
La biblioteca dll incrustada en svchost.exe es el principal eslabón de gestión para la organización de ataques DDoS desde el equipo infectado. De la misma manera que el driver-infector, la biblioteca tiene una sección .bdata que guarda el bloque de datos cifrados que tienen la estructura que ya conocemos. Estos datos son un documento xml en el que se ha definido la configuración inicial del bot. Este documento puede tener la siguiente apariencia:
La información más importante es, por supuesto, la dirección del centro de administración de la botnet. En este caso, para más seguridad, se ponen dos direcciones: si una de ellas estuviera cerrada y el bot no pudiese obtener acceso, puede probar establecer contacto con su dueño mediante la dirección adicional.
El bot envía a la dirección del centro de administración una solicitud html preparada con anticipación, que consiste de un renglón que contiene los datos de identificación del equipo infectado. He aquí el aspecto de este renglón:
El parámetro id, el identificador del equipo infectado, contiene el nombre del ordenador y el número de serie del disco duro donde está ubicado el disco C:. Más adelante se indican los datos del sistema operativo: idioma del sistema, país donde está instalado el sistema y versión del sistema. Al final se agrega el identificador de la versión del bot (último campo “build_id” en los primeros renglones del documento xml.
Un determinado tipo de renglones de búsqueda puede ser una confirmación de que nos encontramos ante un bot. Además, para el centro de administración, el uso de solicitudes html user-agent puede ser una especie de contraseña.
Si el centro de administración acepta la solicitud, enviará como respuesta un fichero de configuración del bot, también en forma de documento xml cifrado. El cifrado usado es el mismo que en el caso del cifrado de los datos del driver y la dll: RC4. El identificador del equipo infectado sirve de llave (el parámetro id del renglón de solicitud del ejemplo de más arriba “xCOMPUTERNAME_62CF4DEF”).
Ahora veamos un ejemplo de estas instrucciones:
La sección <plugins> le dice al bot cuáles son los módulos existentes en el servidor que se pueden usar para organizar ataques DDoS. Si el bot todavía no cuenta con estos módulos o en el servidor existe una versión más nueva, el bot envía una solicitud al servidor para descargar un plugin, por ejemplo:
El plugin es una biblioteca dll. Se la envía al bot cifrada. Si para el cifrado se usa una llave diferente al valor del parámetro id, se indica en el fichero de configuración en el campo <key>. Después de recibir y descifrar la biblioteca-plugin, se la ubica en la memoria asignada, con lo que queda lista para empezar el ataque DDoS en cuanto le llegue la orden correspondiente.
Los plugins se descargan con regularidad al ordenador infectado: tan pronto como el creador de virus perfecciona el método de ataque, el bot Black Energy 2 descarga la versión más nueva del plugin.
Los plugins descargados de esta manera se guardan en el disco duro del ordenador infectado en el catálogo del sistema “<WINDIR>system32drivers” bajo el nombre “str.sys”. El contenido del fichero str.sys se cifra con la llave indicada en el parámetro id. Antes de efectuar el cifrado, los datos contenidos en str.sys tienen el siguiente aspecto:
En cada plugin hay una función DispatchCommand que se puede exportar y que llama al módulo de gestión principal, la biblioteca dll incrustada en el proceso svchost.exe. A la función DispatchCommand se le transmite un parámetro, que es una de las instrucciones del sector <cmds> en el fichero de configuración del bot. Después de lo cual el plugin ejecuta la instrucción.
Los plugins principales
Los principales plugins de Black Energy son ddos, syn y http. Hablaremos un poco sobre cada uno de ellos.
El plugin ddos
A la entrada del plugin ddos se introduce la dirección del servidor atacado, el protocolo y el puerto. De conformidad con estos datos, se inician conexiones masivas con el servidor al puerto determinado y por el protocolo determinado. Después de establecer la conexión, se envía al servidor un paquete lleno de datos aleatorios. El plugin admite los protocolos tcp, udp, icmp y http.
He aquí un ejemplo de realización de la instrucción “ddos_start udp <интернет-адрес> 80”:
Se envía al servidor una solicitud GET mediante el protocolo http con la ayuda de las funciones socket, connect y send.
El plugin syn
A diferencia de los demás plugins mencionados en este artículo, en el plugin syn hay un driver de red. Al llamar la función DllEntry del plugin, este driver se instala en el catálogo “<WINDIR>system32drivers” bajo el nombre synsenddrv.sys». El driver se encarga de enviar los paquetes de red. Como ya se puede adivinar, la función DispatchCommand espera de la biblioteca un parámetro del siguiente aspecto: “syn_start <domain> <port>” o “syn_stop <domain>”. En caso de recibir el primer parámetro, el plugin empieza el ataque, si recibe el segundo, lo suspende. En el primer caso el ataque consiste de múltiples solicitudes de establecer conexiones, de la apertura de una sesión de red, también conocida como “apretón de manos” (handshake):
Como es natural, cuando las solicitudes múltiples proceden de una gran cantidad de ordenadores infectados, crean una carga sensible para el servidor.
El plugin http
Para contrarrestar los métodos de DDoS descritos se suele usar la redirección: el servidor con los recursos de Internet se esconde detrás de una pasarela que se ve desde el exterior y ésta remite las solicitudes a un servidor con recursos. La pasarela se defiende de los ataques DDoS con todos los métodos posibles y no es tan fácil dejarla fuera de combate. Por lo tanto, los plugins ddos y syn pueden atacar sólo a la pasarela según su dirección IP, ya que no cuentan con ninguna función de detección de la redirección del tráfico y el tráfico exagerado que generan simplemente no llega a alcanzar al servidor atacado. Para estos casos los creadores de virus han desarrollado el plugin http.
Al recibir la instrucción “http_start <url> <port>”, el plugin http crea el objeto COM “Internet Explorer (Ver 1.0)” con la interfaz “IwebBrowser2”. Se llama el método Navigate con el parámetro <url> de la instrucción “http_start”. El resultado es que el objeto COM “Internet Explorer (Ver 1.0)” hace la transición a la página indicada. Después, mediante el método Busy, el programa malicioso espera que se complete el procesamiento de la solicitud.
De esta manera se hace una emulación completa de una visita a la página realizada por un usuario común y corriente. La única diferencia es que, a diferencia del usuario, el programa malicioso realiza una gran cantidad de visitas a la misma dirección en un corto periodo. Incluso si se usa una pasarela con redirección, las solicitudes http se remiten al servidor protegido que contiene los recursos de Internet y se le crea una carga.
Las instrucciones básicas
Además de la descarga de plugins y la ejecución de instrucciones relacionadas con éstos, Black Energy 2 “entiende” varias instrucciones generales que pueden proceder del centro de administración:
rexec – descargar de Internet el fichero indicado y ejecutarlo;
lexec – ejecutar el fichero indicado, que se encuentra en el ordenador infectado;
die – cesar la ejecución del bot;
upd – actualizar el bot;
setfreq – establecer la frecuencia de envío de solicitudes al centro de administración;
http – enviar una solicitud http a una página determinada de Internet.
Conclusión
En un principio Black Energy se creó como un bot destinado a hacer ataques DDoS, pero con la aparición de la segunda versión de los plugins, las funcionalidades de esta familia maliciosa son prácticamente ilimitadas (aunque, la verdad sea dicha, los delincuentes por el momento la usan sobre todo para lanzar ataques DDoS). Se puede, por ejemplo, instalar un plugin para enviar spam, interceptar los datos del usuario, organizar servidores proxy, etc. La instrucción upd permite renovar el bot, por ejemplo, por una versión con un nuevo tipo de cifrado. La constante actualización le da al bot la posibilidad de permanecer ocultas ante los antivirus que pudiesen estar instalados en el ordenador del usuario. El potencial de este instrumento malicioso es bastante alto, lo que sin lugar a dudas, representa un gran peligro. En vista de que en Internet no existen las así denominadas versiones públicas de builders para la construcción de bots Black Energy 2, las diferentes variantes de este programa malicioso no aparecen en cantidades comparables a las de, por ejemplo, ZeuS o el primer Black Energy. No obstante, a juzgar por los datos que tenemos a nuestra disposición, los delincuentes han construido grandes botnets basados en la plataforma Black Energy 2, que ya han demostrado sus fuerzas al hacer ataques DDoS.
Es difícil saber con anticipación qué uso les darán los dueños a sus botnets. Para los escritores de virus es fácil crear un plugin y enviarlo a los ordenadores infectados. Y el código del plugin aparecerá sólo en la memoria RAM del ordenador infectado, porque en los demás lugares (durante el envío de datos o el almacenamiento en el disco duro) los módulos maliciosos estarán cifrados. Además, en sí los plugins para Black Energy 2 no son ficheros ejecutables “.exe”. Los plugins se descargan sólo en los equipos infectados y por lo tanto, no se difunden con métodos destinados a provocar infecciones masivas y puede pasar largo tiempo antes de que sean detectados por las compañías antivirus. Pero son precisamente los plugins los que a fin de cuentas plasman las ideas del delincuente, es decir, las acciones maliciosas para las que Black Energy 2 infectó los ordenadores de los usuarios. ¡Es necesario conocerlas! Con este objetivo nuestro laboratorio ha organizado la monitorización de los plugins para Black Energy 2, con lo que las tendencias de utilización de este programa malicioso no nos pasarán inadvertidas. También tendremos al lector al tanto de los sucesos.
Autores
De los mismos autores
En la misma categoría
Los DDoS negros