Fanny Equation: “Yo soy tu padre, Stuxnet”

En la conferencia Virus Bulletin de 2010, los investigadores de Kaspersky Lab se asociaron con Microsoft para presentar sus hallazgos sobre Stuxnet. La presentación conjunta incluyó diapositivas con varias partes de Stuxnet, como los día-cero utilizados en el ataque.

Quizás el exploit día-cero más interesante de Stuxnet fue el exploit LNK (CVE-2010-2568) que le permitía propagarse a través de dispositivos USB e infectar incluso los equipos que tenían deshabilitada la función Autorun.

En la investigación de 2010 sobre Stuxnet, se descubrió que el exploit LNK se había utilizado anteriormente en otro programa malicioso, supuestamente un Zlob PE, que apuntaba a “fanny.bmp.

En 2010, muy pocos prestaron atención a un programa malicioso que usaba el exploit LNK anterior a Stuxnet. Zlob es una familia extensa de programas maliciosos, y este tipo de muestras de crimeware no suelen interesar a los investigadores que se enfocan en los exploits día-cero y en las operaciones con respaldo gubernamental.

Sin embargo, durante nuestra investigación del grupo Equation en 2014, creamos una detección especial para la librería de explotación del grupo, bautizado como “PrivLib”. Para sorpresa nuestra, esta detección fue activada por un gusano de 2008 que utilizaba el exploit LNK de Stuxnet para replicarse, bautizado como Fanny.

¿Qué es Fanny?

Este gusano impulsado por PrivLib, que se propaga mediante el exploit LNK de Stuxnet y con el nombre de archivo “fanny.bmp”, se compiló el lunes 28 de julio de 2008 a las 11:11:35, si es que podemos confiar en la marca de tiempo de la compilación. Llegó a nuestra colección de Internet de diciembre de 2008, por lo que los datos de la compilación pueden ser correctos.

“Fanny my name” podría ser un mensaje de presentación de los autores

Los productos de Kaspersky Lab detectan el gusano "Fanny.bmp" de 2008 como Trojan-Downloader.Win32.Agent.bjqt. Este programa malicioso incluye el exploit LNK, lo que significa que se trata de un programa malicioso que ¡usaba el exploit LNK de Stuxnet antes que apareciera Stuxnet!

El segundo exploit de Stuxnet (MS09-025)

Si un programa malicioso que utilizaba un exploit de Stuxnet antes de Stuxnet es una presa jugosa, uno que utilize un segundo exploit de Stuxnet lo es mucho más aún.

El segundo exploit era un día-cero cuando Fanny estaba activo. Esto significa que para replicarse Fanny usaba dos exploits día-cero que más tarde utilizó Stuxnet. La vulnerabilidad específica usada para la elevación de privilegios se parchó con MS09-025:

“La actualización de seguridad corrige estas vulnerabilidades modificando los métodos utilizados para validar un cambio en objetos específicos del núcleo, para la validación del input pasado del modo de usuario al núcleo, y para la validación del argumento pasado a la llamada del sistema. La actualización de seguridad también corrige una vulnerabilidad garantizando que el núcleo de Windows limpie punteros en condiciones de error”.

El mismo exploit se utilizó luego en un módulo inicial de Stuxnet de 2009, que se incrustaba en una versión binaria extensa utilizando la plataforma Flame. Ese módulo de Stuxnet, también conocido como “atmpsvcn.ocx”, o Resource 207, fue el vínculo técnico entre Stuxnet y Flame. šEsta historia la desarrollamos en este artículo.

Si bien la vulnerabilidad que explotan ambos módulos Stuxnet/Flame y Fanny es la misma, la implementación del exploit es diferente. El exploit en Stuxnet ataca a una versión de sistema operativo específica, mientras que Fanny está diseñado para uso universal y es capaz de ejecutarse en múltiples plataformas. Tiene un shellcode único y procedimientos de activación de exploits para:

  • Windows NT 4.0
  • Windows 2000
  • Windows XP
  • Windows 2003
  • Windows Vista, 2008 y posiblemente otros de la familia NT6.x

La implementación del exploit en Fanny es más compleja que en Stuxnet: en lugar de ejecutar una sola carga, sus autores crearon un marco de trabajo que ejecuta tantas cargas como deseen, remplazando un despachador de llamadas de servicio del sistema nt!NtShutdownSystem con su propio puntero personalizado desde el espacio del usuario, como se muestra en la siguiente figura:

