Todo sobre el rootkit Rustock

El rootkit indetectable

En diciembre de 2006, en ciertos sitios dedicados al análisis de las herramientas informáticas para camuflar actividades, como blackhat y whitehat, empezó a circular un rumor sobre la creación de una “herramienta absolutamente invisible de camuflaje de actividades”, llamada Rustock.C. El rumor decía que ninguno de los programas antivirus o de las soluciones anti-rootkit podía detectarla.

Intensas investigaciones sobre esta «herramienta de rootkit» no dieron resultado alguno. La situación era tal que los especialistas no tomaban en serio la información sobre “Rustock.C”, considerándola una broma. Ese era el panorama hasta mayo de 2008.

El doctor hace su diagnóstico

A principios del mes de mayo, la compañía rusa DrWeb anunció a los medios especializados en la lucha antivirus que sus expertos habían descubierto la herramienta rootkit Ntlrdbot, que en realidad era Rustock.C. Mala noticia, pero sensacional al mismo tiempo.

Según las declaraciones de los representantes de DrWeb, esta herramienta de rootkit había conseguido eludir los medios de detección de todos los desarrolladores de programas antivirus desde octubre de 2007. Algunos especialistas hasta se atrevieron a opinar que Rustock.C había contribuido a la implementación de poderosas redes zombi destinadas a la propagación de correo no deseado. Se citaron los resultados de un estudio realizado por la compañía Secure Works. Según este estudio, la red zombi creada por Rustock era la tercera de las redes más importantes y era capaz de propagar a diario hasta 30 millones de mensajes no deseados.

Sin embargo, no es muy probable que las estimaciones de Secure Works se refirieran de una manera u otra a la herramienta de rootkit detectada, porque esta era literalmente desconocida hasta mayo de 2008. Es más probable que los especialistas de Secure Works se refirieran a una red creada por versiones anteriores de Rustock, a saber, las versiones A y B (Costrat y SpamTool.Win32.Mailbot, según la clasificación de Kaspersky Lab).

De acuerdo a la información proveniente de otro editor, una muestra de Rustock.C cayó en manos de los expertos a fines de marzo de 2008, y fue necesario más de un mes para analizar el código de la herramienta de camuflaje y crear y difundir los medios para detectarla y eliminarla. Sólo después se alertó a otros desarrolladores de soluciones antivirus.

A juzgar por la información publicada por DrWeb, el análisis del rootkit estaba lejos de responder a todas las interrogantes surgidas. En primer lugar, nada dejaba entrever cómo y cuándo esta herramienta de rootkit se había propagado y por qué no se la pudo descubrir desde octubre del 2007.

La muestra de la herramienta de rootkit difundida era un driver del sistema operativo Windows de un tamaño de 244 448 bytes.

Pero, por desgracia, faltaba el archivo responsable de la instalación de la herramienta en el sistema (“dropper”). De haber contado con este archivo se habría facilitado de manera considerable la tarea de los laboratorios antivirus en lo referente al análisis y a la adición de procedimientos complementarios para descubrir Rustock.C y neutralizar sus efectos; también habría sido posible aportar respuestas sobre la propagación inicial de esta herramienta de camuflaje de actividades.

Tampoco se contaba con información fiable sobre la presencia de esta herramienta de rootkit en Internet. Todo parecía indicar que Rustock.C era un producto de “colección” y que no se habría propagado en el mundo real, lo que quizás explicaba por qué se había tardado tanto en detectarlo.

Análisis en laboratorio

El 12 de mayo, Kaspersky Lab inició el análisis en profundidad del código de esta herramienta de camuflaje de actividades. La tarea que les esperaba a nuestros especialistas era particularmente compleja. Todo el código del rootkit estaba cifrado según un método desconocido y no se prestaba a los métodos tradicionales de análisis de códigos comprimidos y de emulación. El problema se agravaba por el hecho de que cada archivo de la herramienta estaba de alguna manera vinculado a una parte material del ordenador infectado, y no era posible ejecutar y analizar la herramienta en otros equipos o en máquinas virtuales.

