TDSS

• TDSS. Las tecnologías de los rootkits
  • Principio. TDL-1
  • La saga continúa. TDL-2
  • ¿Es el final? TDL-3
• TDSS online
  • La “Partnerka”
  • AffId
  • Connect
  • C&C
  • Blind SQL Injection
  • Del modo de núcleo al modo de usuario
• TDSS. Juego de herramientas para lucrar
  • El dinero
  • Carga
  • Instrucciones del centro de administración
  • El “virus que suplanta páginas web”
  • Black SEO
  • Clicker
• Dimensiones de la infección
• Esto todavía no es el final

El rootit TDSS, que apareció en 2008, con el tiempo se ha hecho mucho más popular que el escandaloso rootkit Rustock, y por sus funcionalidades y complejidad se aproxima a un bootkit. En los bootkits se usa un mecanismo que infecta el sector de arranque del disco duro, lo que hace que se cargue un código malicioso antes del inicio del sistema operativo. TDSS utiliza una función de infección de drivers que garantiza su inicio y funcionamiento en las etapas más tempranas del funcionamiento del sistema operativo. Como consecuencia, es muy difícil identificar el rootkit TDSS en el sistema y su tratamiento es un problema serio.

TDSS. Las tecnologías de los rootkits

Principio. TDL-1

Kaspersky Lab detectó la primera versión de TDSS el 6 de abril de 2008 y le asignó el veredicto Rootkit.Win32.Clbd.a. El nombre de este programa malicioso tiene cierta similitud con el driver clbdriver.sys y el nombre de la biblioteca dinámica clbdll.dll, en los cuales se encuentran sus funcionalidades maliciosas principales.

Todo lo grande empieza con algo pequeño y las tecnologías rootkit de la primera versión de TDSS no son la excepción. Las funcionalidades del driver son bastante sencillas, incluso para el año 2008.

Es digno de mencionar que desde los tiempos de la primera versión algunos componentes del rootkit no se han modificado:

1. El identificador “TDL”;
2. Las funciones de infección del driver;
3. El uso de un fichero de configuración;
4. La forma de trabajo con el panel de administración.

 
Parte del fichero de una de las primeras versiones del rootkit TDSS
(Rootkit.Win32.Clbd.o) que infecta el driver beep.sys

Principales funciones de este rootkit:

• para defenderse, oculta las ramas críticas del registro;
• oculta los ficheros críticos en el disco;
• incrusta el código malicioso en los procesos del sistema desde el driver en modo de núcleo;
• oculta los puertos de red TCP;
• ejecuta algunas funciones (clausura de proceso, terminación de flujos, ocultación de módulos DLL cargados, etc.).

Para ocultar los ficheros, se agrega un filtro malicioso en la pila (stack) de drivers del sistema. Y esta acción se ejecuta en ciclos para cada tomo del sistema. Este método permite matar dos pájaros de un tiro. El rootkit no solo esconde en el disco los ficheros cuyos nombres empiezan con las letras “tdl”, sino que si se intenta abrir el tomo DeviceHarddiskVolumeX, devuelve un error que provoca malfuncionamientos en los diferentes antirootkits que requieren acceso al tomo en cuestión para el análisis de bajo nivel de la estructura del sistema de ficheros.

El número del error que devuelve el programa malicioso -STATUS_TOO_MANY_SECRETS- es un testimonio del peculiar sentido del humor de los escritores de virus. Este truco se ha convertido en una especie de distintivo de sus autores.

La ocultación de los puertos de red también se realiza agregando un filtro malicioso a la pila del dispositivo DeviceTcp.

La ocultación de las ramas del registro del servicio malicioso y los datos de configuración se basa en la intercepción de la función del sistema NtEnumerateKey. La intercepción usa el método de splicing, que se basa en la sustitución de cierta cantidad de bytes en el principio de la función por un desvío que conduce al driver malicioso.

 
Ejemplo de splicing de las funciones NtEnumerateKey
y NtFlushInstructionCache en el sistema infectado

Una particularidad interesante de TDL-1 es que intercepta la función del sistema NtFlushInstructionCache. Es justo con su llamada que el driver es capaz de ejecutar diferentes instrucciones adicionales, para ser más exactos:

• destruir un flujo;
• bloquear la ejecución de un flujo;
• destruir el proceso actual;
• recibir el nombre del proceso actual;
• ocultar el módulo DLL cargado;
• descargar el driver;
• recibir el listado de los procesos en ejecución.

 
Función que ejecuta las instrucciones adicionales del rootkit

Para ocultar su driver en el sistema, el rootkit usa un procedimiento bastante trivial que consiste en separar el módulo cargado de la lista de drivers PsLoadedModuleList del sistema.

Y me parece que en este rootkit no hay ninguna otra cosa digna de interés. Con el nivel actual de desarrollo de las tecnologías antivirus, detectarlo y curarlo si se activa en el sistema es bastante fácil. La aparición de TDL-2 lo confirma.

La saga continúa. TDL-2

Las tecnologías antirootkit no paran de desarrollarse, y lo mismo hacen las tecnologías rootkit. Una nueva modificación de TDSS (TDL-2) apareció a principios de 2009.

Merece la pena destacar que se han detectado varias modificaciones del rootkit TDL-2 con nuevas funcionalidades, por lo que sus diferentes descripciones pueden ser diferir.

Para hacer más complicado el análisis de los driver maliciosos, los autores usaron los mecanismos de enmarañamiento y cifrado del cuerpo del rootkit. Entre otras cosas, para confundir al analista de virus, el contenido del fichero malicioso abunda en palabras escogidas al azar de la tragedia Hamlet de William Shakespeare.

 
Parte del contenido del fichero malicioso diluido con palabras al azar

En comparación con la primera versión, este rootkit ha cambiado poco en sus funcionalidades, pero sí han cambiado sus métodos de camuflaje y autodefensa. Para alcanzar sus propósitos, el driver malicioso intercepta mediante slicing varias funciones del núcleo, por ejemplo:

• IofCallDriver
• IofCompleteRequest
• NtFlushInstructionCache
• NtEnumerateKey
• NtSaveKey (en algunas versiones)
• NtSaveKey (en algunas versiones)
• NtQueryValueKey (en algunas versiones)

 
Funciones del sistema operativo interceptadas

Se podría haber tratado de eliminar las incoherencias indicadas más arriba, pero el rootkit usa varios flujos del modo núcleo en ciclos, en los cuales verifica la presencia de sus interceptores en el sistema y en caso de que no encontrarlos, los reinstala. De la misma forma se verifica que en el registro esté presente la información sobre el servicio malicioso y si no la encuentra, se recupera toda la información.

La intercepción de la función NtEnumerateKey también se utiliza para ocultar los ficheros de configuración de los datos del rootkit y sus ramas críticas en el registro.

La intercepción de las dos nuevas funciones NtSaveKey y NtSaveKeyEx se usa para impedir que algunos anti-rootkits detecten anomalías en el registro del sistema y con esto, la presencia de un código malicioso activo en el sistema.

La intercepción de la función NtFlushInstructionCache sirve para que los componentes del programa malicioso reciban acceso en modo de núcleo.

La intercepción de las funciones del sistema IofCallDriver y IofCompleteRequest permite al driver malicioso filtrar los paquetes IRP del sistema. Así se garantiza la funcionalidad que limita el acceso y oculta los ficheros del rootkit. En el SO Windows el sistema de entrada/salida está construido sobre una interfaz unificada y es el corazón del sistema operativo. El gestor de entrada/salida conecta las aplicaciones y componentes del sistema con los diferentes dispositivos. La mayoría de las solicitudes de entrada/salida son paquetes IRP especiales (I/O request packet). De esta manera, al interceptar las funciones mencionadas, se puede filtrar diferentes paquetes de entrada/salida del sistema, por ejemplo, las operaciones de apertura de ficheros. Pero si la intercepción de IofCallDriver ofrece la posibilidad de filtrar un paquete antes que el sistema, la intercepción de IofCompleteRequest permite anular las operaciones exitosas, por ejemplo, la apertura de un fichero.

La intercepción de IofCallDriver se ha implementado de una forma sui generis. En el interceptor se usa el método de desenrollamiento de la pila de ejecución, y si se encuentra en la pila un driver que no está en la lista de admitidos, si se hacen intentos de leer determinados ficheros se muestra que la operación tuvo éxito, pero en realidad no se los lee.

En la intercepción de IofCompleteRequest se devuelve un error STATUS_SECRET_TOO_LONG y se anula la operación exitosa.

El rootkit usa un truco que involucra la rama del registro ServiceGroupOrder. Esta rama del registro es responsable del orden de carga de los drivers. Si el rootkit detecta un driver cuyo grupo de carga está al principio de la lista, antes de System Reserved, entonces la entrada de este servicio en el registro se corrige de tal forma que el servicio se inicie mucho después. Este es un método más de resistencia a las tecnologías rootkit.

Esta funcionalidad es suficiente para evadir la mayoría de los antivirus de hoy en día, porque le permite al rootkit pasar inadvertido en el sistema infectado. No obstante, los autores decidieron seguir adelante: en el otoño de 2009 apareció TDL-3, el más potente, interesante y complejo rootkit que existe en este momento.

¿Es el final? TDL-3

La nueva versión del programa malicioso usa los últimos logros de los escritores de virus. Aparte de la creación del rootkit, los autores mejoran constantemente sus características de autodefensa, corrigen errores y defectos, agregan nuevas funcionalidades y reaccionan de inmediato ante la aparición de tecnologías antivirus que puedan detectarlo.

Para arraigar el rootkit en el sistema operativo, los autores eligieron una vía bastante conocida: un virus de fichero, para ser más exactos, uno que infecta los componentes del sistema operativo. Para inocular la infección se usa un minipuerto o un driver de puerto del disco. Este método permite al rootkit cargarse prácticamente después del inicio del sistema operativo.

En sus modificaciones más tardías, el rootkit aprendió a elegir e infectar al azar los drivers del sistema que según determinados parámetros le pueden ser útiles. Pero nosotros nos detendremos a analizar las versiones más tempranas, que para realizar la infección usaban el driver atapi.sys. La infección ocurre de tal manera que el tamaño del fichero no sufre cambios. Esto permite engañar a los antirookits, los cuales comparan el tamaño del fichero a partir de datos de alto y bajo nivel.

El infector reemplaza cierta cantidad de bytes en la sección de recursos del fichero-víctima por un cargador del cuerpo principal del rootkit y traslada el punto de entrada del driver.

 
Punto de entrada de atapi.sys antes de la infección

 
Punto de entrada del atapi.sys infectado

El principal objetivo de este pequeño cargador es cargar en la memoria el cuerpo principal del rootkit que se encuentra en los últimos sectores del disco y entregarle el control.

 
Cuerpo principal del rootkit con el indicador “TDL3”

Pero hay más sorpresas. TDL-3 usa una implementación propia de sistema cifrado de ficheros, en el que guarda sus datos de configuración y las bibliotecas adicionales del modo de usuario. Por eso es que no necesita sistemas de ficheros FAT o NTFS como tales.

 
Ejemplo de configuración del rootkit ubicado en los últimos sectores del disco

Uno de los principales objetivos de cualquier rootkit es el bloqueo y ocultación de los datos críticos del programa malicioso. Para conseguirlo, TDL-3 usa la técnica de suplantación del objeto que sirve al dispositivo del sistema.

 
Pila del disco

Todas las funciones que sirven a este dispositivo conducen a la función interceptora del driver malicioso:

 

Así, el rootkit filtra las solicitudes a los sectores del disco donde se encuentran los datos que tienen importancia crítica para su funcionamiento. En caso de que se hagan intentos de leer el driver infectado (en nuestro caso atapi.sys), se devuelve al cliente el contenido del fichero antes de la infección.

TDL-3 es un programa complejo y bien pensado desde el punto de vista tecnológico. Los autores siempre están al tanto de los últimos avances de las compañías antivirus y reaccionan inmediatamente publicando versiones nuevas y corregidas del rootkit (en este momento la última versión es la 3.273). Por eso, en un futuro cercano hay que esperar el cambio de la funcionalidad del rootkit en la dirección de un enfrentamiento más efectivo a las tecnologías antirootkit.

TDSS online

A principios de marzo de 2010 Kaspersky Lab registró un extraordinario crecimiento en la virulencia de TDSS.

 
Cantidad diaria de variantes detectadas del rootkit TDSS y sus componentes
(según los datos de Kaspersky Security Network)

Esta activa propagación de TDSS fue el motivo de que hacer un análisis más detallado de este rootkit. Más adelante presentamos los resultados de este análisis.

La “Partnerka”

De la propagación del rootkit TDSS se encargan los “programas de afiliados” que en el presente son el método más popular de cooperación entre los delincuentes para sus fines de lucro. Según la Wikipedia, un “programa de afiliados es una forma de cooperación entre un vendedor y sus afiliados para la venta de mercancías o servicios que permite al vendedor reducir los gastos de atraer al usuario final”. Para los delincuentes cibernéticos que participan en el programa de afiliados, la mercancía puede ser programas maliciosos y sus servicios, la atracción de usuarios a sitios web infectados y la inoculación de ordenadores. Existe una gran cantidad de diversos programas de afiliados, pero en nuestro caso se trata de los denominados “partnerka”, que propagan programas maliciosos y antivirus falsos.

Resultados 1 – 10 de aproximadamente 1 120 000 para la palabra “partnerka” (0,21 sec.)

Cantidad de páginas encontradas en el motor de búsqueda
Google con la palabra clave “partnerka”

Es curioso que a los participantes en las “partnerkas” no se les pone ningún límite de propagación de programas maliciosos. Mientras más ordenadores se infecten, más dinero se le pagará al afiliado.

Por eso, apara infectar programas maliciosos en los ordenadores de los usuarios, la mayoría de los afiliados usan diversos conjuntos de exploits
, gusanos y virus.
De esta manera, el gusano Worm.Win32.Kido (Conficker), que causó una epidemia a principios de año, contenía una función de descarga y ejecución del programa de afiliados Traffic Converter, que se encarga de propagar antivirus falsos.

La mayoría de los programas de afiliados que difunden códigos maliciosos funcionan según el esquema Pay-Per-Install (PPI, pago por instalación), donde los pagos al afiliado dependen de la cantidad de instalaciones del programa malicioso y de la ubicación geográfica de los ordenadores infectados.

 
Sitio del programa de afiliados PMSoftware, que propaga TDSS y falsos antivirus El
pago por instalación depende de la ubicación geográfica del ordenador-víctima

AffId

En vista de que el rootkit TDSS se difunde a través de una “partnerka”, entre sus funcionalidades se ha incluido un mecanismo de transmisión de información sobre el afiliado que instaló el rootkit en el ordenador del usuario. Esta información se guarda en el fichero de configuración del rootkit en forma de una cifra en el campo AffId.

Parte del fichero de configuración del rootkit TDSS que
contiene el identificador del afiliado en el campo AffId

El identificador AffId se transmite al panel de administración para indicar que un afiliado en concreto ha instalado una versión del rootkit en un ordenador dado y que hay que pagarle precisamente a él. Al mismo tiempo, el panel de administración determina la ubicación geográfica del ordenador infectado por la dirección IP desde donde se envió el identificador.

Al recibir información sobre los nuevos casos de instalación de TDSS y las fuentes de infección se puede determinar qué formas de propagación del rootkit usan los diferentes afiliados. Por ejemplo, el afiliado número 20106 infecta los ordenadores de los usuarios con la ayuda de códecs falsos, que supuestamente se necesitan para ver un vídeo en un sitio web.

 
Propuesta de instalar un códec para ver un vídeo

Los afiliados 10438 y 11418 proponen a los usuarios instalar un generador de llaves para programas, que al mismo tiempo instala un rootkit.

 
Utilitario para instalar TDSS junto con el keygen

El afiliado con AffId 20273 infecta los ordenadores de los usuarios con la ayuda de exploits (Drive-by-Download) y los rootkits con el identificador 00123 fueron instalados en equipos que figuraban en dos botnets CnC (ZeuS) diferentes. Esta circunstancia puede significar que el dueño de ambas botnets es el mismo.

Connect

Las direcciones del panel de administración a las que se conecta TDSS durante su primera ejecución en el ordenador infectado también se indican en el fichero de configuración. Por lo general, en cada fichero hay tres de estas direcciones. Para la última versión del rootkit se conocen 33 direcciones. Los paneles de administración están ubicados en China, Luxemburgo, Hong-Kong, Holanda y Rusia. Este es el formato de las solicitudes:

GUID|AffId|status|erType|erCode|OS

GUID identificador exclusivo del ordenador infectado

AffId identificador del afiliado

Status estado de la tarea en curso

erType tipo de error durante el funcionamiento del rootkit

erCode código del error

OS versión del sistema operativo del ordenador infectado

El trabajo con el panel de administración se realiza mediante el protocolo HTTPS, para lo cual se usa un certificado de seguridad firmado por los delincuentes, expedido por una organización inexistente, Widgits Pty Ltd (entre los programadores este certificado se usa como ejemplo de certificado estándar para SSL).

 
Certificado estándar de seguridad para C&C

El trabajo mediante el protocolo HTTPS con el uso de un certificado estándar persigue dos objetivos:

1. Impedir que los antivirus detecten y bloqueen el tráfico de red según el contenido específico de los paquetes.
2. Impedir que se falsifique el panel de administración para apoderarse del mando de la botnet.

Además de trabajar en un canal seguro, la tercera versión de TDSS también usa un algoritmo de cifrado de las solicitudes GET. Primero, la solicitud se cifra en el dominio del panel de administración usando el algoritmo RC4 y después se codifica en BASE64 (http://ru.wikipedia.org/wiki/Base64). Y si las solicitudes GET generadas por las versiones anteriores de TDSS podían ser interceptadas y reconocidas por los antivirus, las solicitudes GET de la tercera versión del rootkit son prácticamente imposibles de reconocer, ya que descifrar cada solicitud GET enviada desde el ordenador del usuario exige grandes recursos de procesador y memoria.

BASE64(RC4(“domain.org”,”f1344ab7-e226-4385-b292-328fd91e5209|20123|0|1|0|5.1 2600 SP2.0″)) = naRV/t1H20oohxzGEVXPMbdVVOjvK0PMUE VzuYWyEDHKsOFud57tO4HMkrkf0abk5UC3XtwDW/7Fmc s7Vy14niX4t3eRARHRlnGKP14CcOwASIdVHac

 

Ejemplo de cifrado de solicitud GET HTTP de TDSS

C&C

Las diferentes versiones de TDSS usaban diferentes juegos de scripts y bases de datos para administrar los bots y guardar información sobre los mismos. Así, durante el trabajo de TDL-2 se usaba el motor SENEKA (algunos antivirus bautizaron con el mismo nombre esta versión de TDSS), mientras que en el presente la botnet TDSS usa DM-Engine para su funcionamiento. Conociendo el formato de los paquetes y el algoritmo de cifrado, se puede enviar una solicitud especial al panel de administración de la botnet para recibir no solo las instrucciones dirigidas a los ordenadores infectados, sino también la información sobre la estructura del panel de administración y el contenido de su base de datos. Se puede crear a propósito errores en las solicitudes enviadas al panel de administración para averiguar la ubicación y nombres de los ficheros que mantienen la botnet.

/data/www/dm_engine/library/classes/DBase.php /data/www/dm_engine/public/enginestatusn.php /data/www/dm_engine/library/models/mSystems.php /data/www/dm_engine/public/index.php

 

Ejemplo de ubicación de los ficheros en el panel de administración de TDSS

Al saber el formato de las solicitudes y los parámetros de los bots, se puede también deducir de qué manera el panel de administración procesa estos parámetros.

Tabla de trabajo del panel de administración sobre los parámetros enviados por TDSS

Todos estos datos permiten obtener información sobre el contenido de algunos campos de la base de datos del panel de administración que se encarga de la botnet TDSS.

Blind SQL Injection

La base de datos instalada en el panel de administración funciona en silencio y no permite obtener notificaciones sobre la ejecución de solicitudes que se le envían. Sin embargo, el método de “inyección ciega” (Blind SQL Injection) permite analizar los resultados de las solicitudes basándose en el retardo en recibir la respuesta HTTP. El principal problema de este método consiste en escoger los nombres y campos correctos almacenados en la base de datos. En vista de que el delincuente que creó el panel de administración usó nombres de campo y tablas que guardan relación con los nombres de los bots, no es difícil extrapolarlos.

Así, en el código del bot, el campo GUID en la solicitud TDSS enviada al panel de administración se denominaba SystemId, y el nombre de la tabla en la que se almacenan todos los identificadores de los ordenadores infectados… pues lógicamente se llama Systems. Todos los identificadores de los afiliados (Affld) se guardan en la tabla Affiliates. Usando los campos numéricos vulnerables enviados por TDSS al panel de administración, se puede generar la siguiente solicitud: en el caso de que la cantidad de entradas SystemId, en las cuales se almacenan los identificadores de los ordenadores infectados sea más de una, devolver “1”, si no, ejecutar el cálculo de funciones hash MD5 20 millones de veces.

“26344ab7-e226-4385-b292-328fd91e5209|20123|0|1 AND IF ((SELECT COUNT(systemId) From systems) > 1,1,Benchmark(20000000,md5(1))) |0|5.1 2600 SP2.0″

 

Solicitud a la base de datos del panel de administración de TDSS

Esta solicitud se cifra, usando como llave el nombre del panel de administración. Después de enviar la solicitud, la confirmación del panel de administración sobre su ejecución vuelve en el lapso de un segundo. Si se modifica esta solicitud para cien mil ordenadores infectados (en el caso de que la cantidad de entradas SystemId en las cuales se almacenan los identificadores de ordenadores infectados sean más de cien mil… etc.), la respuesta llegará en el lapso de 10 segundos.

“26344ab7-e226-4385-b292-328fd91e5209|20123|0|1 AND IF ((SELECT COUNT(systemId) From systems) > 100000,1,Benchmark(20000000,md5(1))) |0|5.1 2600 SP2.0″

 

Solicitud modificada a la base de datos del panel de administración de TDSS

Al formar de esta manera las solicitudes, se puede establecer que el panel de administración en el dominio 873hgf7xx60.com se encarga de 243 ordenadores infectados y el panel en el dominio zz87jhfda88.com sólo de 119.

A principios de junio, cerca de 2.000 afiliados difundían TDSS.

26345ab7-e226-4385-b292-328fd91e5209|20023|0|1 AND IF ((SELECT COUNT(affid) From affiliates) > 1691,1,Benchmark(20000000,md5(1))) |0|5.1 2600 SP2.0

 

Solicitud a la base de datos del panel de administración TDSS
(En caso de que la cantidad de entradas AffId que contienen identificadores de afiliados sea mayor de 169,
devolver “1”, en caso contrario, ejecutar el procesamiento de la función hash MD5 20 millones de veces)

No es difícil adivinar que este método puede usarse para borrar todas las tablas en el panel de administración de la botnet y para hacer crecer los pagos a los afiliados.

Del modo de núcleo al modo de usuario

La tecnología que el rootkit TDSS usa para comunicarse con el mundo exterior no ha cambiado desde las primeras versiones. Así, el rootkit lee el fichero config.ini, en el cual se suelen indicar los siguientes datos predeterminados:

[main], la función principal que identifica el rootkit en el sistema.

• Quote1, citas de películas, dibujos animados, etc. que se visualiza cuando se conecta el depurador.
• Version, la versión del rootkit instalado.
• BotId, el identificador del bot para el panel de administración.
• AffId, identificador del afiliado.
• SubId, es “0” por omisión y sirve para la identificación adicional del bot si la botnet se divide.
• Installdate, fecha de instalación del rootkit en el sistema.
• Builddate, fecha de compilación del rootkit.

[injector], sección que apunta a la carga útil del rootkit.

• El primer campo contiene el nombre de los procesos (por omisión “*”, significa todos los procesos).
• El segundo campo indica el nombre de la biblioteca dinámica que hay que cargar para los procesos indicados.

[tdlcmd], la sección de la carga útil.

• Servers, las direcciones de los paneles de administración del rootkit, por lo general tres.
• Wspservers, las direcciones de los servidores para el trabajo con los servicios de búsqueda.
• Popupservers, direcciones de los servidores para la apertura de páginas.
• Version, versión de la carga útil.

 
Ejemplo de contenido del fichero de configuración del rootkit TDSS

El formato del fichero de configuración puede cambiar según la versión de TDSS, su carga útil y también por orden del centro de administración de la botnet.

TDSS. Juego de herramientas para lucrar

El dinero

Rootkit.Win32.TDSS es un programa malicioso multifacético, que puede ocultar la presencia en el sistema de cualquier otro programa malicioso y darles grandes posibilidades en el sistema infectado. En un bootkit ya se habían utilizado tecnologías similares y entonces escribimos que programas maliciosos parecidos, gracias a su facilidad de utilización y amplio espectro de posibilidades, podrían popularizarse entre los delincuentes. En esencia, TDSS es un framework que se actualiza y complementa constantemente.

El rootkit TDSS implementa de forma predeterminada sólo la funcionalidad de Trojan-Clicker (http://www.securelist.com/ru/encyclopedia/objects/trojan-programs/trojan-clicker#list ) y los delincuentes lo usan para lucrar con la manipulación de la cantidad de visitas a los sitios web. Esta funcionalidad está incluida en una biblioteca dinámica que es parte de todas las configuraciones estándar del rootkit y que la mayor parte de las veces se llama tdlcmd.dll. Sin embargo, las posibilidades del rootkit son mucho más amplias y su utilización posterior depende sólo de los deseos de los autores y las tareas de los arrendatarios o compradores de la botnet construida con este programa malicioso. En 2009, se estimaba que la cantidad de ordenadores infectados que funcionaban bajo la dirección de TDSS era de 3 millones, y que cerca de la mitad de ellos se encontraban en el territorio de EEUU.

Es curioso que durante el análisis de todos los casos relacionados con este programa malicioso, todo el tiempo hemos tenido la impresión de que su autor o autores son rusos, o por lo menos, de habla rusa. Con regularidad actualizan TDSS, pero lo conservan en sus manos, sin ponerlo nunca en venta. Se venden sólo las botnets dirigidas por TDSS y que como regla constan de unos 20.000 equipos infectados.

A partir de este momento, el uso posterior del botnet TDSS depende del comprador. En todo el tiempo que llevamos haciendo nuestras observaciones, en una de estas botnets se cargaron spam-bots, antivirus falsos y troyanos para robar datos personales.

Carga

Los autores de TDSS tomaron precauciones para que las botnets creadas les traigan lucro. Una de las cargas útiles que TDSS instala por omisión es la biblioteca dinámica tdlcmd.dll.

En la mayoría de los casos el fichero tdlcmd.dll se carga junto con TDSS y el rootkit lo incluye en todos los procesos, pero para cumplir con su carga útil, esta biblioteca funciona sólo en los procesos de los navegadores y el servicio de actualización de Windows, porque así recibe la posibilidad de trabajar con los datos de los procesos en la red.

 
Lista de procesos en los cuales funciona tdlcmd.dll

Durante su funcionamiento, la biblioteca tdlcmd.dll ejecuta las siguientes tareas:

1. Recibe y ejecuta las instrucciones del centro de administración del botnet.
2. Intercepta las solicitudes que el usuario envía a los sistemas populares de búsqueda para sustituir la respuesta.
3. Crea solicitudes para enviarlas a los sistemas de búsqueda.
4. Emula el trabajo del usuario en el sitio.

Cada una de estas acciones contribuye a que los dueños de la botnet construida mediante TDSS se enriquezcan.

Instrucciones del centro de administración

En la configuración predeterminada tldcmd.dll ejecuta las siguientes instrucciones del panel de administración:

• DownloadCrypted, descargar el fichero cifrado;
• DownloadAndExecute, descargar y ejecutar el fichero;
• DownloadCryptedAndExecute, descargar el fichero cifrado, descifrarlo y ejecutarlo;
• Dowload, descargar el fichero;
• ConfigWrite, introducir los cambios en el fichero de configuración.

En caso de que se descargue una instrucción cifrada desde el C&C, se la descifrará usando el algoritmo RC4. En este caso la clave es el nombre del dominio desde el que se descarga el fichero indicado. Después de ejecutar la instrucción del panel de administración, en el fichero config.ini se crea la sección [Tasks], en la que se anotan todas las acciones del bot.

Ejemplo de nota en el fichero config.ini creada después
de descargar la versión actualizada de tdlcmd.dll

Tomando en cuenta que toda la comunicación con el panel de administración se realiza mediante el protocolo HTTPS, la lectura de esta sección simplifica mucho el trabajo de los analistas durante el seguimiento que hacen de las acciones de TDSS.

TDSS, a diferencia del bootkit o Kido, no consta de un algoritmo de elección de dominios para los centros de administración migrantes, pero la instrucción ConfigWrite que cambia el campo Servers en la sección [tdlcmd] llega la primera vez que se envía una solicitud al centro de administración y después una vez por semana.

 
Ejemplo de ubicación del panel de administración

El “virus que suplanta páginas web”

Durante el proceso de trabajo del navegador, tdlcmd.dll hace un seguimiento de los sitios visitados por los usuarios:

En cada solicitud a los sitios indicados, tdlcmd.dll genera también una solicitud al servidor indicado en el campo Wspservers del fichero de configuración. Se envía al servidor la información sobre el sistema infectado y sobre la solicitud enviada por el usuario al sitio indicado. Como respuesta, el servidor envía un enlace a la página que hay que mostrar al usuario. El enlace puede llevar al usuario a cualquier sitio, por ejemplo un sitio phishing o uno legítimo. El sistema de búsqueda ruso Yandex escribió sobre un ataque similar en 2008. En ese entonces esta venía incluída en muchos programas maliciosos.

Es curioso que en la segunda versión del rootkit TDSS su carga útil no funcionaba con el buscador FireFox y los delincuentes tuvieron que recurrir a instalar un addon que ejecutase las mismas funciones en el navegador.

 
Ejemplo de addon para el navegador FireFox, que sirve para remitir a otra
dirección las solicitudes de búsqueda del usuario

Black SEO

Hace sólo unos años, al buscar “antivirus” en Google, en la primera página aparecían sólo antivirus falsos. Esto se lograba mediante la “optimización negra del posicionamiento en buscadores”.

El fichero tdlcmd.dll contiene una funcionalidad similar de “optimización” de sitios según palabras clave. En la parte del disco cifrada por el rootkit se crea el fichero keywords, que contiene las palabras que hay que enviar al sistema de búsqueda. Después, en la página de resultados del sistema de búsqueda se escoge el sitio elegido por los delincuentes. Para hacer una emulación completa del trabajo del usuario con el sistema de búsqueda, se usa JavaScript, que se instala en el navegador e imita la pulsación en los botones correspondientes de transición.

 
Ejemplo de entrega de un sitio que contiene exploits

Clicker

La comunicación del rootkit con el servidor de administración se realiza mediante el protocolo HTTPS. Sin embargo, durante el trabajo con servidores que sirven para hacer cliks falsos, tdlcmd.dll sólo cifra la solicitud GET, con los mismos algoritmos RC4 con el consiguiente recifrado del resultado en BASE64. Tdlcmd.dll se conecta con el servidor indicado en el parámetro Popupservers del fichero de configuración. Como respuesta, el servidor envía el nombre del sitio, el enlace al sitio y la dirección del recurso web desde el cual hay que seguir este enlace. Además, en el fichero de configuración se indica la frecuencia con la que hay que entrar al sitio. A diferencia de otros programas maliciosos con funcionalidades similares, TDSS crea una ventana real del navegador para hacer una emulación completa de la entrada del usuario al sito. De esta manera TDSS muestra ventanas publicitarias, antivirus falsos y cualquier otro tipo de sitio según el deseo de los dueños de la botnet.

Dimensiones de la infección

La propagación de TDSS mediante los programas de afiliados con el uso de cualquiera de las formas posibles de entrega del código malicioso a los ordenadores de los usuarios ha provocado que el rootkit TDSS ataque ordenadores en todo el mundo.

 
Estadística de infecciones provocadas por el rootkit TDSS en la primera mitad de
2010 (según los datos de Kaspersky Security Network)

En vista de que las infecciones de los ordenadores ubicados en EEUU son las mejores recompensadas (ver más arriba), TDSS se propaga con más ahínco precisamente en este país.

Como complemento a la estadística KSN, también se puede obtener información sobre el panel de administración de la botnet:

Esto todavía no es el final

El soporte continuo, la corrección de errores y los diferentes métodos de evasión de los métodos de detección según firmas, heurístico y proactivo le permiten a TDSS penetrar en los ordenadores de los usuarios incluso si tienen un antivirus instalado.

El uso de métodos de cifrado durante la comunicación del bot con el centro de administración dificulta sustancialmente el análisis de los paquetes de red. El potentísimo componente de rootkit oculta la infección y sus componentes críticos. El ordenador de la víctima se convierte en un eslabón de la botnet en el que se instalan otros programas maliciosos. Los delincuentes lucran vendiendo botnets de poca envergadura y usando el Black SEO.

Mientras el programa malicioso siga trayendo ganancias, se lo seguirá modificando y perfeccionando. TDSS se ha convertido en un dolor de cabeza para las compañías antivirus. Kaspersky Lab presta gran atención a los problemas relacionados con la detección y tratamiento de TDSS. Esperamos que nuestros colegas de la industria antivirus no se olviden de este programa malicioso y hagan todo lo posible para defender de esta amenaza a los usuarios.