Fanny inyectó su propio despachador de llamadas de servicios del sistema

Esto activa un trampolín persistente del modo usuario al modo núcleo. Esta función no estaba disponible en el módulo Stuxnet, pero hay otras similitudes. Por ejemplo, al parecer los desarrolladores de Stuxnet y los de Fanny siguen ciertos lineamientos de codificación, como el uso de números mágicos originales para cada llamada de función. La mayoría de los resultados producidos simplemente se descartan, pero siguen siendo parte del código. Podrían ser los restos de una versión de depuración del código que potencialmente podría registrar cada paso en el código para facilitar el seguimiento de un error durante las pruebas. En sistemas complejos en los que el núcleo y el código del espacio del usuario se ejecutan sin interacción, este parece un método lógico e incluso esencial. Una vez más, se encuentra implementado en el código Stuxnet y en Fanny. Veamos la siguiente figura.

Stuxnet (a la izquierda) y Fanny (a la derecha) usan valores mágicos de retorno

El programa malicioso Fanny

Entonces, ¿qué es Fanny en esencia? Se trata de un gusano USB con una puerta trasera sofisticada que utiliza la así llamada “vulnerabilidad LNK de Stuxnet” para ejecutarse automáticamente desde el dispositivo USB, incluso si Autorun está deshabilitado. Puede elevar los privilegios al sistema local usando vulnerabilidades en el núcleo, y descarga y registra módulos adicionales. Intenta conectarse a un servidor C&C e instala otros componentes si la conexión está disponible. En caso contrario, utiliza el dispositivo USB como portador para enviar/recibir peticiones a y desde el operador a través de un área oculta de almacenamiento creada en una estructura FAT pura.

Generalmente, la víctima inserta un nuevo dispositivo USB y lo abre con el Explorador de Windows. Es posible ver las dos etapas de infección desde el USB que se ejecutan en segundos.

Módulos de Fanny

MD5 0a209ac0de4ac033f31d6ba9191a8f7a
Tamaño 184320
Tipo Win32 DLL
Nombre interno dll_installer.dll
Compilado 2008.07.28 08:11:35 (GMT)

Este fichero es un DLL con dos exportaciones (para instalar y desinstalar el programa malicioso). Contiene un config cifrado con xor en recurso binario con el número 101. El config determina el comportamiento del programa malicioso: hay un comando para instalar programas maliciosos en el sistema actual, URLs para el servidor C&C y nombres de archivos locales y rutas utilizadas para instalar componentes embebidos del malware.

Componentes de Fanny dentro del ejecutable principal

Una vez que se inicia, verifica los siguientes Mutexes:

  • GlobalRPCMutex
  • GlobalRPCMutex <InstanceNum>

Donde <InstanceNum> es un número entero de 1-byte tomado del config. Si existe cualquiera de estos Mutexes, el código no se ejecutará. Esto significa que alguna otra instancia del mismo código se está ejecutando. InstanceNum muy probablemente identifica una variante o generación de Fanny, evitando así que una misma versión vuelva a infectar el sistema, pero permitiendo que diferentes versiones se ejecuten (posiblemente para activar la actualización forzada de sus componentes).

El módulo también verifica otro byte importante en su configuración. Este byte es un contador que disminuye durante la infección exitosa de un sistema. Cuando el contador alcanza un valor mínimo de uno, el módulo limpia la unidad USB y deja de propagar el gusano. De esta manera, los atacantes limitan la longitud máxima de la cadena de ataque del gusano.

Si el módulo tiene el nombre “fanny.bmp” (el nombre de archivo que Fanny utiliza para propagarse mediante unidades USB), se autoinstalará desde la unidad USB.

Como parte del proceso inicial de la infección, Fanny intentará elevar los privilegios actuales si el usuario no tiene derechos de administración en el sistema actual. Utiliza una vulnerabilidad parchada por MS09-025 para este propósito. Sólo si la elevación tiene éxito, el programa malicioso intentará conectarse a un servidor C&C usando una URL que está guardada en el config:

  • http://webuysupplystore[.]mooo[.]com/ads/QueryRecord200586_f2ahx.html

La siguiente es una muestra de los pedidos del programa malicioso:

GET /ads/QueryRecord200586_f2ahx.html HTTP/1.1
User-Agent: Mozilla/4.0 (compatible;)
Host: webuysupplystore.mooo.com

