FinFisher: el espía mejora su arsenal con 4 niveles de ofuscación

FinSpy, también conocido como FinFisher o Wingbird , es un infame conjunto de herramientas de vigilancia.

Kaspersky ha estado rastreando las implementaciones de este software espía desde 2011. Históricamente, su implante de Windows se distribuía 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 una tasa de detección decreciente de FinSpy para Windows. Si bien la naturaleza de esta anomalía permaneció desconocida, comenzamos a detectar algunos instaladores sospechosos de aplicaciones legítimas, con puertas traseras con un descargador ofuscado relativamente pequeño. No pudimos agrupar esos paquetes hasta mediados de 2019 cuando encontramos un host que sirvió a estos instaladores entre los implantes de FinSpy Mobile para Android. En el transcurso de nuestra investigación, descubrimos que los instaladores con puerta trasera no son más que implantes de primera etapa que se utilizan para descargar e implementar cargas útiles adicionales antes del troyano FinSpy real.

Además de los instaladores troyanizados, también observamos infecciones relacionadas con el uso de un kit de arranque UEFI o MBR. Si bien la infección de MBR se conoce desde al menos 2014, los detalles sobre el kit de arranque UEFI se revelan públicamente en este artículo por primera vez.

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

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

Contacto: intelreports@kaspersky.com

Infección UEFI

Durante nuestra investigación, encontramos un bootkit UEFI que estaba cargando FinSpy. Todas las máquinas infectadas con el kit de arranque UEFI tenían el Administrador de arranque de Windows ( bootmgfw.efi ) reemplazado por uno malicioso. Cuando UEFI transfiere la ejecución al cargador malicioso, primero ubica el Administrador de arranque de Windows original.

Se almacena dentro del directorio efi \ microsoft \ boot \ en-us \ , y el nombre consta de caracteres hexadecimales. Este directorio contiene dos archivos más: Winlogon Injector y Trojan Loader. Ambos están encriptados con RC4. La clave de descifrado es el GUID de la partición del sistema EFI, que difiere de una máquina a otra.

Contenido de muestra del directorio \ efi \ microsoft \ boot \ en-us \

Una vez que se encuentra el cargador de arranque original, se carga en la memoria, se parchea y se ejecuta. El lanzador parcheado:

  • Parcha la función del cargador del sistema operativo que transfiere la ejecución al kernel
  • La función parcheada engancha la función PsCreateSystemThread del kernel , que, cuando se llama por primera vez, crea un hilo adicional que descifra la siguiente etapa del cargador y la lanza.

La siguiente etapa:

  • Localiza el archivo del cargador de troyanos en la partición EFI y lo descifra
  • Espera hasta que un usuario inicia sesión e inyecta el cargador de troyanos en exe.

El cargador de troyanos:

  • Extrae el troyano de los recursos y lo coloca bajo el nombre dll
  • Descifra el troyano con un cifrado basado en XOR y lo descomprime con aPLib
  • Carga y lanza de forma reflexiva el troyano.

Infección MBR

Las máquinas más antiguas que no son compatibles con UEFI pueden infectarse a través del MBR. Cuando se inicia la máquina víctima, el MBR infectado copia el código del cargador inicial desde el último megabyte del disco duro a la memoria más alta disponible ubicada antes del EBDA 1 . Este código conecta las interrupciones del BIOS 13h y 15h y luego lanza el MBR original. La interrupción de 15 h se asegura de que el cargador de Windows no sobrescriba el código copiado. Cuando se llama a esta interrupción para obtener el tamaño del área antes del EBDA, el gancho reducirá la cantidad de memoria disponible. En cuanto a las 13hgancho de interrupción (que gestiona la lectura de información del disco), parchea el cargador del sistema operativo cuando se lee desde el disco. Al igual que en el caso de la infección EFI, las funciones enganchadas colocan sus propios ganchos en las etapas de carga del sistema operativo posteriores. El último gancho de la cadena crea un hilo en el kernel que inyecta la siguiente etapa en winlogon.exe .

En caso de que la infección esté instalada 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 UEFI. Es como sigue:

  • Se crea un hilo con shellcode de trampolín dentro de exe.
  • Este shellcode duplica el identificador 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 vuelva a inyectar el cargador de troyanos en winlogon.exe .

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

El cargador de troyanos inyectado es el mismo que el de UEFI.

Infección del modo de usuario

Visión general

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

  • La víctima descarga una aplicación troyana y la ejecuta.
  • Durante su curso normal de funcionamiento, la aplicación se conecta a un servidor C2, descarga y luego lanza un componente no persistente llamado Pre-Validator. El prevalidador garantiza que la máquina víctima no se utilice para el análisis de malware.
  • El Pre-Validator descarga Security Shellcodes del servidor C2 y los ejecuta. En total, implementa más de 30 códigos de shell. Cada código de shell recopila información específica del sistema (por ejemplo, el nombre del proceso actual) y la carga de nuevo en el servidor.
  • En caso de que falle una comprobación, el servidor C2 finaliza el proceso de infección. De lo contrario, continúa enviando códigos de shell.
  • Si todos los controles de seguridad pasan, el servidor proporciona un componente que llamamos Post-Validator. Es un implante persistente que probablemente se usa para garantizar que la víctima sea la prevista. El Post-Validator recopila información que le permite identificar la máquina víctima (procesos en ejecución, documentos abiertos recientemente, capturas de pantalla) y la envía a un servidor C2 especificado en su configuración.
  • Dependiendo de la información recopilada, el servidor C2 puede ordenar al Post-Validator que implemente la plataforma troyana completa o elimine la infección.

Descripción general de la infección del modo de usuario

Aplicaciones troyanizadas

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

Todas las muestras de aplicaciones con puertas traseras observadas tienen su firma digital original. No es válido, lo que indica que la aplicación ha sido parcheada. Si bien 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 puerta trasera tiene su última sección ( .rsrc en la captura de pantalla siguiente) ampliada en 51 KB.

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

Aparte de eso, una parte del código de la sección .text (aproximadamente 8 KB) se sobrescribe con un código muy ofuscado, con el código de la aplicación original colocado en la última sección expandida.

Cuando se inicia la aplicación con puerta trasera, se ejecuta normalmente, es decir, el código oculto insertado no afecta el flujo de trabajo 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 aleatoriamente en el código. Por ejemplo, se reemplazó una llamada a la función CreateWindowExW :

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

Esta cama elástica está protegida con un ofuscador que llamamos FinSpy Mutator. Lanza un código que:

  • Descifra y lanza un stager HTTPS inverso Metasploit ligeramente modificado . El procedimiento de descifrado:
    • Está ofuscado con FinSpy Mutator
    • Implica aplicar 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 se sobrescribió con el código malicioso (recuerde 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 se ha sobrescrito con un salto
  • Salta a la instrucción restaurada, reanudando así la ejecución de la aplicación original.

El stager Metasploit se conecta a un servidor C2 configurado utilizando HTTPS para la comunicación. En el caso de 5EDF9810355DE986EAD251B297856F38, el stager envía la siguiente solicitud GET al servidor C2:

El servidor C2 responde con un componente que llamamos Pre-Validator en respuesta a la solicitud GET. El stager de Metasploit lo lanza.

El prevalidador

El Pre-Validator es un código de shell ofuscado con FinSpy Mutator. Al inicio,:

  • Engancha las NtTerminateProcess y ExitProcess funciones para asegurarse de que el pre-validador continúa trabajando si la aplicación está cerrada backdoored. Las funciones enganchadas 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? Attachid = a46dee635db8017962741f99f1849471 & d = 5d7e89e6b4874d0df95141bd923556f8 (todas las partes de esta URL varían entre muestras). Todas las comunicaciones entre el servidor están encriptadas con RC4.

La respuesta a la solicitud POST inicial contiene un shellcode que llamamos Security Shellcode. Al recibirlo, el Pre-Validador:

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

La naturaleza de estos códigos de shell indica que se utilizan para realizar huellas dactilares del sistema y verificar que no se utilizan para el análisis de malware. Es importante resaltar que los shellcodes solo recopilan los datos, todas las verificaciones se realizan del lado del servidor. En caso de que un shellcode cargue resultados de ejecución sospechosos (por ejemplo, el Pre-Validator se está ejecutando en una máquina virtual), el servidor proporciona un shellcode que termina el Pre-Validator.

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

Shellcode # Descripción
1 Intenta detectar un hipervisor con la instrucción CPUID (EAX = 1) . Si se detecta, devuelve el nombre del hipervisor (EAX = 0x40000000); de lo contrario, devuelve cero bytes.
2 Comprueba si es necesario suplantar el proceso actual (por ejemplo, si un usuario sin privilegios ejecuta la aplicación con puerta trasera como administrador).
3 Devuelve la carpeta del perfil del usuario (por ejemplo, C: \ Users \ username)
4 Devuelve la forma abreviada de la carpeta del perfil del usuario (por ejemplo, C: \ Users \ abcdef ~ 1)
5 Devuelve el tipo de unidad que contiene la aplicación con 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 a la carpeta ‘Archivos de programa’.
8 Para la unidad del sistema, devuelve:
  • Espacio total disponible
  • Espacio disponible para el usuario actual (puede ser menor que el espacio total disponible debido a las cuotas)
  • Capacidad de disco
9 Devuelve la ruta a la carpeta temporal del usuario.
10 Devuelve la lista de tipos de adaptadores de red, direcciones IP y MAC asignadas a ellos.
11 Devuelve la lista de procesos en ejecución.
12 Devuelve el valor de ProcessDebugPort devuelto por NtQueryInformationProcess para el proceso actual.
13 Devuelve el valor de ProcessDebugObjectHandle 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.
dieciséis 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 el BIOS de la máquina.
19 Devuelve la lista de nombres de objetos en \ GLOBAL ?? directorio.
20 Devuelve información sobre el sistema operativo.
21 Devuelve el nombre del usuario actual, el nombre de la computadora, la ruta al 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 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 informático (de SELECT * FROM Win32_ComputerSystem WMI query)
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 clase de ventana secundaria y de nivel superior que no son propiedad del proceso actual o principal.
31 Devuelve la lista de títulos de ventanas secundarias y de nivel superior que no son propiedad del proceso actual o principal.
32 Devuelve el SID del dominio actual.
33 Limpia las funciones de la API potencialmente enganchadas 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 pasan todas las comprobaciones de seguridad, el servidor C2 envía un código de shell que descarga y ejecuta el instalador posterior al validador.

El instalador posterior al validador

Este módulo es un shellcode ofuscado. Eso:

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

    Los nombres de los archivos están codificados en el cuentagotas, pero son únicos para cada muestra y parecen generados aleatoriamente.

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

Después de que se instala el Post-Validator, el Pre-Validator se apaga.

El cargador posvalidador

El Post-Validator Loader es una enorme DLL ofuscada (3-9 MB). El Programador de tareas lo inicia al inicio del sistema a través de regsvr32.exe . Su función principal tiene un tamaño de varios megabytes, pero a pesar de eso, su propósito es simple: leer y ejecutar un código de shell que está almacenado en el mismo directorio que el Post-Validator Loader.

Propiedades de la tarea programada de muestra

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

El posvalidador

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

  • El formato TLV ( tipo-longitud-valor ) para intercambiar datos con servidores C2
  • Constantes de tipo TLV que se encuentran en el troyano
  • La biblioteca de criptografía del troyano para cifrar / descifrar los datos intercambiados

En el inicio, el Post-Validator verifica que no se inicie dentro de un entorno de espacio aislado. Luego inicia la comunicación con los servidores C2 especificados en su configuración, enviando mensajes de latido con intervalos de 15 minutos. Cada latido incluye información breve sobre la máquina víctima.

La respuesta de latido puede contener diferentes comandos.

ID de TLV Propósito del comando (inferido del troyano principal) Implementación de comando en el Post-Validator
0x8030A0 Recupera la configuración del implante.
0x8070A0 Recupere la lista de archivos con datos preparados para la exfiltración. Devuelve tres cadenas en un TLV: 243a , 201a y 201b (nombres de archivos de datos ‘virtuales’)
0x8072A0 Cargue un archivo preparado con un nombre específico al servidor C2. 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 , toma una captura de pantalla y la carga en el 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 Desinstale el troyano. Desinstale el prevalidador.
0x7502A0 Desconéctese del servidor C2.

Cuando el validador posterior recibe el instalador de troyanos (que es una DLL),:

  • Carga e inicia de forma reflectante el instalador
  • Dependiendo de la configuración, se desinstala a sí mismo (eliminando su directorio y la tarea programada) o se pone en suspensión hasta que se reinicia el sistema.

Según los datos recopilados por el posvalidador, lo más probable es que:

  • El Post-Validator se implementa para garantizar que la víctima infectada sea la prevista.
  • El operador del servidor C2 analiza manualmente los datos recibidos de la víctima y ordena eliminar el Post-Validator o infectar la máquina con el troyano.

El Postvalidator es otro obstáculo para los investigadores. Incluso si logran pasar todas las comprobaciones del Pre-Validator, 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 en inglés concatenadas>) y lo configura para que se acceda, modifique y cree un año antes. Luego, le coloca los siguientes archivos:

Nombre del archivo Descripción
<4 caracteres hexadecimales aleatorios> .cab El archivo de configuración de instalación, que está encriptado con RC4 (clave: el nombre del directorio de trabajo).
Los nombres difieren entre muestras El archivo VFS cifrado.
El cargador inicial.
msvcr90.dll El paquete de troyanos, cifrado con XOR y comprimido con aPLib.
msvcr120d.dll Cargador de troyanos de 64 bits. El ejecutable se antepone con 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 descartados se establecen en un año antes de la fecha actual. Una vez que se prepara el directorio de trabajo, el instalador lanza el troyano.

El cargador inicial

El cargador inicial es un archivo DLL que rundll32.exe lanza en cada inicio (el troyano lo agrega 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 que se asemeja al ofuscador OLLVM de código abierto. A pesar de su tamaño, la única funcionalidad del cargador inicial es descifrar y ejecutar el cargador de troyanos de 32 bits.

El cargador de troyanos

El Trojan Loader de 32 bits, que se inicia 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 de 32 bits o de 64 bits):

  • Lee el archivo del paquete troyano ( dll ), lo descifra con XOR y lo descomprime con aPLib.
  • Inyecta el troyano DLL en exe ya sea llamando CreateRemoteThread o utilizando el KernelCallbackTable técnica .

Infección MacOS

La versión macOS del malware no es tan complicada como la de Windows. Está escrito en Objective-C. Se 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 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 solo tiene un tipo de instalador.
  • El cargador inicial.
  • El cargador de troyanos.
  • El troyano que consta del orquestador, la biblioteca de criptografía y los complementos.

El instalador

Cuando la víctima ejecuta la aplicación maliciosa, se inicia un ejecutable ubicado en la ruta del instalador <nombre de la aplicación maliciosa> .app / Contents / MacOS / . Al inicio, comprueba el entorno en busca de depuradores y máquinas virtuales. Deja los siguientes archivos en la máquina:

Sendero Descripción
/Library/Frameworks/Storage.framework Un directorio con el troyano dentro
/ privado / etc / logind El cargador de troyanos que se ejecuta como agente de lanzamiento. Este archivo se ejecuta al inicio.

/Library/LaunchAgents/logind.plist

La configuración del agente de logind . El troyano lo necesita para mantener la persistencia.

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

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

Luego, el instalador lanza el ejecutable logind (Trojan Loader) con la utilidad launchctl .

El cargador inicial

El cargador inicial ( / private / etc / logind ) se inicia cada vez que se inicia el sistema operativo. Una vez lanzado, The Initial Loader lanza el Trojan Loader ( /Library/Frameworks/Storage.framework/Contents/MacOS/logind ).

El cargador de troyanos

Trojan Loader tiene una función de constructor que se invoca antes que main . Establece enlaces a funciones que cargan paquetes de aplicaciones. Estos ganchos permiten al troyano cargar complementos mientras los descifra sobre la marcha.

Una vez que se colocan los ganchos, Trojan Loader inicia el Orchestrator ( /Library/Frameworks/Storage.framework/Contents/Resources/dataPkg ). El orquestador (así como los complementos) están empaquetados con aPLib y encriptados con AES. Cuando se desempaqueta el orquestador, se carga reflectantemente.

Infección de Linux

La versión de Linux de FinSpy está protegida con un ofuscador similar a OLLVM. Tiene los mismos componentes que en la versión macOS (Initial Loader, Trojan Loader, Orchestrator y complementos).

El instalador

Se desconocen los vectores de infección utilizados para entregar FinSpy para Linux. La base de datos filtrada de preguntas de soporte de FinFisher sugiere que el acceso físico podría usarse para infectar máquinas:

Una pregunta relacionada con la infección de Linux que se envió 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 él, el script extrae el instalador de segunda etapa de 32 bits o de 64 bits en el archivo / tmp / udev2 y lo ejecuta . 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__ , y la cadena __x64xx__ delimita la versión de 64 bits de la de 32 bits.

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

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

En caso de que se detecte una máquina virtual y el troyano instalado no se pueda iniciar en una máquina virtual, el instalador se cierra. El directorio de trabajo se encuentra en la ruta ~ / <directorio # 1> / <directorio # 2> . Los directorios n. ° 1 y n. ° 2 pueden tomar los siguientes nombres que se seleccionan al azar:

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

Luego, el instalador coloca el troyano en el directorio de trabajo. El nombre del archivo Trojan Loader es uno de los siguientes:

  • cpuset
  • kthreadd
  • ksnapd
  • udevd
  • dbus-daemon
  • atd
  • crond
  • hald

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

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

El cargador inicial

El cargador inicial es el siguiente script de shell:

Este script descodifica la ruta del directorio y el troyano cargador de hexadecimal y ejecuta el “ && ./<loader nombre de archivo> cd <directorio de ruta de trabajo> cd> / dev / null 2> & 1 && -> / dev / null 2> & 1″ comando , lanzando así el Trojan Loader.

El cargador de troyanos

Cuando se inicia, el Trojan Loader:

  • Comprueba si se está depurando con la función ptrace y sale si lo está.
  • Lee el archivo de Orchestrator del disco y lo descomprime con aPLib.
  • Carga e inicia de forma reflexiva el orquestador.

El troyano

Descripción general de los componentes del troyano de Windows

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

  • The Hider, el primer componente lanzado. Inicia el orquestador y oculta las áreas de memoria que contienen el código y los datos de los componentes troyanos.
  • The Orchestrator, una DLL que se encarga de administrar los complementos instalados y preparar los datos para enviarlos 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 que Orchestrator y otros complementos interactúen sin problemas con los complementos y sus configuraciones
  • El módulo ProcessWorm que intercepta la actividad del sistema. Similar a un gusano de red que infecta las máquinas de 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 hijos.
  • El módulo Comunicador que envía datos al servidor C2 y recibe respuestas

El ocultador

The Hider es el primer componente lanzado de Backdoor. Es un archivo PE válido protegido con FinSpy VM. Al iniciarse, Hider carga una copia limpia de ntdll.dll desde el disco, que se utiliza al llamar a funciones API desde esta biblioteca. Después de eso, descifra el orquestador, que se almacena en la sección de recursos de Hider. Está cifrado con una clave RC4 de 256 bytes. que se codifica 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 de forma reflexiva.

La funcionalidad de ocultación

Antes de transferir la ejecución al punto de entrada del orquestador, el ocultador activa su función 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
  • Hider detecta la excepción generada a través del enlace de la función KiUserExceptionDispatcher , que maneja el envío de todas las excepciones
  • La función enganchada descifra la página oculta y le asigna el atributo PAGE_EXECUTE_READWRITE , manejando así la excepción
  • The Hider vuelve a ocultar las páginas no ocultas en 30 segundos.

Hider también protege los complementos cargados por el orquestador.

El orquestador

El orquestador es el módulo principal del troyano que controla todos los complementos y administra las comunicaciones del servidor C2.

Cuando el orquestador se inicia,:

  • Engancha 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 ganchos para interactuar con el VFS.
  • Configura la persistencia creando una entrada en la clave de registro HKCU \ Software \ Microsoft \ Windows \ CurrentVersion \ Run .
  • Lee la configuración de Orchestrator 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 la memoria y realizar un 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 ProcessWorm que inyecta ProcessWorm en procesos que no están infectados con este componente.
  • El hilo del administrador de grabación que controla los datos que se filtrarán al servidor C2
  • El hilo del comunicador del servidor C2.

El observador de aplicaciones

El observador de aplicaciones examina con regularidad todos los procesos del sistema en busca de aplicaciones especificadas en la configuración de Orchestrator. Cuando detecta una primera instancia inicial (o una última parada) de un proceso de la lista en la configuración, se informará al servidor C2 de un evento apropiado durante el tiempo de latido. Es de destacar que el observador de aplicaciones adquiere identificadores para todos los procesos en ejecución en el sistema, lo que da como resultado que winlogon.exe o explorer.exe obtengan numerosos identificadores de procesos.

Controles de proceso adquiridos por explorer.exe en un sistema limpio (izquierda) y en un sistema infectado con el orquestador que reside dentro del proceso explorer.exe (derecha)

El inyector ProcessWorm

El subproceso del inyector ProcessWorm garantiza que ProcessWorm se esté ejecutando en todos los procesos a los 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 e inyecta ProcessWorm si es necesario.

El administrador de grabaciones

Durante el transcurso de su ejecución, los complementos pueden guardar archivos de grabación en el directorio de trabajo (por ejemplo, registros de teclas, capturas de pantalla o archivos impresos). El administrador de grabación tiene dos funciones:

  • Comprobación periódica de si hay archivos de grabación disponibles para enviar al servidor C2
  • Preparar archivos de grabación para cargarlos cuando el servidor C2 solicite su descarga.

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

<prefijo de complemento> <prefijo de 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 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, estafa, ssy

Prefijos de tipo de grabación: inf, sys, doc, mem, vmx, net, run, dat, dll.

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

El hilo de comunicación del servidor C2

Este hilo es responsable de mantener la comunicación con el servidor C2. En particular, contacta con el servidor C2, envía mensajes de latidos y recibe comandos. El hilo envía 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 de Orchestrator:

ID de comando Descripción
Comandos relacionados con grabaciones
0x8072A0 Cargue un archivo de grabación con un nombre específico al servidor C2.
0x8076A0, 0x807AA0 Elimina una grabación con un nombre de archivo determinado del sistema.
0x8078A0 Recupere la lista de todas las grabaciones presentes en la máquina víctima.
0x8070A0 Recupere la lista de grabaciones realizadas por un complemento con el ID especificado.
Comandos relacionados con la configuración
0x8030A0 Envíe la configuración actual al servidor.
0x8032A0 Cambie la configuración del orquestador.
Comandos relacionados con complementos
0x8009A0 Envíe una lista de complementos instalados al servidor.
0x8054A0, 0x805BA0 Comience el proceso de instalación del complemento creando un archivo temporal en el directorio de trabajo.
0x8056A0, 0x805DA0 Agregue un fragmento del cuerpo del complemento al archivo de complemento temporal creado por el comando anterior.
0x8057A0, 0x805EA0 Finalice 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 Desinstale un complemento de la máquina. Este comando descarga el complemento especificado y lo elimina del VFS.
Comandos misceláneos
0x8018A0 Desinstale la puerta trasera. Este comando borra todos los archivos y claves de registro creados por la puerta trasera, así como también restaura el MBR y EFI Windows Boot Manager (siempre que estuvieran infectados) de las copias de seguridad.
0x807DA0 Cierre la conexión actual del servidor C2.
0x7502A0 Termine todas las transmisiones en vivo.

El módulo Comunicador

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

El componente del sistema de archivos virtual

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

Desplazamiento de archivo Descripción
0x0 Suma de comprobación CRC32 del archivo (el cálculo de la suma de comprobación comienza desde el desplazamiento 4)
Entrada de VFS n. ° 1
0x4 ID del complemento correspondiente al archivo. La configuración de Orchestrator se almacena en el VFS con 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 Tamaño de archivo de nuevo.
0x14 Bytes del cuerpo del archivo.
Entrada de VFS n. ° 2
La última entrada de VFS tiene la ID igual a 0xFFFFFFFF y tamaño cero. Sirve como marcador final de VFS.
EndOfFile – 0x10 0xFFFFFFFF
 EndOfFile – 0xC 0x0
EndOfFile – 0x8 0x0
EndOfFile – 0x4 0x0

Se accede al VFS a través de las funciones de administración de archivos conectadas por el orquestador. Por ejemplo, los archivos virtuales se pueden crear o abrir a través de la API CreateFileW enganchada . El valor de retorno de la función de creación de archivos enganchados es un identificador VFS, que es un número del formato 0xFF000XXX .

El ProcessWorm

El malware inyecta 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 los complementos.

ProcessWorm es una DLL envuelta en un shellcode y ofuscada con FinSpy VM. El ProcessWorm se puede inyectar a los procesos de dos maneras: generando un hilo remoto con el código de shell o creando un APC ( llamada a procedimiento asíncrono ) con la dirección del procedimiento apuntando al inicio del código de shell. Este último se utiliza cuando ProcessWorm se inyecta en procesos recién creados.

El código del cargador se comporta de manera diferente según el tipo de inyección elegido. Si bien el cargador utilizado con el primer método de inyección es simple, el que se invoca en el caso de las inyecciones de APC es bastante interesante. El procedimiento asincrónico coloca un enlace en la función NtTestAlert y luego sale. Cuando se carga el ejecutable del proceso, ntdll.dll llamará a la función NtTestAlert . Su versión modificada primero llamará a la función NtTestAlert original y luego invocará el cargador reflectante ProcessWorm.

El cargador reflectante ProcessWorm viene con un giro. Cuando procesa importaciones, no asigna un puntero de función a cada entrada en el IAT. En cambio, las entradas 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 XOR-ing dos números y luego salta a ella.

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

Mientras ejecuta su actividad similar a un gusano, ProcessWorm se inyecta en los procesos creados por el proceso que ya están infectados con este componente. Para hacer eso, coloca un gancho en la función de API CreateProcessInternalW . Si el nuevo proceso no se crea con un indicador DEBUG_PROCESS o DEBUG_ONLY_THIS_PROCESS , la función de creación de proceso enganchado borra un posible gancho de la   función NtQueueAPCThread y luego lo usa para crear un procedimiento APC en el nuevo proceso. Cuando se inicia el nuevo proceso, ProcessWorm se cargará con la ayuda del cargador de inyección APC.

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

El resto de la actividad maliciosa se distribuye a través de enlaces de varias funciones de WinAPI. Se colocan para proporcionar información a los complementos incluidos con el malware. Ejemplos de dicha información son las pulsaciones de teclas escritas o los documentos enviados a la impresora.

El orquestador de macOS y Linux

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

  • El sistema de archivos virtual (los complementos y las configuraciones se almacenan en archivos separados)
  • ProcessWorm (su funcionalidad está incrustada en complementos)
  • El módulo comunicador (el orquestador intercambia datos con servidores C2 sin módulos adicionales)
  • El observador de la aplicación (el orquestador no informa los procesos iniciados o detenidos a los servidores C2)

Las funcionalidades del Orchestrator siguen siendo las mismas: intercambiar información con el servidor C2, enviar comandos a complementos y administrar archivos de grabación.

Descripción general de los complementos

En el cuadro a continuación, resumimos la información sobre los complementos.

Tipo e ID de complemento Características
Administrador de archivos (0x02) Cargue, descargue, busque, elimine archivos. Crear grabaciones de listas de archivos
CommandShell (0x04) Crear sesiones de shell remotas
TaskScheduler (0x05) Cree diferentes tipos de grabaciones (listas de archivos, micrófono, pantalla, cámara web) en un momento específico enviando comandos a los complementos apropiados
MicRecorder (0x10) Transmita en vivo el micrófono de la víctima o capture sus grabaciones.
KeyLogger (0x12) Transmisión en vivo o grabar pulsaciones de teclas
SkypeStealer (0x14) Intercepte contactos, chats, llamadas y archivos transferidos de Skype
FileModificationRecorder (0x16) Grabar archivos que han sido modificados
FileAccessRecorder (0x17) Registrar archivos a los que se ha accedido
PrintedFilesRecorder (0x18) Robar archivos impresos por la víctima.
FileDeletionRecorder (0x19) Grabar archivos eliminados
Lanzador forense (0x20) Reúna datos forenses descargando y ejecutando utilidades específicas. (Solo Windows)
VoIPRecorder, VoIPLite (0x21, 0x26) Escuche a escondidas y tome capturas de pantalla durante las conversaciones en línea. (Solo Windows)
ClickRecorder (0x22) Capture el área de la pantalla alrededor de las ubicaciones de los clics del mouse
Grabadora de cámara web (0x23) Tome imágenes de la cámara web con una velocidad de fotogramas específica y transmítalas en vivo o grábelas.
Grabador de pantalla (0x24) Tome capturas de pantalla con una velocidad de fotogramas especificada y transmítalas en vivo o grábelas.
BlackberryInfect (0x25) Infecte los dispositivos móviles Blackberry con una aplicación maliciosa. (Solo Windows)
Grabadora de correo electrónico (0x27) Robar correo electrónico de Thunderbird, Outlook, Apple Mail e Icedove
Grabadora WiFi (0x28) Supervisar las redes Wi-Fi disponibles
Grabadora extraíble (0x29) Grabar archivos en medios extraíbles insertados
CryptoKeyRecorder (0x30) Capture claves de cifrado: claves SSL, certificados S / MIME, llaveros GPG / PGP junto con sus contraseñas. (Solo Windows)

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

IoC

La siguiente lista de IoC no está completa. Si desea obtener más información sobre el APT que se analiza 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

Hash de archivo

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

Rutas de archivo

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

Mutexes

SesiónImmersiveMutex
WininetStartupMutex0

Eventos

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

Asignaciones de 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 IP

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

1 Área de datos de BIOS extendida (https://wiki.osdev.org/Memory_Map_(x86))

Por Marcelo Lozano General Publisher IT CONNECT LATAM

Lea más

Zero Trust 2021: ¿Teletrabajo sin temor a ser hackeado?

Servicios Digitales 21 Android, WhatsApp y Google huelen mal

Ciberseguridad 2021: cómo optimizar la inversión

Tarjetas de crédito: publican datos de 1 millón de plásticos gratis

TheHive Reloaded: 4.1.0 ya está disponible

FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher.

FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher.

FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher.

FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher,

FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, FinFisher, 

97 / 100