Stuxnet: Analizando su funcionamiento

La primera ciberarma digital que llegó a infectar a más de 300.000 equipos en más de 100 países distintos era una bomba de 500 KB desarrollada para ralentizar el enriquecimiento de uranio en la central nuclear de Natanz ubicada en Irán. Continuando con la serie de capítulos del libro Countdown to Zero Day de Kim Zetter veremos realmente cómo funcionaba esta obra de ingeniería.

Como cualquier otro malware, la primera ciberarma digital se puede dividir en dos partes. Por un lado, el payload que se encarga de propagar el virus por diferentes equipos, y por otro lado el payload que se encarga de robar información o hacer cualquier otra cosa, en este caso atacar sistemas PLC de Siemens.

Stuxnet, como así se llama la ciberarma, lo primero que hacía era comprobar si la máquina donde se iba a desplegar era de 32 o 64 bits, ya que este malware tan solo funcionaba sobre máquinas Windows de 32 bits. Después, comprobaba si la máquina ya estaba infectada, si era así, comprobaba si existía alguna actualización de Stuxnet para descargarse la última versión disponible. En cambio, si la máquina aún no estaba infectada procedía a determinar la mejor manera para infectarla.

Para infectar la máquina se pone en marcha un rootkit que esconde los archivos de Stuxnet al sistema operativo, de esta manera los nombres de los archivos de Stuxnet no podían ser vistos por los motores de antivirus y no eran analizados. Si un escáner de malware intentaba leer el contenido de la memoria USB que estaba infectando la máquina, el rootkit interceptaba los comandos y devolvía una lista modificada de los archivos que contenía la memoria USB, obviamente eliminando de la lista los nombres de los ficheros de Stuxnet para que no fuesen analizados. Sin embargo, Stuxnet no podía hacer un bypass de todos los motores de antivirus, así que para aquellos motores que no podía controlar la infección, Stuxnet se paraba y se terminaba la infección.

A continuación, si Stuxnet decidía proceder porque podía hacer un bypass del antivirus se activaba un segundo driver con dos tareas. La primera tarea consistía en infectar cualquier otra memoria USB que estuviera conectada. La segunda, y más importante, era descifrar y cargar la biblioteca .DLL, y varios de sus componentes, en memoria. A continuación descomprimía la DLL para obtener otras DLL más pequeñas. Una vez que todas las DLL estaban en memoria, Stuxnet buscaba otras máquinas para propagarse y después se ponía en contacto con el C&C. Obviamente, como todas las DLL estaban en memoria cada vez que el equipo se reiniciaba se borraban, así que el driver en cada reinicio tenía que volver a cargar las DLL a memoria.

Posteriormente el malware hacía un inventario del software instalado en la máquina y lo enviaba al C&C, si no encontraba ningún software de Siemens ni el WinCC, Stuxnet quedaba inactivo. Si por el contrario encontraba software de Siemens, concretamente Siemens Step 7, y/o el WinCC, buscaba las PLC S7-315 y S7-417 de Siemens. Sólo esta combinación de hardware y software hacían posible descifrar y lanzar el ataque.

A continuación podemos ver las fases del ataque:

 

Además de la manera de cómo evitar los antivirus y la forma de cargar los archivos en memoria, Stuxnet monitorizaba los recursos de la máquina infectada para comprobar si la ejecución del malware sobrecargaba la máquina. Si Stuxnet utilizaba demasiada CPU o memoria podría ser detectado. Stuxnet también eliminaba los archivos temporales que no necesitaba para pasar desapercibido.

Encontrar evidencias suficientes para conocer el origen del malware es algo muy complicado a no ser que los propios desarrolladores dejen alguna "pista". Algunos desarrolladores utilizan técnicas para que sus propios equipos no se infecten con su propio malware, para ello antes de infectar un equipo el malware realiza una serie de comprobaciones para conocer si la máquina que va a infectar pertenece al desarrollador. Stuxnet parece que tenía algo parecido, antes de infectar la máquina comprobaba un registro de Windows y si dentro de ese registro se encontraba la cadena 0x19790509, la máquina no era infectada. Inmediatamente los investigadores se pusieron a investigar qué podría significar esta cadena. Una hipótesis dice que la cadena pertenece a una fecha, concretamente el 9 de Mayo de 1979, fecha que coincide con la ejecución de Habib Elghanian, un importante hombre de negocios de la comunidad judía en Irán. Tras su muerte muchos judíos migraron hacia Israel.

Otra evidencia que se encontró en el código de Stuxnet que hace pensar que Israel está detrás de su desarrollo fue que el compilador del malware dejó rastro del path donde se encontraba el proyecto. Concretamente la cadena b:\myrtus\src\objfre_w2k_x86\i386\guava.pdb que nos indica que el nombre de usuario de la máquina es myrtus, que coincide con el nombre hebreo de la reina judía que evitó una masacre de judíos en el imperio persa.

Otra hipótesis del significado de myrtus puede significar My RTUs, haciendo referencia a Unidades de Terminal Remoto que son componentes usados para monitorizar y operar equipamiento industrial.

Sea cual sea la verdad, la especulación de quién está detrás de este sofisticado ataque está abierta para todos los investigadores.