El programa malicioso espera del servidor C&C una respuesta HTTP 200 y añade caracteres cifrados en xor de 0x7f que contienen una URL de segunda etapa. La respuesta de segunda etapa puede contener el cuerpo de un archivo ejecutable que se guarda en el disco y se ejecuta.

En este momento, el servidor C&C es un cenote de Kaspersky Lab, pero según nuestros registros pDNS, anteriormente apuntaba a la siguiente direccione IP:

  • 210.81.22.239

Información IP

A continuación se describe las etapas que se identificaron durante el análisis de los componentes iniciales e embebidos de Fanny.

Infección

El módulo busca fanny.bmp en la carpeta raíz de las unidades de disco, empezando con la unidad D: y la copia en los siguientes lugares:

  • %WINDIR%system32comhost.dll
  • %WINDIR%system32mscorwin.dll

¿Por qué hace Fanny dos copias de sí mismo? En realidad, hay una pequeña diferencia entre estos dos ficheros. Fanny parcha su config en la sección de recursos de uno de los ficheros (comhost.dll). Los datos parchados son el valor de la extensión máxima que queda de la cadena de ataques de Fanny. “mscorwin.dll” es el archivo original copiado tal cual desde la unidad portátil. Hasta ahora, una copia se usa para infectar otras unidades USB, y la otra se carga al arrancar el sistema.

También copia todos los ficheros *.Ink desde la unidad USB a “%WINDIR%system32” para volver a usarlos para infectar otras unidades USB insertadas. Es posible que haya más de un fichero LNK, ya que cada LNK contiene una ruta distinta al DLL que se carga. Si se desconoce la letra de una nueva unidad en el sistema atacado, Fanny utiliza varios LNKs para las letras más comunes de LNKs. Este método se mejoró posteriormente en Stuxnet, que usaba una ruta dependiente relacionada con la identidad del dispositivo a la unidad USB. Sin embargo, incluso ese método requería varios ficheros LNK (hasta cuatro) debido a las diferentes rutas relativas en diferentes versiones de Windows, pero de todas formas su número es mucho menor que un conjunto casi completo de letras del alfabeto latino.

Persistencia

Fanny crea el siguiente valor de registro para lograr la persistencia:
HKLMSystemCurrentControlSetControlMediaResourcesacmECELP4Driver.

Esta no es una forma común de lograr que un código se inicie automáticamente al arrancar el sistema y es extremadamente invasivo, pero garantiza que el módulo se cargue en el espacio de dirección de cada proceso en el sistema, incluyendo algunos procesos críticos como lsass.exe y services.exe que se ejecutan como usuario SYSTEM.

Cuando el módulo se carga, verifica otros valores que comienzan con “filter” en la misma llave de registro, por ejemplo:

  • HKLMSystemCurrentControlSetControlMediaResourcesacmECELP4filter2
  • HKLMSystemCurrentControlSetControlMediaResourcesacmECELP4filter3
  • HKLMSystemCurrentControlSetControlMediaResourcesacmECELP4filter8

Los valores contienen un nombre de proceso de hosting y una ruta a un fichero DLL o EXE. Si el nombre del proceso actual contiene el valor establecido como proceso de hosting, entonces el módulo carga un DLL o inicia un nuevo proceso (en caso del fichero EXE), dependiendo de la extensión del fichero atacado.

Este es un mapa de los procesos y módulos que se usan en Fanny:

Proceso Módulos de Fanny Breve descripción
winlogon c:windowsMSAgentAGENTCPD.DLL puerta trasera USB
explorer c:windowssystem32shelldoc.dll rootkit para el Explorador de Windows
lsass c:windowssystem32mscorwin.dll gusano USB

Gusano USB

El código del gusano es parte de la exportación %WINDIR%system32comhost.dll con ordinal 4 (el nombre de la exportación es "dll_installer_4"). El DLL es un gusano modificado de próxima generación que se copia a cada unidad USB insertada con todos los archivos relacionados con LNK guardados en el directorio WindowsSystem32. Este módulo es distribuido por mscorwin.dll que es parte del proceso de sistema Isass.

Rootkit para el Explorador de Windows

Las funciones del rootkit las provee un fichero shelldoc.dll cargado en el proceso del Explorador de Windows. Oculta algunos archivos relacionados con Fanny (archivos LNK y Fanny.bmp) en el Explorador de Windows quitándolos de la lista de ítems en la ventana principal que usa el control SysListView32 (generalmente la ventana del Explorador de Windows).

