FinSpy: nuevos hallazgos

FinSpy, también conocido como FinFisher o Wingbird, es un conocido conjunto de instrumentos de vigilancia. Kaspersky lleva rastreando las implementaciones de este software espía desde 2011. Su implante para Windows solía distribuirse a través de un instalador de una sola etapa. Esta versión fue detectada e investigada varias veces hasta 2018. Desde ese año, observamos la disminución de la tasa de detección de FinSpy para Windows. Si bien la naturaleza de esta anomalía se mantuvo desconocida, comenzamos a detectar algunos instaladores sospechosos de aplicaciones legítimas, que contenían una puerta trasera con un descargador ofuscado relativamente pequeño. No logramos entender qué tenían en común esos paquetes hasta mediados de 2019, cuando encontramos un host que distribuía estos instaladores entre los implantes de FinSpy Mobile para Android. En el transcurso de nuestra investigación, descubrimos que los instaladores ocultos no son más que implantes de primera etapa que se utilizan para descargar e instalar otras cargas útiles antes que el troyano FinSpy propiamente dicho.

Aparte de los instaladores troyanizados, también observamos infecciones que implicaban el uso de un bootkit para UEFI o MBR. Aunque la infección del MBR se conoce desde al menos 2014, en este artículo revelamos por primera vez los detalles del bootkit para UEFI.

Hemos decidido compartir algunos de nuestros hallazgos sobre el estado real de los implantes FinSpy. Cubriremos no sólo la versión para Windows, sino también las versiones para Linux y macOS, ya que tienen muchas similitudes en su estructura interna y código.

Los detalles completos de esta investigación, así como las futuras actualizaciones de FinSpy, están disponibles para los clientes del servicio de informes APT a través de nuestro Threat Intelligence Portal.

Contacto: intelreports@kaspersky.com

Infección de la UEFI

Durante nuestra investigación, encontramos un bootkit para la UEFI que cargaba FinSpy. En todos los equipos infectados por el bootkit para UEFI, el Administrador de arranque de Windows (bootmgfw.efi ) había sido sustituido por uno malicioso. Cuando la UEFI transfiere la ejecución al cargador malicioso, primero busca la ubicación del Administrador de arranque de Windows original, que se encuentra dentro del directorio efi\microsoft\boot\en-us , con un nombre conformado por caracteres hexadecimales. Este directorio contiene dos archivos más, el Inyector de Winlogon y el Descargador troyano. Ambos están están cifrados con RC4. La clave de descifrado es el GUID de la partición del sistema EFI, que difiere de una máquina a otra.

Ejemplo del contenido del directorio \efi\microsoft\boot\en-us

Una vez encontrado el bootloader original, se lo carga en la memoria, parcha y lanza. El lanzador parchado ejecuta las siguientes acciones:

• Parcha la función del cargador del SO que transfiere la ejecución al kernel
• La función parchada captura la función PsCreateSystemThread del kernel, que, cuando se llama por primera vez, crea un subproceso adicional que descifra la siguiente etapa del cargador y la ejecuta.

La siguiente etapa:

• Localiza el archivo descargador troyano en la partición EFI y lo descifra
• Espera a que un usuario se conecte e inyecta el descargador troyano en exe.

El descargador troyano:

• Extrae el troyano de los recursos y lo guarda bajo el nombre dll
• Descifra el troyano con una cifra basada en XOR y lo desempaqueta con aPLib
• Carga y ejecuta el troyano de forma reflexiva.

Infección de la MBR

Las máquinas más antiguas que no tienen UEFI pueden infectarse a través del MBR. Cuando la máquina víctima arranca, el MBR infectado copia el código del cargador inicial desde el último megabyte del disco duro a la memoria más alta disponible situada antes del EBDA¹. Este código captura las interrupciones 13h y 15h de la BIOS y luego lanza el MBR original. La interrupción por 15h asegura que el cargador de Windows no sobrescriba el código copiado. Cuando se llama esta interrupción para obtener el tamaño del área antes de la EBDA, el enlace reducirá la cantidad de memoria disponible. En cuanto al enlace de interrupción por 13h (encargada de la lectura de información del disco), parcha el cargador del SO cuando se lee del disco. Al igual que en el caso de la infección de EFI, las funciones capturadas colocan sus propios enlaces en las siguientes etapas de carga del sistema operativo. El último enlace de la cadena crea un subproceso en el kernel que inyecta la siguiente etapa en winlogon.exe.

En caso de que la infección se instale en una máquina de 32 bits, el proceso de inyección de código en winlogon.exe es más complejo que el observado en la infección de UEFI. Ocurre así:

• Se crea un subproceso con shellcode de trampolín dentro de exe.
• Este shellcode duplica el handle del proceso exe y lo transfiere a explorer.exe.
• El shellcode inyecta otro shellcode de trampolín en Explorer.
• El segundo shellcode hace que exe inyecte el descargador troyano en winlogon.exe.

Esta forma indirecta de inyectar código pretende engañar a las soluciones de seguridad.

El descargador troyano inyectado es el mismo que el de la UEFI.

Infección en modo de usuario

Panorama general

Esta infección es la más compleja. En resumen, el escenario de ataque es el siguiente:

• La víctima descarga una aplicación troyanizada y la ejecuta.
• Durante su funcionamiento normal, la aplicación se conecta a un servidor C2, descarga y ejecuta un componente no persistente llamado Pre-Validador. El Pre-Validador comprueba que la máquina víctima no se utilice para el análisis de malware.
• El Pre-Validador descarga del servidor C2 los shellcodes de seguridad y los ejecuta. En total, despliega más de 30 shellcodes. Cada shellcode recoge información específica del sistema (por ejemplo, el nombre del proceso actual) y la sube al servidor.
• En caso de que una comprobación falle, el servidor C2 termina el proceso de infección. De lo contrario, continúa enviando shellcodes.
• Si se pasan todas las comprobaciones de seguridad, el servidor envía un componente que llamamos Post-Validador. Se trata de un implante persistente que probablemente se utilice para asegurarse de que la víctima sea la prevista. El Post-Validador recoge información que le permite identificar la máquina víctima (procesos en ejecución, documentos abiertos hace poco, capturas de pantalla) y la envía a un servidor C2 especificado en su configuración.
• Dependiendo de la información recogida, el servidor C2 puede ordenar al Post-Validador que instale la plataforma troyana completa o que elimine la infección.

Resumen de la infección en modo usuario

Aplicaciones troyanizadas

A lo largo de nuestra investigación, identificamos numerosas aplicaciones legítimas con puertas traseras de FinSpy. Los ejemplos incluyen instaladores de software (por ejemplo, TeamViewer, VLC Media Player, WinRAR), así como aplicaciones portátiles.

Todas las muestras de aplicaciones observadas tienen su firma digital original, pero no es válida, lo que indica que la aplicación ha sido parchada. Mientras que la función de punto de entrada de la aplicación parece clara, la inspección de las secciones del archivo PE del ejecutable revela anomalías: la aplicación con la puerta trasera tiene ampliada su última sección (.rsrc en la captura de pantalla de abajo) en 51 KB.

Secciones de la aplicación original (izquierda) y de la aplicación con puerta trasera (derecha)

Aparte de eso, una parte del código de la sección .text (aproximadamente 8 KB) está sobreescrita con código fuertemente ofuscado, y el código original de la aplicación está puesto en la última sección expandida.

Cuando se lanza la aplicación con puerta trasera, se ejecuta normalmente, es decir, el código ofuscado insertado no afecta el funcionamiento de la aplicación. En algún momento la aplicación ejecuta una instrucción de salto que redirige la ejecución al trampolín ofuscado en la sección .text. Esta instrucción parece estar colocada al azar en el código. Por ejemplo, sustituye una llamada a la función CreateWindowExW:

El código original (izquierda) y el parchado (derecha) de la aplicación con puerta trasera

Este trampolín está protegido con un ofuscador que hemos denominado FinSpy Mutator. Ejecuta un código que:

• Descifra y ejecuta un stager de Metasploit Reverse HTTPS ligeramente modificado. El procedimiento de descifrado:
  • Está ofuscado con FinSpy Mutator
  • Implica que se apliquen 10 operaciones (ADD, SUB, XOR, ROL, ROR) a cada byte del stager
  • Es diferente en cada instalador con puerta trasera.
• Restaura el código en la sección .text que fue sobrescrito con el código malicioso (recuerdemos que el código original se guarda en la sección de recursos)
• Resuelve las reubicaciones en el código restaurado
• Restaura la instrucción que ha sido sobrescrita con un salto
• Salta a la instrucción restaurada, reanudando así la ejecución de la aplicación original.

Para comunicarse, el stager de Metasploit se conecta a un servidor C2 configurado utilizando HTTPS. En el caso de 5EDF9810355DE986EAD251B297856F38, el stager envía la siguiente solicitud GET al servidor C2:

El servidor C2 responde a la solicitud GET con un componente que llamamos Pre-Validador. El stager de Metasploit lo ejecuta.

El Pre-Validador

El Pre-Validador es un shellcode ofuscado por medio de FinSpy Mutator. Durante el arranque, hace lo siguiente:

• Enlaza las funciones NtTerminateProcess y ExitProcess para asegurarse de que el Pre-Validador siga funcionado si la aplicación retroalimentada se cierra. Las funciones de enlazamiento cierran todas las ventanas de la aplicación, pero no terminan su proceso.
• Realiza una solicitud POST inicial al servidor C2. Ejemplo de la URL de solicitud: https://45[.]86[.]163[.]138/blog/index.asp?attachmentid=a46dee635db8017962741f99f1849471&d=5d7e89e6b4874d0df95141bd923556f8 (todas las partes de esta URL varían entre las muestras). Todas las comunicaciones entre el servidor se cifran con RC4.

La respuesta a la solicitud POST inicial contiene un shellcode que hemos llamado Shellcode de seguridad. Al recibirlo, el Pre-Validador:

• Descifra y ejecuta el Shellcode de seguridad recibido
• Envía los resultados de la ejecución del shellcode al servidor C2 mediante una solicitud POST.
• Recibe el siguiente shellcode de seguridad del servidor C2 y repite los pasos anteriores.

La naturaleza de estos shellcodes indica que se utilizan para tomar una huella digital del sistema y verificar que no se los utilice para el análisis de malware. Es importante destacar que los shellcodes sólo recogen los datos; todas las comprobaciones se realizan del lado del servidor. En caso de que un shellcode cargue resultados de ejecución sospechosos (por ejemplo, el Pre-Validador se está ejecutando en una máquina virtual), el servidor envía un shellcode que termina el Pre-Validador.

Los shellcodes recibidos están protegidos por FinSpy Mutator o por un ofuscador parecido a OLLVM, o por ambos. En total, observamos 33 Shellcodes de seguridad enviados por el servidor (listados en orden de ejecución):