Dicho esto, nuestros expertos lograron vencer todos los obstáculos y en dos días pudieron descifrar una parte considerable del cuerpo del virus con la ayuda de una clave descifrada. En la noche del 14 de mayo, habíamos logrado descifrar los segmentos del verdadero código de Rustock.C.

Junto a la resolución de este complejo problema técnico, habíamos realizado intentos de descubrir el archivo que instalaba la herramienta de rootkit en el sistema. Su descubrimiento debía permitirnos no sólo acelerar el análisis, sino también detectar las fuentes de propagación de Rustock.C.

Nuestras investigaciones nos permitieron descubrir 599 archivos de Rustock.C. Una parte de estos archivos presentaban lo que se llama el “cuerpo en sí” del código rootkit, mientras que la otra parte estaba compuesta de drivers de sistema infectados. En realidad, todos los archivos eran el resultado de un polimorfismo aplicado al mismo código.

¿Cuándo se creó rootkit?

A partir de ese momento contábamos con 600 archivos que se distinguían por su tamaño y por la fecha en que nuestras trampas los capturaron. Todos los archivos encontrados cayeron en las trampas entre el 10 de septiembre de 2007 y el 14 de mayo de 2008. Adelantándonos con las conclusiones, diría que no hemos descubierto ninguna muestra de Rustock.C creada antes de septiembre de 2007. No se descarta que versiones más antiguas hayan aparecido antes de esta fecha, como las versiones de evaluación o las pruebas de concepto del autor. Pero la herramienta llamada Ntldrbot de DrWeb poseía una clara fecha de nacimiento: septiembre de 2007.

¿Dónde ubicar en este contexto los rumores sobre la existencia de Rustock.C a finales de 2006? Creemos que Rustock.C no existía en aquel entonces. Se creó mucho después de su campaña publicitaria entre los analistas de herramientas de disimulación de actividades, quizás a manera de reacción ante la histeria relacionada con las investigaciones. Esta conclusión puede confirmarse de manera indirecta por el hecho de que el código de la herramienta de rootkit contiene el nombre del programa malicioso “Rustock.C”, que corresponde a un nombre dado por el autor a las versiones Rustock.A y Rustock.B (“spambot” y número de la versión). La compañía Symantec usó este nombre para designar a la primera versión de la herramienta de rootkit y se remonta a 2005 y 2006. El nombre fue adoptado por los especialistas en rootkits y por analogía con las versiones Rstock.A y Rustock.B ya conocidas, la versión “invisible” se designó como Rustock.C”. Es posible que el autor decidiera nombrar su nueva herramienta de rootkit de esta manera para confirmar los rumores sobre su existencia.

De una u otra manera, las primeras versiones «funcionales» de Rustock.C nacieron en septiembre de 2007 y muy probablemente, su desarrollo comenzó algunos meses antes.

Modificaciones

El análisis de los 599 archivos evidencia numerosos detalles interesantes desconocidos hasta entonces.

Identificamos 4 modificaciones de Rustock.C.

Creemos que la versión C1 se creó el 10 de septiembre de 2007. En sí, el “cuerpo” de la herramienta de rootkit alcanza un tamaño comprimido de entre 244 440 y 244 512 bytes y contiene un driver y una DLL. Esta es la versión que los expertos de DrWeb estudiaron y presentaron a los desarrolladores de soluciones antivirus.

La versión C2 se remonta al 26 de septiembre. Su tamaño está entre 158 432 y 158 464 bytes.

Las versiones C3 y C4 se crearon el 9 y el 10 de octubre de 2007. Su tamaño varía entre 158 400 y 158 496 bytes.

Aunque la versión C1 difiere de las versiones siguientes en casi 100 Kb, en realidad no existen grandes diferencias entre ellas. Su autor sólo optimizó el algoritmo de la herramienta de disimulación de actividades. Todas las versiones presentan diferencias mínimas al nivel del código de la DLL (spambot).

Spambot

Analizamos la herramienta de rootkit durante cinco días: se la descomprimió en su totalidad y se la ejecutó en máquinas virtuales (a pesar de no contar con el “dropper”). Esto nos permitió acceder al código DLL (spambot) cuya existencia y protección son el objetivo principal de Rustock.C.