Ya hemos mostrado algunas capturas de pantalla con ficheros que desaparecen; sin embargo, a veces este enfoque puede provocar sospechas. Así se ve cuando el usuario abre un directorio system32 con el Explorador:

Iconos de siete archivos relacionados con Fanny que desaparecieron en el Explorador de Windows

Aparentemente, tiene la apariencia de que recortaran los iconos de los archivos. Además, parece que faltan algunos directorios estándar debido a un problema en el código del rootkit. Al parecer, los autores no comprobaron apropiadamente este componente.

Modo Enmascarado Activado

El código del DLL de la puerta trasera USB tiene una parte interesante que a primera vista no parece tener mucho sentido. Toma algunas constantes de codificación estática (hardcoded) y genera un valor aleatorio que se guarda en una llave del registro.

Fanny genera valores aleatorios que se guardan en el registro

Después mueve el ejecutable que actualmente aloja al DLL a: c:windowssystem32msdtc32.exe. Luego se agrega la ruta del ejecutable al valor de registro HKLMSoftwareMicrosoftWindows NTCurrentVersionWinlogonShell, lo que hace que el ejecutable se ejecute en el arranque del sistema.

Esto puede parecer una forma tradicional para que el malware se agregue a autostart, pero no hay que dejarse engañar. El propósito de esta acción es hacerles creer a algunos sistemas y programas automatizados, como los basados en cajas de ejecución (sandbox) y emuladores, que han atrapado un programa malicioso desconocido y no dejar que se siga ejecutando. Parece que el componente es tan raro que sus autores decidieron evitar el riesgo de que levante más sospechas. Puede parecer paradójico, pero sus autores prefieren que se detecte este código como un programa malicioso. El truco es imitar el comportamiento de algunos programas maliciosos tradicionales, bots, y que se lo detecte tan pronto como sea posible, para no revelar sus actividades secretas. Considerando que este componente se propagó mediante unidades USB y que podría aparecer en muchos sistemas, al detectarlo como un bot tradicional se lo colocaría en una zona de bajo riesgo y en consecuencia se lo descartaría sin someterlo a mayor análisis.

Esto explicaría por qué se lo había detectado como una variante del programa malicioso Zlob, sin que nadie le prestara mayor atención.

Puerta trasera USB

Uno de los módulos, agentcpd.dll, es una puerta trasera diseñada para funcionar como una herramienta avanzada de búsqueda de inteligencia para ordenadores protegidos por segmentación física (air-gap) que son los que normalmente se usan en instalaciones con alta seguridad. Esta puerta trasera espera que se inserte una unidad USB y si es un disco nuevo, de inmediato asigna espacio para un contenedor vacío usando su propio controlador del sistema de archivos FAT16/FAT32.

Así se ve el directorio raíz FAT antes y después de insertar una unidad USB en un equipo infectado:

Vista hexadecimal de una participación de disco limpia antes y después de insertar una USB en un equipo infectado

En la parte superior de esta vista hexadecimal se encuentra la etiqueta de disco “MYDRIVE” (los correspondientes bytes hexadecimales están subrayados con verde). Le sigue un valor indicador de un solo byte (0x08 en hexadecimales) que, según Microsoft, significa ATTR_VOLUME_ID. Cada entrada en esta tabla de directorio raíz tiene 32 bytes de largo.

Las entradas de subdirectorio, como Pictures, Music, Documents y Work ocupan 63 bytes, debido a la característica de nombres largos de archivos FAT. šHay dos variantes de nombres de subdirectorios: cortos y largos. Una entrada de subdirectorio usa un indicador 0x10 a continuación de un nombre corto de directorio que, según Microsoft, significa ATTR_DIRECTORY.

El último registro insertado por Fanny (remarcado en rojo), usa un nombre de directorio inválido y un indicador 0x18 que combina ATTR_VOLUME_ID y ATTR_DIRECTORY. Esta combinación de indicadores no se documenta según las especificaciones vigentes FAT, y por lo tantoš los controladores del sistema de ficheros ignoran toda la entrada como si fuesen datos corrompidos o un bloque malo. En consecuencia, esta entrada no es visible en Windows, Mac OS, y Linux, y probablemente todas las otras implementaciones del controlador FAT.

Aunque Fanny no protege rigurosamente los datos en su almacenamiento oculto (no marca el espacio asignado como bloques malos, probablemente para evitar su detección), si cambia el valor indicador del controlador del sistema de archivos que señala donde buscar el siguiente grupo libre. De esta manera reserva un espacio de aproximadamente 1Mb en el disco para usarlo como un almacenamiento oculto.