Shellcode #	Descripción
1	Busca un hipervisor con la instrucción CPUID (EAX = 1). Si lo detecta, devuelve el nombre del hipervisor (EAX = 0x40000000), de lo contrario devuelve cero bytes.
2	Comprueba si el proceso actual necesita ser suplantado (por ejemplo, si un usuario sin privilegios ejecuta la aplicación con la puerta trasera como administrador).
3	Devuelve la carpeta del perfil del usuario (por ejemplo, C:\Usuarios\nombre de usuario)
4	Devuelve la forma abreviada de la carpeta del perfil del usuario (por ejemplo, C:\Usuarios\abcdef~1)
5	Devuelve el tipo de la unidad que contiene la aplicación con la puerta trasera (por ejemplo, unidad extraíble)
6	Devuelve los nombres de los procesos del árbol de procesos actual (es decir, el proceso actual, el proceso padre, el proceso abuelo, etc.)
7	Devuelve la ruta de la carpeta ‘Archivos de programa’.
8	Para la unidad del sistema, vuelve: Espacio total disponible Espacio disponible para el usuario actual (puede ser menor que el espacio total disponible debido a las cuotas) Capacidad del disco
9	Devuelve la ruta de la carpeta temporal del usuario.
10	Devuelve la lista de tipos de adaptadores de red y las direcciones IP y MAC que tienen asignadas.
11	Devuelve la lista de procesos en ejecución
12	Devuelve el valor de ProcessDebugPort, a su vez devuelto por NtQueryInformationProcess para el proceso actual.
13	Devuelve el valor de ProcessDebugObjectHandle , a su vez devuelto por NtQueryInformationProcess para el proceso actual.
14	Devuelve  los valores TotalNumberOfObjects y TotalNumberOfHandles de los objetos creados por NtCreateDebugObject.
15	Devuelve el SID del usuario actual.
16	Devuelve la lista de imágenes (archivos EXE/DLL) cargadas en el proceso actual.
17	Devuelve  las estructuras OSVERSIONINFOEXW y SYSTEM_INFO.
18	Devuelve información sobre la BIOS de la máquina.
19	Devuelve la lista de nombres de objetos en el directorio \GLOBAL??
20	Devuelve información sobre el sistema operativo.
21	Devuelve el nombre del usuario actual, el nombre del equipo, la ruta del ejecutable actual, su nombre y la ruta de la línea de comandos.
22	Devuelve la lista de controladores cargados.
23	Devuelve la lista de rutas PDB de los controladores cargados
24	Devuelve los primeros 16 bytes de la primera función Zw* exportada de ntdll.dll (ZwAcceptConnectPort)
25	Verifica la firma del proceso padre.
26	Devuelve información sobre los dispositivos Plug and Play conectados.
27	Devuelve información sobre el sistema del equipo (desde la consulta WMI SELECT * FROM Win32_ComputerSystem)
28	Devuelve la lista de dispositivos PCI conectados.
29	Devuelve los nombres de los accesos directos en el directorio del Escritorio.
30	Devuelve la lista de nombres de clases de ventanas de nivel superior y secundarias que no son propiedad del proceso actual o del proceso principal.
31	Devuelve la lista de títulos de ventanas de nivel superior y secundarias que no son propiedad del proceso actual o del proceso principal.
32	Devuelve el SID del dominio actual.
33	Limpia las funciones de la API potencialmente controladas por las soluciones de seguridad: funciones Nt* en ntdll.dll y todas las funciones exportadas en kernel32.dll, kernelbase.dll y advapi32.dll.

Una vez que se han superado todas las comprobaciones de seguridad, el servidor C2 envía un código shell que descarga y ejecuta el Instalador Post-Validador.

El instalador del Post-Validador

Este módulo es un shellcode ofuscado. Hace lo siguiente:

• Crea un subdirectorio (el nombre difiere entre las muestras) en el directorio C:\ProgramData
• Guarda dos archivos en el subdirectorio recién creado:
  • La DLL del cargador Post-Validador
  • Un shellcode con el propio Post-Validador.

  Los nombres de los archivos están cifrados en el dropper, pero son únicos para cada muestra y parecen ser generados al azar.

• Crea una tarea programada que se ejecuta al inicio del sistema y lanza el cargador del Post-Validador a través de regsvr32 (acción de la tarea: %windir%\syswow64\regsvr32.exe /s “<ruta al DLL del cargador>”)

Una vez instalado el Post-Validador, el Pre-Validador se desactiva.

El cargador Post-Validador

El cargador Post-Validador es un enorme (3-9 MB) DLL ofuscado. El programador de tareas lo lanza al inicio del sistema a través de regsvr32.exe. Su función principal tiene un tamaño de varios megabytes, pero su propósito es simple: leer y ejecutar un shellcode que se almacena en el mismo directorio que el cargador Post-Validador.

Ejemplo de propiedades de una tarea programada

El shellcode lanzado descifra el Post-Validador (se almacena en el mismo archivo con el shellcode) con RC4 (clave: SID del dominio) y lo carga de forma reflexiva.

El Post-Validador

El Post-Validador es una DLL ofuscada con VMProtect. Este módulo utiliza el mismo protocolo de comunicación que el componente principal del troyano:

• El formato TLV (tipo-longitud-valor) para intercambiar datos con los servidores C2
• Las constantes de tipo TLV que se encuentran en el Troyano
• La biblioteca criptográfica del troyano para cifrar o descifrar los datos intercambiados

Al iniciarse, el Post-Validador verifica que no se lo haya lanzado dentro de un entorno aislado. A continuación, inicia la comunicación con los servidores C2 especificados en su configuración, enviando mensajes de latido a intervalos de 15 minutos. Cada latido incluye una breve información sobre la máquina víctima.

La respuesta del latido puede contener diferentes comandos.

TLV ID	Propósito del comando (deducido del troyano principal)	Implementación del comando en el Post-Validador
0x8030A0	Recupera la configuración del implante.
0x8070A0	Recupera la lista de archivos con datos preparados para la extracción.	Devuelve tres cadenas en un TLV: 243a, 201a y 201b (nombres de archivos de datos “virtuales”)
0x8072A0	Sube al servidor C2 un archivo preparado con un nombre especificado.	Si el nombre del archivo preparado es: 201a, obtiene la lista de procesos y la envía al servidor C2. 201b, obtiene la lista de archivos recientes y la envía al servidor C2. 243a, hace una captura de pantalla y la sube al servidor C2.
0x8054A0, 0x805BA0, 0x8056A0, 0x805DA0, 0x8057A0, 0x805EA0	Los comandos se utilizan para descargar e instalar complementos.	Los comandos se utilizan para descargar y ejecutar el instalador de troyanos.
0x801530, 0x801630, 0x801730, 0x8018A0	Desinstala el troyano.	Desinstala el Pre-Validador.
0x7502A0	Se desconecta del servidor C2.

Cuando el Post-Validador recibe el instalador del troyano (que es una DLL), hace lo siguiente:

• Carga e inicia el instalador de forma reflexiva
• Dependiendo de la configuración, se desinstala (borrando su directorio y la tarea programada) o entra en reposo hasta el reinicio del sistema.

A partir de los datos recogidos por el Post-Validador, lo más probable es que:

• Se despliegue el Post-Validador para comprobar que la víctima infectada es la prevista.
• El operador del servidor C2 analiza manualmente los datos recibidos de la víctima y ordena eliminar el Post-Validador o infectar la máquina con el troyano.

El Post-Validador es otro obstáculo para los investigadores. Incluso si consiguen pasar todas las comprobaciones del Pre-Validador, el operador del servidor C2 puede negarse a infectar una máquina sospechosa.

El Instalador de troyanos

El instalador crea el directorio de trabajo (ruta: %localappdata%\Microsoft<dos palabras concatenadas en inglés>) y lo establece como accedido, modificado y creado un año antes. Después, guarda allí los siguientes archivos:

Nombre de archivo	Descripción
<4 caracteres hexadecimales aleatorios>.cab	El archivo de configuración de la instalación, que está cifrado con RC4 (clave: el nombre del directorio de trabajo).
Los nombres difieren entre las muestras	El archivo VFS cifrado.
	El Cargador inicial.
msvcr90.dll	El paquete troyano, cifrado con XOR y comprimido con aPLib.
msvcr120d.dll	Cargador de troyanos de 64 bits. Al ejecutable se le añaden 0x4000 bytes aleatorios y se cifra con RC4 (clave: GUID de la máquina)
msvcr140d.dll	Cargador de troyanos de 32 bits, también precedido de bytes aleatorios y cifrado con RC4.

Las marcas de tiempo de los archivos eliminados se fijan un año antes de la fecha actual. Una vez preparado el directorio de trabajo, el instalador lanza el troyano.

El Cargador inicial

El Cargador inicial es una DLL que se lanza en cada inicio mediante rundll32.exe (el troyano lo añade a la clave HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, el nombre del valor es único para cada muestra). El tamaño del cargador inicial supera los 5 MB. Está ofuscado con un protector parecido al ofuscador OLLVM de código abierto. A pesar de su tamaño, la única funcionalidad del cargador inicial es descifrar y lanzar el descargador troyano de 32 bits.

El Cargador de troyanos

El cargador de troyanos de 32 bits, que se lanza independientemente de la arquitectura de la máquina víctima, comprueba si se está ejecutando en un sistema de 64 bits. Si es así, lee el cargador de 64 bits (msvcr120d.dll) del disco y lo ejecuta como un shellcode.

El cargador de troyanos (ya sea el de 32 bits o el de 64 bits):

• Lee el archivo troyano empaquetado (msvcr90.dll), lo descifra con XOR y lo desempaqueta con aPLib.
• Inyecta la DLL del troyano en exe llamando a CreateRemoteThread o utilizando la técnica KernelCallbackTable.

Infección de MacOS

La versión de macOS del malware no es tan complicada como la de Windows. Está escrito en Objective-C. Utiliza un ofuscador similar a OLLVM para proteger FinSpy para Mac. Además, los selectores de Objective-C que pueden revelar información sobre los nombres de los métodos contienen basura.

La versión para macOS de FinSpy tiene los siguientes componentes:

• El Instalador (a diferencia de la versión de Windows que cuenta con numerosos instaladores, la versión de macOS sólo tiene un tipo de instalador).
• El Cargador inicial.
• El Cargador de troyanos.
• El troyano, formado por el Orquestador, la Biblioteca de Criptografía y los complementos.

El Instalador

Cuando la víctima ejecuta la aplicación maliciosa, se lanza un ejecutable ubicado en la ruta <nombre de la aplicación maliciosa>.app/Contents/MacOS/installer. Al iniciarse, revisa el entorno en busca de depuradores y máquinas virtuales. Guarda los siguientes archivos en la máquina:

Ruta	Descripción
/Librería/Frameworks/Storage.framework	Un directorio con el troyano dentro
/privado/etc/logind	El cargador de troyanos que se ejecuta como agente de ejecución. Este archivo se ejecuta al inicio.
/Library/LaunchAgents/logind.plist	La configuración del agente logind. El troyano lo necesita para mantener la persistencia.

Todos los archivos copiados tienen una marca de tiempo (la fecha de modificación es la marca de tiempo de Finder.app). El instalador establece que su propietario es root:wheel. Además, establece los bits SUID y SGID del archivo /private/etc/logind.

Al copiar el archivo logind.plist en el directorio /Library/LaunchAgents, el instalador configura el troyano para que se cargue al inicio.

El instalador ejecuta entonces el ejecutable logind (descargador troyano) con la utilidad launchctl.

El Cargador inicial

El cargador inicial (/private/etc/logind) se ejecuta cada vez que el sistema operativo arranca. Una vez ejecutado, el cargador inicial ejecuta el cargador de troyanos (/Library/Frameworks/Storage.framework/Contents/MacOS/logind).

El Cargador de troyanos

El Cargador de troyanos tiene una función constructora que se invoca antes de main. Establece enlaces en funciones que cargan paquetes de aplicaciones. Estos enlaces permiten al troyano cargar complementos mientras los descifra sobre la marcha.

Una vez colocados los enlaces, el cargador de troyanos lanza el orquestador (/Library/Frameworks/Storage.framework/Contents/Resources/dataPkg). El Orquestador (así como los complementos) están empaquetados con aPLib y cifrados con AES. Una vez desempaquetado, el Orquestador, se carga de forma reflexiva.

Infección en Linux

La versión de Linux de FinSpy está protegida con un ofuscador similar a OLLVM. Tiene los mismos componentes que la versión para macOS (Cargador inicial, Cargador de troyanos, Orquestador y complementos).

El Instalador

Se desconocen los vectores de infección que se utilizan para introducir FinSpy en Linux. La base de datos de preguntas de soporte de FinFisher filtrada sugiere que se podría utilizar el acceso físico para infectar las máquinas:

Una pregunta relacionada con la infección de Linux que se presentó al soporte de FinFisher en 2013

La etapa inicial del instalador es el siguiente script de shell:

Este script determina la arquitectura de la máquina víctima. Dependiendo de cual sea, el script extrae el instalador de la segunda etapa de 32 bits o de 64 bits al archivo /tmp/udev2 y lo lanza. Ambas versiones del ejecutable del instalador se adjuntan al script Bash. La versión de 32 bits se delimita del script con la cadena __x86xx__, mientras que la cadena __x64xx__ delimita la versión de 64 bits de la de 32 bits.

El ejecutable lanzado comprueba primero si se está ejecutando en una máquina virtual con:

• La instrucción de ensamblaje CPUID
• El comando lspci
• El comando dmesg

Si se detecta una máquina virtual y el troyano instalado no puede ser lanzado en una VM, el instalador finaliza. El directorio de trabajo se encuentra en la ruta ~/<directorio#1>/<directorio#2>.  Los directorios #1 y #2 pueden tomar los siguientes nombres, que se seleccionan al azar:

Nombres del directorio #1	Nombres del directorio #2
.cache .dbus .fontconfig .gconf .gnome .gnome2 .kde .local .qt .ssh	.config .bin .sbin .etc .cfg .apps

El instalador guarda el troyano en el directorio de trabajo. El nombre del archivo del descargador troyano es uno de los siguientes:

• cpuset
• kthreadd
• ksnapd
• udevd
• dbus-daemon
• en
• crawn
• hald

Los archivos del complemento tienen el nombre de <module ID>.so, y los nombres de sus configuraciones son <module ID>C.dat.

Después de guardar los archivos, el instalador establece la persistencia. En KDE, copia un script Bash en ~/.kde4/Autostart/udev2.sh o ~/.kde/Autostart/udev2.sh. En otros entornos de escritorio, añade el mismo script al archivo ~/.profile.

El Cargador inicial

El cargador inicial es el siguiente script de shell:

Este script descifra de la notación hexadecimal la ruta del directorio y el descargador troyano, y ejecuta el comando “cd <ruta del directorio de trabajo> && ./<nombre del archivo de carga> > /dev/null 2>&1 && cd – > /dev/null 2>&1″ , ejecutando así el descargador troyano.

El Cargador de troyanos

Cuando se ejecuta, el Descargador de troyanos:

• Usa la función ptrace para saber si se lo está depurando; si es así, finaliza.
• Lee el archivo de Orquestador del disco y lo desempaqueta con aPLib.
• Carga y ejecuta el Orquestador de forma reflexiva.

El Troyano

Resumen de los componentes del Troyano para Windows

La versión para Windows del troyano consta de los siguientes componentes:

• El Ocultador, el primer componente lanzado. Inicia el Orquestador y oculta las áreas de memoria que contienen el código y los datos de los componentes del troyano.
• El Orquestador, una DLL que se encarga de manejar los complementos instalados y de preparar los datos que se enviarán al servidor C2
• Complementos, módulos DLL que realizan actividades maliciosas en la máquina víctima
• El sistema de archivos virtual (VFS) que permite al Orquestador y a otros complementos interactuar sin problemas con los complementos y sus configuraciones
• El módulo ProcessWorm que intercepta la actividad del sistema. Al igual que un gusano de red que infecta máquinas en la red local, ProcessWorm se inyecta en todos los procesos en ejecución. Una vez que un proceso está infectado, ProcessWorm se propaga a sus procesos secundarios.
• El módulo Communicador, que envía datos al servidor C2 y recibe las respuestas

El Ocultador

El Ocultador es el primer componente lanzado del Backdoor. Es un archivo PE válido protegido con la VM de FinSpy. Al iniciarse, el Ocultador carga una copia limpia de ntdll.dll desde el disco, que se utiliza cuando se llaman funciones de la API desde esta biblioteca.  Después de eso, descifra el Orquestador, que se almacena en la sección de recursos del Ocultador. Se cifra con una clave RC4 de 256 bytes, que se descifra en tiempo de ejecución mediante operaciones de suma, resta y XOR. La clave puede variar de una muestra a otra.

Un fragmento de la función de generación de claves RC4

Después de descifrar y desempaquetar el Orquestador, el Ocultador lo carga reflexivamente.

La función de ocultación

Antes de transferir la ejecución al punto de entrada del Orquestador, el Ocultador activa su funcionalidad de ocultación. Funciona de la siguiente manera:

• El Ocultador cifra las páginas del Orquestador con un cifrado basado en operaciones XOR y ROL y les asigna el atributo PAGE_NOACCESS
• Cuando el Orquestador accede a páginas ocultas, el sistema operativo genera una excepción ACCESS_VIOLATION
• El Ocultador detecta la excepción generada a través del enlace de la función KiUserExceptionDispatcher, que se encarga de distribuir todas las excepciones
• La función enlazada descifra la página oculta y le asigna el atributo PAGE_EXECUTE_READWRITE, manejando así la excepción
• El Ocultador vuelve a ocultar las páginas no ocultas en 30 segundos.

El Ocultador también protege los complementos cargados por el Orquestador.

El Orquestador

El Orquestador es el módulo central del troyano, que controla todos los complementos y gestiona las comunicaciones con el servidor C2.

Cuando el Orquestador se pone en marcha:

• Enlaza su propia IAT (tabla de direcciones de importación) para alterar el comportamiento de las funciones de manipulación de archivos WinAPI. El Orquestador necesita estos enlaces para interactuar con el VFS.
• Establece la persistencia mediante la creación de una entrada en la clave de registro HKCUSoftware\Microsoft\Windows\CurrentVersion\Run.
• Lee la configuración del Orquestador y carga los complementos instalados.

Un hecho interesante sobre el Orquestador es que borra sus estructuras PE y el código de los procedimientos de inicialización. Este truco está diseñado para dificultar la detección de este componente en memoria y el análisis de sus volcados.

Una vez inicializado, el Orquestador lanza sus siguientes componentes, que detallaremos a continuación:

• El observador de aplicaciones que busca procesos específicos y notifica al servidor C2 cuando se inician o se detienen
• El inyector de ProcessWorm, que inyecta el ProcessWorm en procesos que no están infectados con este componente
• El subproceso del administrador de grabaciones que controla los datos que se extraen hacia el servidor C2
• El subproceso comunicador del servidor C2.

El observador de aplicaciones

El observador de aplicaciones examina a intervalos regulares todos los procesos del sistema, buscando las aplicaciones especificadas en la configuración del Orquestador. Cuando detecta una instancia de un proceso que se inicia primero (o que es el último en detenerse) presente en la lista en la configuración, informa de un evento apropiado al servidor C2 durante el tiempo del latido.  Cabe destacar que el vigilante de aplicaciones adquiere los controladores de todos los procesos que se ejecutan en el sistema, lo que hace que winlogon.exe o explorer.exe obtengan numerosos controladores de procesos.

Controladores de procesos adquiridos por explorer.exe en un sistema limpio (izquierda) y en un sistema infectado, donde el Orquestador reside dentro del proceso explorer.exe (derecha)

El inyector ProcessWorm

El subproceso inyector de ProcessWorm garantiza que ProcessWorm se ejecute en cada subproceso al que puede acceder el Orquestador. Al igual que el observador de aplicaciones, el inyector obtiene regularmente la lista de procesos en ejecución. Para cada proceso, verifica si ProcessWorm se está ejecutando dentro de él, y de ser necesario, le inyecta ProcessWorm.

El administrador de grabaciones

A lo largo de su ejecución, los complementos pueden guardar archivos de grabaciones en el directorio de trabajo (por ejemplo, keylogs, capturas de pantalla o archivos impresos). El administración de grabaciones tiene dos funciones:

• Comprobar periódicamente si hay archivos de grabación disponibles para enviarlos al servidor C2
• Preparar los archivos de grabación para enviarlos cuando el servidor C2 lo solicite.

Cada archivo de grabación almacenado en el directorio de trabajo tiene el siguiente formato de nombre:

<prefijo del complemento><prefijo del tipo de grabación><número aleatorio de cinco dígitos>.<extensión>

El prefijo del complemento, la extensión y el prefijo del tipo de grabación dependen del ID del complemento que creó la grabación. El Orquestador tiene matrices que convierten los ID en prefijos y extensiones.

Posibles prefijos de los complementos: auth, avi, cert, crt, com, mem, sxs, msvc, dmem, mtx, net, nls, odbc, ole, pnp, ssl, win, vm, vsc, ntos, user, run, cvs, cvg, con, ssy

Prefijos de tipo de las grabaciones: inf, sys, doc, mem, vmx, net, run, dat, dll.

Extensiones de archivo utilizadas: doc, vmx, net, xls, zip.

El subproceso de comunicación del servidor C2

Este subproceso se encarga de mantener la comunicación con el servidor C2. En particular, se pone en contacto con el servidor C2, envía mensajes de latido y recibe comandos. El subproceso despacha los comandos recibidos a los complementos y envía los resultados de su ejecución al servidor.

A continuación, se muestra una lista de los comandos del Orquestador:

Id. de la orden	Descripción
Comandos relacionados con las grabaciones
0x8072A0	Subir al servidor C2 un archivo de grabación con un nombre determinado.
0x8076A0, 0x807AA0	Borrar del sistema una grabación con un nombre de archivo determinado.
0x8078A0	Recuperar la lista de todas las grabaciones presentes en la máquina víctima.
0x8070A0	Recuperar la lista de grabaciones realizadas por un complemento con el id. especificado.
Comandos relacionados con la configuración
0x8030A0	Enviar la configuración actual al servidor.
0x8032A0	Cambiar la configuración del Orquestador.
Comandos relacionados con los complementos
0x8009A0	Enviar al servidor una lista de los complementos instalados.
0x8054A0, 0x805BA0	Iniciar el proceso de instalación del complemento creando un archivo temporal en el directorio de trabajo.
0x8056A0, 0x805DA0	Añadir un pedazo del cuerpo del complemento al archivo temporal del complemento creado por el comando anterior.
0x8057A0, 0x805EA0	Finalizar el proceso de instalación del complemento. Este comando mueve el contenido del archivo temporal al sistema de archivos virtual y carga el nuevo complemento.
0x8059A0	Desinstalar un complemento de la máquina. Este comando descarga el complemento especificado y lo elimina del VFS.
Comandos varios
0x8018A0	Desinstalar la puerta trasera Este comando borra todos los archivos y claves de registro creados por el backdoor. También restaura el MBR y el gestor de arranque EFI de Windows (siempre que estén infectados) a partir de copias de seguridad.
0x807DA0	Cerrar la conexión actual del servidor C2.
0x7502A0	Finalizar todas las transmisiones en directo.

El módulo Comunicador

La configuración del malware incluye uno o varios servidores C2 a los que puede conectarse. En caso de que uno de los servidores no funcione, la puerta trasera utiliza una de las direcciones de reserva. FinSpy no se comunica con los servidores C2 directamente desde winlogon.exe o explorer.exe. En su lugar, genera un proceso de navegador por defecto con una ventana oculta e inyecta el módulo Comunicador en él. Esto se hace para que las comunicaciones parezcan legítimas.

El componente Sistema de archivos virtual

El Sistema de archivos virtual es el lugar donde se esconden todos los ejecutables del complemento y sus configuraciones. Todos los archivos virtuales se almacenan en un único archivo “real”, que está cifrado con RC4 y tiene la siguiente estructura:

Desplazamiento de archivos	Descripción
0x0	Suma de comprobación CRC32 del archivo (el cálculo de la suma de comprobación comienza a partir del desplazamiento 4)
VFS entry #1
0x4	Id. del complemento correspondiente al archivo. La configuración del Orquestador se almacena en el VFS con el ID 0xFFFFFFFE.
0x8	0x0 si el archivo es una configuración de complemento, 0x2 si es un ejecutable de complemento.
0xC	Tamaño del archivo.
0x10	Otra vez el tamaño del archivo.
0x14	Bytes del cuerpo del archivo.
Entrada VFS #2
…
El id. de la última entrada que VFS tiene es igual a 0xFFFFFFFF y su tamaño es cero. Sirve como marcador final del VFS.
EndOfFile – 0x10	0xFFFFFFFF
EndOfFile  – 0xC	0x0
EndOfFile – 0x8	0x0
EndOfFile – 0x4	0x0

Se accede al VFS a través de funciones de gestión de archivos enlazadas por el Orquestador. Por ejemplo, los archivos virtuales pueden crearse o abrirse a través de la API CreateFileW enlazada. El valor de retorno de la función de creación de archivos enlazados es un controlador VFS, que es un número en formato 0xFF000XXX.

El ProcessWorm

El malware inyecta el ProcessWorm en todos los procesos que se ejecutan en el sistema. Su objetivo principal es extraer información específica sobre los procesos en ejecución y enviarla al Orquestador o a los complementos.

El ProcessWorm es una DLL envuelta en un shellcode y ofuscada con FinSpy VM. Se puede inyectar ProcessWorm en los procesos de dos maneras: por generación de un proceso remoto con el shellcode o mediante la creación de un APC (Asynchronous Procedure Call) con la dirección del procedimiento que apunta al inicio del shellcode.  Este último se utiliza cuando el ProcessWorm se inyecta en procesos recién creados.

El código del cargador se comporta de forma diferente según el tipo de inyección elegido. Mientras que el cargador utilizado con el primer método de inyección es simple, el que se invoca en el caso de las inyecciones APC es bastante interesante. El procedimiento asíncrono coloca un enlace en la función NtTestAlert y luego sale. Cuando se carga el ejecutable del proceso, ntdll.dll llama la función NtTestAlert . Su versión modificada llama primero a la función original NtTestAlert y luego invoca al cargador reflexivo ProcessWorm.

El cargador reflexivo ProcessWorm tiene un giro inesperado. Cuando procesa las importaciones, no asigna un puntero de función a cada entrada de la IAT. En su lugar, las entradas de la IAT apuntan a búferes de código basura generado aleatoriamente. Este código obtiene la dirección de la función API de destino mediante la combinación XOR de dos números y luego salta a ella.

Ejemplo de código basura creado por el cargador de ProcessWorm, las instrucciones útiles están resaltadas en amarillo

Mientras ejecuta su actividad de gusano, el ProcessWorm se inyecta en los procesos creados por el proceso que ya están infectados con este componente. Para ello, coloca un enlace en la función de la API CreateProcessInternalW. Si el nuevo proceso no se crea con una bandera DEBUG_PROCESS o DEBUG_ONLY_THIS_PROCESS, la función de creación de procesos enlazados borra un posible enlace de la función NtQueueAPCThread y luego lo utiliza para crear un procedimiento APC en el nuevo proceso. Al iniciarse el nuevo proceso, el ProcessWorm se cargará con la ayuda del cargador de inyección APC.

Dependiendo de la configuración del malware, el ProcessWorm puede ocultar la presencia de FinSpy en la máquina víctima. Puede ocultar el directorio de trabajo del malware, los servicios, las claves del registro, las direcciones del servidor C2, así como filtrar los registros de eventos relacionados con la actividad maliciosa. El ProcessWorm se hace invisible aprovechando funciones de la API de bajo nivel (como NtEnumerateValueKey o NtQuerySystemInformation)

El resto de la actividad maliciosa se dispersa en los enlaces de varias funciones de WinAPI. Se colocan para proporcionar información a los complementos incluidos en el malware. Ejemplos de esta información son las pulsaciones de teclas o los documentos que se envían a la impresora.

El Orquestador par macOS y Linux

El orquestador para macOS/Linux es una versión simplificada del Orquestador para Windows. A diferencia de la versión para Windows, sí tiene los siguientes componentes:

• El sistema de archivos virtuales (los complementos y las configuraciones se almacenan en archivos separados)
• El ProcessWorm (su funcionalidad está integrada en los complementos)
• El módulo comunicador (el Orquestador intercambia datos con los servidores C2 sin necesidad de módulos adicionales)
• El observador de aplicaciones (el Orquestador no informa de los procesos iniciados o detenidos a los servidores C2)

Las funcionalidades del Orquestador siguen siendo las mismas: intercambio de información con el servidor C2, envío de comandos a los complementos y gestión de los archivos de grabación.

Resumen de los complementos

En el siguiente cuadro resumimos la información sobre los complementos.

Tipo e id. del complemento	Características
FileManager (0x02)	Cargar, descargar, buscar y eliminar archivos. Crear grabaciones de listas de archivos
CommandShell (0x04)	Crear sesiones de shell remotas
TaskScheduler (0x05)	Crear diferentes tipos de grabaciones (listados de archivos, micrófono, pantalla, cámara web) en un momento determinado mediante el envío de comandos a los complementos adecuados
MicRecorder (0x10)	Transmitir en directo el micrófono de la víctima o capturar sus grabaciones.
KeyLogger (0x12)	Transmitir en directo o grabar las pulsaciones del teclado
SkypeStealer (0x14)	Interceptar contactos, chats, llamadas y archivos transferidos de Skype
FileModificationRecorder (0x16)	Registrar los archivos que han sido modificados
FileAccessRecorder (0x17)	Registrar los archivos a los que se ha accedido
PrintedFilesRecorder (0x18)	Robar archivos que la víctima imprime
FileDeletionRecorder (0x19)	Registrar los archivos eliminados
ForensicLauncher (0x20)	Reunir datos forenses mediante la descarga o ejecución de utilidades específicas. (Sólo para Windows)
VoIPRecorder, VoIPLite (0x21, 0x26)	Espiar y tomar capturas de pantalla durante las conversaciones en línea (sólo para Windows).
ClickRecorder (0x22)	Capturar el área de la pantalla alrededor de las ubicaciones de los clics del ratón
WebcamRecorder (0x23)	Tomar imágenes de la cámara web con una velocidad de fotogramas determinada y transmitirlas en directo o grabarlas.
ScreenRecorder (0x24)	Realizar capturas de pantalla con una velocidad de fotogramas determinada y transmitirlas en directo o grabarlas.
BlackberryInfect (0x25)	Infectar los dispositivos móviles Blackberry con una aplicación maliciosa. (sólo para Windows)
EmailRecorder (0x27)	Robar el correo electrónico de Thunderbird, Outlook, Apple Mail e Icedove
WiFiRecorder (0x28)	Supervisar las redes Wi-Fi disponibles
RemovableRecorder (0x29)	Grabar archivos en soportes extraíbles insertados
CryptoKeyRecorder (0x30)	Capturar claves de cifrado: Claves SSL, certificados S/MIME, llaveros GPG/PGP junto con sus frases de contraseña (sólo para Windows).

Los detalles completos de esta investigación, así como las futuras actualizaciones de FinSpy, están disponibles para los clientes del servicio de informes APT a través de nuestro Threat Intelligence Portal.

IoCs

La siguiente lista de IoC no es completa. Si desea más información sobre la APT de la que se habla aquí, los clientes de Kaspersky Threat Intelligence Reports tienen a su disposición una lista completa de IoC y reglas YARA. Contacto: intelreports@kaspersky.com

Hashes de archivos

5EDF9810355DE986EAD251B297856F38
31F1D208EE740E1FDF9667B2E525F3D7
4994952020DA28BB0AA023D236A6BF3B
262C9241B5F50293CB972C0E93D5D5FC
405BB24ADE435693B11AF1D81E2BB279
EF74C95B1DBDBF9BD231DA1EE99F0A7E
B8A15A0CE29692FBA36A87FCDED971DE

Rutas de los archivos

\efi\microsoft\boot\en-us\%HEXNUMS% – en la partición del disco EFI
/Library/Frameworks/Storage.framework – para la versión de Mac OS

Mutexes

SessionImmersiveMutex
WininetStartupMutex0

Eventos

0x0A7F1FFAB12BB2
WinlogonLogon
Debug.Trace.Event.f120.0.v1
TermSrvReadyEvent%HEXNUMS%
SessionImmersiveEvent

Archivos

0x0A7F1FFAB12BB3
windows_shell_global

Mailslots

mailslot\x86_microsoft.windows.c-controls.resources_6595b64144ccf1df_6.0.7600.16385_en-us_581cd2bf5825dde9
mailslot\x86_microsoft.vc90.mfc_1fc8b3b9a1e18e3b_9.0.30729.6161_none_4bf7e3e2bf9ada4c
mailslot\6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2
mailslot\ConsoleEvent-0x00000DAC–16628266191048322066-650920812-1622683116-1844332734-1046489716-2050906124-443455187

Dominios e IPs

45.86.136[.]138
79.143.87[.]216
185.25.51[.]104
109.235.67[.]175
213.252.247[.]105
108.61.190[.]183
185.141.24[.]204

¹ Extended BIOS Data Area (https://wiki.osdev.org/Memory_Map_(x86))