Durante su funcionamiento, la herramienta de rootkit extrae la DLL y la ejecuta en la memoria del sistema, inyectándola en el proceso winlogon.exe. Esta DLL no existe como un archivo en el disco y sólo se encuentra en la memoria del ordenador. Su tarea consiste en propagar correo no deseado desde el ordenador infectado. Para desarrollar esta función, se conecta con el servidor 208.66.194.215 y recibe los modelos de los mensajes a propagar. La dirección IP pertenece al proveedor de hospedaje (hosting) MCCOLO que desde hace ya mucho tiempo hospeda programas maliciosos y sitios de grupos de ciberdelincuentes.

Detección y reparación

Aunque el autor aplica las herramientas de camuflaje a Rustock.C (protector, codificador, clave de codificación), la adición de la detección de esta herramienta de rootkit a las bases de datos antivirus de Kaspersky Lab no reviste ninguna dificultad. Parecería que el autor estaba tan convencido de la eficacia de la codificación de su obra que no tuvo en cuenta los métodos de detección que los programas antivirus poseen. El objetivo que perseguía era el de crear el máximo de complicaciones y de aplazar en lo posible el análisis del código (tanto por parte de los desarrolladores de programas antivirus como de la de los autores de virus) y las tecnologías de codificación empleadas también tenían el mismo objetivo.

La reparación de los sistemas de archivos infectados por la herramienta de rootkit es algo más compleja. El principio de funcionamiento de una herramienta de rootkit se basa en la infección de sólo los drivers Windows creados por Microsoft (responsables del lanzamiento del sistema operativo). Esta es la forma en que la herramienta de rootkit puede tomar el control y disimular su presencia en el sistema. El driver infectado original se encontraba en la última sección del cuerpo del rootkit y también estaba codificado.

El algoritmo que permitía a la herramienta de rootkit codificar el cuerpo del driver infectado era bastante simple y no dependía de ninguna parte material del ordenador infectado. Asimismo, pudimos detectar y reparar en su totalidad los archivos infectados.

La herramienta de rootkit recibió la clasificación Virus.Win32.Rustock.a. Pertenece a la categoría de virus porque Rustock es un virus de archivo que funciona en el núcleo del sistema operativo.

Kaspersky Lab difundió los procedimientos de detección y de reparación el 20 de mayo de 2008 (8 días después de iniciada la investigación).

La versión más reciente de nuestro programa antivirus, KAV/KIS 2009, es perfectamente capaz de detectar una herramienta de rootkit activa en el sistema infectado y de reparar los archivos infectados. Los usuarios de otras versiones pueden detectar una eventual presencia de Rustock en sus ordenadores mediante el Disco de Rescate y de cualquier versión de nuestro programa antivirus. También pueden identificar y reparar los archivos sospechosos aunque no exista una infección activa.

Preguntas y respuestas

Podría pensarse que la tarea había terminado; se descubrió la herramienta de rootkit y las víctimas disponen de una solución confiable para neutralizar el problema. Pero las preguntas fundamentales todavía quedaban sin respuesta: ¿Cómo se propagó Rustock? ¿Realmente está circulando en Internet? Dar respuesta a estas interrogantes y poner el punto sobre las íes era una cuestión de honor para nosotros .

Propagación de Rustock

Durante varios días analizamos en profundidad todas las muestras de la herramienta de rootkit que llegaban a nuestras manos con el fin de definir sus “parámetros materiales”. Este análisis debía proporcionarnos al menos una representación aproximada del alcance de la propagación de Rustock. Todos los datos corresponden a las fechas de descubrimiento de las muestras.

Así, de las 599 muestras, 590 fueron capturadas en nuestras trampas entre el 10 de septiembre y el 23 de noviembre de 2007, contra 9 sólo entre el 23 de noviembre de 2007 y mediados de mayo de 2008.

Se utilizaron estas estadísticas para definir los objetos de la investigación y para establecer las relaciones entre los archivos y las cuatro versiones de la herramienta de rootkit que conocíamos.

El cuadro era el siguiente:

Entre el 17 de octubre y el 12 de noviembre de 2007 no se registró ningún caso de aparición de Rustock. Sin embargo, entre el 12 y el 22 de noviembre, se registró una nueva ola de actividades, sobre todo relacionada con la versión C2 (desde el 26 de septiembre) con adiciones insignificantes de las versiones C3 y C4.

A partir del 23 de noviembre de 2007 ingresamos en un largo periodo de calma ¿o de “hibernación”?) que duró algunos meses, durante el cual no tuvimos noticias de Rustock.

Estos datos resultaban realmente interesantes, pero aún no sabíamos nada de la magnitud de la propagación de Rustock y de los medios de los que se valió. A pesar de todos nuestros esfuerzos, no encontrábamos el “dropper” de la herramienta de disimulación de actividades.

Pero la suerte nos sonreiría. Habíamos descubierto 500 archivos de la herramienta de disimulación de actividades, cuyo eslabón perdido aún faltaba descubrir.

Los rootkits y las redes zombi

Nuestras diagnóstico de que la propagación activa de Rustock se había iniciado el 10 de septiembre de 2007 se confirmaron. Esto nos permitió detectar los servidores desde los cuales se descargaba y explicar la manera en que se instalaba en el sistema. Encontramos la respuesta a las preguntas “¿Dónde se encuentra el “dropper”?” y “¿se encontraban realmente indefensos los usuarios de programas antivirus contra esta herramienta de rootkit “indetectable” que se propagó al menos durante tres meses?”.

Por desgracia, el modo de propagación y los canales utilizados por Rustock aún preocupaban a los expertos en seguridad informática. Estos son nombres bien conocidos por todo experto antivirus:

Pues sí. Una vez ya nos habíamos enfrentado a uno de los grupos de ciberdelincuentes más conocidos en Internet, al cual se asocian los nombres arriba mencionados. Estos son los nombres que designan sus sitios y sus programas maliciosos. La banda existe al menos desde principios de 2004 y permanece activa en el presente. Entre las “obras” más conocidas y más difundidas de este grupo, podemos mencionar troyanos como Harnig, Tibs, Femad, LoadAdv y diversas versiones de Trojan-Downloader.Agent y Small, así como el troyano Inject.

Estos hábiles ciberdelincuentes siempre han estado a la vanguardia en la creación de virus; fueron los primeros en utilizar los troyanos descargadores en los archivos chm y en sus servidores se descubrieron las primeras versiones de los códigos de explotación de vulnerabilidades en el tratamiento de los archivos ANI e ICO. Utilizaron troyanos escritos en Java (Trojan-Downloader.Java.ClassLoader) e iniciaron la moda de los scripts de descarga.

El grupo IFrameBiz tuvo como peculiaridad usar durante mucho tiempo los dominios en la zona .biz y los nombres de ficheros tipo loadadv*.exe.

Los rastros de este grupo nos conducen a Rusia, donde vive la mayoría de los miembros del grupo. En sus inicios, el grupo utilizaba muchos recursos de hospedaje en San Petersburgo. También colaboró con la tristemente célebre red RBN (Russia Business Network) que muchos especialistas asocian también con esta ciudad.

En sus cuatro años de existencia, el grupo ha creado uno de los sistemas de propagación de programas maliciosos más poderosos del mundo. Su red zombi, compuesta de millones de ordenadores infectados por diversos tipos de troyanos descargadores (encabezados por Tibs y Femad) es capaz de instalar en los ordenadores infectados cualquier programa malicioso nuevo en muy poco tiempo. Esta técnica es una alternativa eficaz a la propagación de códigos maliciosos mediante spam, un método que los desarrolladores de programas antivirus han aprendido a combatir de manera eficaz.

La red zombi IFrameBiz tuvo mucha participación en la propagación de nuevos programas maliciosos. El solicitante paga por cierto tiempo para que su troyano se propague mediante la red zombi. El “desborde” del programa puede entonces tener lugar. Por lo general, un descargador (por ejemplo, Tibs) instala varios troyanos de diferentes solicitantes. El servicio tiene mucha demanda y la ejecución simultánea de varias instrucciones no interfiere con los clientes.

Los autores de varios programas publicitarios recurrieron a los servicios de IFrameBiz, así como individuos deseosos de crear sus propias redes zombi, o propagadores de correo no deseado, organizadores de ataques de denegación de servicio, etc. Si se desea trazar un paralelo con RBN, podríamos decir que RBN es la fachada material y técnica de la actividad de los autores de virus, mientras que IFrameBiz es el programa y el botón de lanzamiento para un gran número de modernos programas maliciosos.

Y es precisamente a IFrameBiz a quien recurrieron los autores de Rustock.C durante el verano de 2007 solicitando difusión. Ya sea porque los troyanos de IFrameBiz no fueron capaces de activar discretamente Rustock en los sistemas, o porque los autores de la herramienta de rootkit no deseaban confiar al ejecutante el código de la herramienta rootkit para no poner en riesgo de robo sus tecnologías, lo cierto es que se creó un módulo completamente separado para el “derrame” a través de los canales de IFrameBiz.

Reconstrucción de los hechos

Tomemos un ejemplo concreto para ver lo que pasó a fines de septiembre de 2007 en uno de los ordenadores infectados pertenecientes a la red zombi IFrameBiz.

Un troyano descargador (probablemente Tibs) instalado en el sistema se conecta con uno de los servidores de la red zombi en la zona .hk (Croacia, el grupo empezó a utilizar los dominios de esta zona en 2007) e intenta descargar el archivo loadadv351.exe.

Este archivo es un módulo mejorado de la red zombi. Según la clasificación de Kaspersky Lab, se trata de Trojan.Win32.Inject.mt. Este nombre indica el objetivo de la acción del programa malicioso, que es introducirse en el proceso Explorer.exe evadiendo así los numerosos cortafuegos y habilitándose para descargar archivos en el sistema sin control alguno.

El troyano envía a los servidores de IFrameBiz información confirmando su exitosa instalación y recibe instrucciones sobre los archivos a descargar y desde dónde. Es así que funciona el sistema elemental de estadísticas de la red zombi que permite a los propietarios de la red monitorear el número de programas maliciosos descargados con éxito y obtener acceso a una serie de informes.

El troyano descarga desde el sistema varios archivos desde diversos servidores pertenecientes a los usuarios maliciosos, o desde los recursos que utilizan en los servidores de IFrameBiz. En el caso que nos concierne, los archivos se descargan desde los recursos de los clientes hospedados en IFrameBiz (http:// *.biz/progs/*). La recopilación y el envío de datos relativos al ordenador infectado (sistema operativo, disco duro, etc.) se producen de manera simultánea. Estos datos son necesarios para tener en cuenta el estado de la red zombi, su distribución geográfica, etc.

Algunos archivos suplementarios aparecen en el sistema, de los cuales dos, a los que llamaremos “1.exe “ y “2.exe”, son de particular interés para nosotros. Para comenzar, nos enfocaremos en “1.exe”, y luego haremos lo mismo con “2.exe”.

Se trata también de un descargador poco habitual. Kaspersky Lab descubrió la primera muestra el 10 de septiembre de 2007, el día de la aparición de las primeras versiones de Rustock. Esta coincidencia ya no es tan sorprendente, ¿no es cierto? El mismo día detectamos este descargador como Trojan-Downloader.Win32.Agent.ddl.

Este programa malicioso contiene un driver que se instala en el núcleo del sistema operativo (de hecho, ¡ya nos estamos enfrentado a una herramienta de rootkit!). El driver está codificado mediante un complejo algoritmo que se parece mucho al algoritmo utilizado para codificar Rustock.

Después de recorrer todos los velos de protección del driver, llegamos al punto más interesante: el descargador de Rustock es tan “mítico” como la misma herramienta de rootkit.

El eslabón perdido

Aunque los rumores sobre la herramienta de rootkit circulaban desde diciembre de 2006, la única mención del descargador y de su existencia se remonta a fines de octubre de 2007, casi dos meses después de su descubrimiento y de que lo agregásemos a nuestras bases de datos antivirus. Es necesario precisar que debido al carácter “indetectable” de Rustock.C en ese entonces, nadie había entrevisto la existencia de su descargador,

Sin embargo, incluso después del descubrimiento de Rustock.C, aunque faltaba encontrar su “dropper”, algunos desarrolladores de programas antivirus no llevaron la investigación más allá y se contentaron con haber detectado la herramienta de camuflaje de actividades. No querían perder tiempo en comprender la manera en que la herramienta de rootkit había llegado a sus ordenadores, o en saber si los usuarios estaban realmente indefensos frente al rootkit “indetectable”.

Nuestra investigación nos permitió responder a esas dos interrogantes. A partir del 10 de septiembre de 2007, después del primer día de propagación de Rustock.C a través de la red zombi IFrameBiz, Kaspersky Anti-Virus había detectado su “acompañante”, a saber, Trojan-Downloader.Win32.Agent.ddl. Posteriormente, varios desarrolladores de programas antivirus también descubrirían el troyano.

Durante algunos meses, la única manera de proteger los ordenadores contra una infección causada por la herramienta de rootkit “imperceptible” consistía en detectar oportunamente la presencia de su descargador.

Por desgracia, en el presente (principios de junio de 2008), algunos programas antivirus aún son incapaces de localizar Agent.ddl.

El descargador

Como dijimos previamente, el troyano está compuesto por dos elementos: el cuerpo y el driver. El driver recolecta información sobre el sistema: identifica los fabricantes y modelos de periféricos en la tarjeta madre, fecha de instalación y versión exacta del sistema operativo. Después, esta información se codificaba y se enviaba al servidor del autor de Rustock.C (o a los solicitantes): 208.66.194.215.

El servidor al que se envía los datos (208.66.194.215) es el mismo que descubrimos en la herramienta de rootkit DLL (spambot). Es de ahí de donde Rustock recibe los mensajes a difundir. Sin embargo, el método de interacción del driver del descargador con el servidor difiere del método utilizado en el spambot.

El driver Agent.ddl trabaja directamente con los periféricos TCP/IP desde el círculo cero, lo que significa que el tráfico saliente del ordenador infectado no se puede descubrir con la ayuda de algunos sniffers/cortafuegos. Agent.ddl establece la conexión en el puerto 443 y trata de ocultar los datos sobre los paquetes del protocolo HTTPS. En consecuencia, el investigador, aún si se intercepta el tráfico al nivel del gateway, no llega a comprender de manera inmediata que no se trata de algo en relación a HTTPS, sino simplemente de datos cifrados recolectados del ordenador infectado.

A continuación un ejemplo de un ordenador infectado presentado bajo la forma de datos HTTPS.

Además, la clave de codificación cambia con cada ejecución del driver. La complejidad del descubrimiento se debe a que el observador externo no conoce el algoritmo ni la llave de codificación.

Conviene remarcar que los autores del troyano descargador trataron claramente de complicar al máximo la vida de quienes deseaban estudiar el código del driver.

La dirección IP del servidor central y el puerto utilizado para comunicarse con el driver, se encuentran protegidos en el cuerpo del programa a fin de disimular su evidente presencia.

Los autores también se concentraron en el ofuscamiento del código. A continuación, a manera de ejemplo, una simple operación:

Después del ofuscamiento se convierte en:

Lo que antes apenas era una instrucción, ahora tiene 7. Uno ya se puede imaginar lo que se encontrará en las “entrañas” del driver.

Volvamos a la comunicación en la red. El código malicioso envía un paquete con los datos del ordenador infectado. En respuesta a estos datos, el ordenador a su vez envía un archivo especialmente codificado para este ordenador con una clave correspondiente al material del ordenador en el que se originó la petición.

De esta manera los autores arreglaron la cuestión del “dropper” que de haberse descubierto, estudiado o ejecutado, les habría evitado a los investigadores tener que “averiguar” la clave para analizar el código de la herramienta de disimulación de actividades.

El archivo generado por la herramienta de disimulación de actividades, el “propio cuerpo” se instala en el ordenador de la víctima, donde Agent.ddl lo activa en el sistema. Rustock.C infecta el driver primario del sistema operativo y con esto, la red zombi de difusión de correo no deseado adquiere otro ordenador.

Actualmente, el servidor se encuentra bloqueado. Todos los paquetes que se le envían son bloqueados por los “routers” de la red. Sin duda, esto significa que las autoridades competentes ya se han interesado por la mencionada dirección IP.

Conclusiones

La reconstrucción de los hechos que los expertos llevaron a cabo hacen evidente que la propagación activa de este rootkit tuvo lugar entre septiembre y octubre de 2007. Por una parte, la utilización de la red IFrameBiz con este fin pudo garantizarle una gran difusión. Por otra parte, los hechos referidos prueban que el carácter “indetectable” de la herramienta de rootkit estaba únicamente vinculado al alto grado de cifrado del código y a la utilización de una serie de astucias para luchar contra el desensamblaje del código, lo que complicó el trabajo de análisis de los expertos.

Los desarrolladores de programas antivirus tuvieron acceso a la herramienta de rootkit desde su puesta en circulación en Internet. La gran mayoría de los programas antivirus, con muy pocas excepciones, desde hacía ya bastante tiempo eran capaces de identificar su actividad una vez instalado en el sistema, así como reconocer los componentes responsables de su instalación y de su propagación. Se podía interceptar su aparición en el sistema al inicio mismo del proceso mediante algunas herramientas de monitoreo de las modificaciones realizadas en el sistema de archivos.

Todo esto sucedió con Rustock decenas de veces, pero sólo fue posible realizar un análisis en profundidad del código en mayo de 2008.

Rustock C es absolutamente real y no se trata de un mito. El mito es su carácter “indetectable” que no se basa en ningún principio sobrenatural de disimulación integrado en la herramienta, sino únicamente sobre los rumores que corrieron a fines de 2006 y que sólo sirvieron al juego de los autores del programa malicioso.

Cualquier herramienta de rootkit que se creara teniendo en cuenta las actuales herramientas de detección encontraría la manera de evitar la protección que estas herramientas brindan. El tema de la lucha a nivel del núcleo del sistema operativo depende en última instancia de la respuesta a una interrogante: ¿Quién será el primero en hacerse con el control: la herramienta de rootkit o el programa antivirus?

El autor de Rustock no deseaba crear una herramienta de rootkit indetectable, sino complicar al máximo el proceso de análisis de la herramienta después de su descubrimiento. Es precisamente este elemento el que garantizaba una ventaja temporal entre el periodo de difusión y el inicio de la detección del programa malicioso.

Sólo una pregunta permanece sin respuesta: ¿Por qué el autor de Rustock interrumpió la mejora de la herramienta y la difusión de nuevas versiones a mediados de octubre de 2007? ¿No significaba esto que se habría dedicado a un nuevo proyecto y que quizás en alguna parte existe “Rustock.D”?

No podemos responder a esta interrogante. De todas maneras, la misma existencia de un programa maliciosos de estas características, aun si no se lo descubre en algunos meses, no tiene ninguna influencia en la aparición diaria de decenas de miles de otros programas maliciosos que los programas antivirus neutralizan con éxito.

Mientras IFrameBiz y otros grupos similares, responsables de la propagación cotidiana de centenares de nuevos programas maliciosos, de la intrusión en numerosos sitios Internet y de decenas de epidemias, sigan existiendo en Internet, no podremos celebrar las victorias obtenidas en batallas locales.

P.D. Dijimos que Trojan.Win32.Inject.mt instalaba en el sistema dos archivos: 1.exe y 2.exe, pero no explicamos en qué consistía el segundo archivo.

Se trata de otra versión del troyano espía Sinowal. Ese mismo Sinowal que algunos meses después de los hechos descritos se constituyó en otro serio problema para los desarrolladores de programas antivirus y que entró en la historia como “bootkit”.

Rustock y Sinowal se propagaron de manera simultánea y a través de la misma red zombi. Las nuevas versiones de Rustock dejaron de aparecer a mediados de octubre de 2007. Las primeras muestras de “bootkit” se descubrieron un mes más tarde, en noviembre de 2007.

¿Se trata de una simple coincidencia?

Quizás un día podamos dar respuesta a esta interrogante.