Cuando Fanny detecta una nueva unidad USB, con su propio controlador FAT revisa el directorio raíz y encuentra la entrada que comienza con el valor mágico 51 50 40 98 (ver arriba). Entonces usa el offset que sigue al valor indicador de 0x18. En la figura de arriba está establecido en 0x001e9c00. Este offset en el mismo disco USB señalara otro valor mágico D0 CF CE CD que sirve como marcador del comienzo del almacenamiento oculto:

Vista hexadecimal del almacenamiento oculto de Fanny con una lista de los procesos en ejecución

Una vez que Fanny le ha asignado espacio al almacenamiento oculto, llena este compartimento con información básica sobre el sistema actual, como: versión del sistema operativo, número de Service Pack, nombre del ordenador, nombre de usuario, nombre de la compañía, lista de procesos en ejecución, etc.

El almacenamiento secreto también se usa para pasar comandos a ordenadores que no están conectados a Internet. Según el código de Fanny, el contenedor puede incluir componentes adicionales y comandos internos, como copiar determinado archivo desde el sistema de archivos local a la unidad USB (sus ubicaciones se definen como parámetros, el archivo se marca oculto y atributos de los archivos del sistema) o actualizar el bloque de configuración. Usa RC4 con la siguiente llave con codificación estatica para proteger los datos críticos:

18 05 39 44 AB 19 78 88  C4 13 33 27 D5 10 6C 25

Cuando la unidad USB se inserta en otro equipo infectado conectado al Internet, puede usarse para extraer archivos importantes y proporcionar una forma de interactuar con el operador. Este método sencillo y extremadamente lento de comunicación no es común entre los cibercriminales tradicionales; es por eso que el código parece una caja de herramientas para el ciberespionaje profesional. Este componente es una de las raras muestras de malware de una clase nueva llamada USB-Backdoors.

Si encuentras este o un código similar de USB-Backdoor en alguno de tus sistemas, se trata de un indicador de un ciberataque profesional.

Estadísticas de cenotes y víctimas

We sinkholed the Fanny C&C server and collected victim statistics, shown below. In total, we observed over 11,200 unique IPs connecting to the sinkhole server over a period of five months:

Por ahora, la gran mayoría de las víctimas se encuentran en Paquistán (un asombroso 59,36%). Muy por detrás se encuentran Indonesia y Vietnam, con el 15,99% y el 14,17%, respectivamente. Las cifras de la infección en otros países son probablemente muy pequeñas para tenerlas en cuenta.

Por supuesto, esto podría plantear la interrogante: ¿Era Paquistán el verdadero blanco de Fanny? Para ser honestos, no lo sabemos. El estado actual de la infección puede diferir de lo que era en 2008-2010. Considerando que todavía hay más de 10.000 víctimas en todo el mundo, las cifras en 2009 pueden haber sido muchísimo mayores, quizás incluso bordeando las 50.000. Puede ser relevante que Paquistán (junto a Rusia e Irán), sea un blanco primordial para otros programas maliciosos del grupo Equation.

Conclusión

Con Fanny comenzamos otro capítulo más en la historia de Stuxnet, el grupo Equation, y Flame. Creado en 2008, Fanny utilizó dos exploits día-cero. Estos dos se añadieron a Stuxnet en junio de 2009 y marzo de 2010. De hecho, esto significa que el grupo Equation tenía acceso a estos día-cero (y otros) años antes de que lo tuviera el grupo Stuxnet.

Si bien aún se desconoce el verdadero blanco de Fanny, su singular capacidad de mapear redes con protección de segmentación fisica (air-gap) y de comunicarse mediante unidades USB muestra que mucho esfuerzo se invirtió en lograr penetrar estas redes con protección air-gap. Como precursor de las versiones de Stuxnet que podían replicarse a través de la red, es posible que Fanny se usara para mapear algunos de los futuros blancos de Stuxnet.

Otro hecho raro es la gran cantidad de infecciones en Paquistán. Puesto que Fanny se propaga sólo a través de unidades USB, que es un proceso lento, esto indica que la infección comenzó en Paquistán, posiblemente antes que en muchos otros países.

¿Se utilizó Fanny para mapear algunas redes altamente sensibles en Paquistán, con un propósito desconocido, o sirvió para preparar Stuxnet? Quizás el tiempo lo diga.

Publicaciones relacionadas

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *