Un Halcón Invisible sobrevuela Medio Oriente desplegando el backdoor Deadglyph

Durante años, Medio Oriente fue terreno fértil para las amenazas persistentes avanzadas (APT). En medio del monitoreo de rutina de actividades sospechosas en los sistemas de clientes de alto perfil, algunos con sede en esa región, ESET Research se topó con un backdoor muy sofisticado y desconocido que hemos llamado Deadglyph.

Su nombre derivó de los artefactos encontrados en el backdoor (como 0xDEADB001, que también se muestra en Tabla 1 ), junto con la presencia de un ataque homoglyph. Hasta donde sabemos, este es el primer análisis público de este backdoor no documentado previamente, utilizado por un grupo que exhibe un notable grado de sofisticación y experiencia. Basándonos en los objetivos y en pruebas adicionales, atribuimos Deadglyph con un alto grado de confianza al grupo Stealth Falcon APT.

La arquitectura de Deadglyph es inusual, ya que consta de componentes que cooperan entre sí: uno es un binario nativo x64 y el otro un ensamblado .NET. Esta combinación es inusual porque el malware suele utilizar un solo lenguaje de programación para sus componentes. Esta diferencia podría indicar un desarrollo separado de esos dos componentes, al tiempo que se aprovechan de características únicas de los distintos lenguajes de programación que utilizan. La diferencia de lenguaje también puede aprovecharse para dificultar el análisis, ya que el código mixto es más difícil de navegar y depurar.

Los comandos tradicionales del backdoor no se implementan en el binario del backdoor, sino que éste los recibe dinámicamente del servidor de comando y control (C&C) en forma de módulos adicionales. Este backdoor también cuenta con una serie de capacidades para evitar ser detectado.

En este blogpost, echamos un vistazo más de cerca a Deadglyph y proporcionamos un análisis técnico de este backdoor, su propósito y algunos de los componentes adicionales que obtuvimos. También presentaremos nuestros hallazgos sobre Deadglyph en la conferencia LABScon 2023.

Puntos clave del blogpost:

• ESET Research descubrió un sofisticado backdoor con una arquitectura inusual que hemos denominado Deadglyph.
• Los componentes principales están cifrados mediante una clave específica de la máquina.
• Los comandos tradicionales del backdoor se implementan a través de módulos adicionales recibidos desde su servidor C&C.
• Obtuvimos tres de los muchos módulos: creador de procesos, lector de archivos y recopilador de información.
• Atribuimos Deadglyph al grupo Stealth Falcon.
• Además, encontramos un downloader de shellcode relacionado; postulamos que podría utilizarse potencialmente para la instalación de Deadglyph.

La víctima de la infiltración analizada es una entidad gubernamental de Oriente Medio que fue comprometida con fines de espionaje. Una muestra relacionada encontrada en VirusTotal también fue subida a la plataforma de escaneo de archivos desde esta región, específicamente desde Qatar. La región objetivo se representa en el mapa de Figura 1 .

Stealth Falcon (también conocido como Project Raven o FruityArmor) es un grupo de amenazas vinculado a los Emiratos Árabes Unidos, según MITRE. Activo desde 2012, Stealth Falcon es conocido por atacar a activistas políticos, periodistas y disidentes en Oriente Medio. Fue descubierto y descrito por primera vez por Citizen Lab, que publicó un análisis de una campaña de ataques de spyware en 2016.

En enero de 2019, Reuters publicó un informe de investigación sobre Project Raven, una iniciativa que supuestamente emplea a antiguos operativos de la NSA y apunta a los mismos tipos de objetivos que Stealth Falcon. Basándoseen estos dos informes que hacen referencia a los mismos objetivos y ataques, Amnistía Internacional ha llegado a la conclusión (que se muestra en Figura 2 ) de que Stealth Falcon y Project Raven son en realidad el mismo grupo.

En septiembre de 2019, publicamos una investigación sobre un backdoor, atribuido a Stealth Falcon, que utilizaba una técnica inusual, Background Intelligent Transfer Service, para la comunicación C&C. Ahora revelamos el resultado de nuestro análisis en profundidad de lo que presumiblemente es la más reciente adición al conjunto de herramientas de espionaje de Stealth Falcon.

Backdoor Deadglyph

La cadena de carga de Deadglyph consta de múltiples componentes, como se ilustra en Figura 3 . El componente inicial es un loader de shellcode del registro, que carga shellcode del registro. Este shellcode extraído, a su vez, carga la parte nativa x64 del backdoor: el Executor. Posteriormente, el Executor carga la parte .NET del backdoor: el Orchestrator. En particular, el único componente en el disco del sistema como archivo es el componente inicial, que está en forma de biblioteca de vínculos dinámicos (DLL). El resto de componentes están cifrados y almacenados en un valor binario del registro.

Aunque aún no se ha determinado el método exacto del vector de compromiso inicial, nuestra sospecha es que un componente instalador está implicado en el despliegue de otros componentes y en el establecimiento de la persistencia dentro del sistema.

En el resto de esta sección, analizamos cada componente.

Loader de código shell del registro

El componente inicial de Deadglyph es una pequeña DLL con una única exportación, denominada 1. Este componente se mantiene mediante la suscripción a eventos de Windows Management Instrumentation (WMI ) y sirve como loader de código shell del registro. Se ejecuta a través de la línea de comandos rundll32 C:\WINDOWS\System32\pbrtl.dll,#1.

El loader de código shell del registro comienza su operación descifrando la ruta al código shell cifrado almacenado en el registro de Windows, utilizando RC4. Sospechamos que la ruta es única para cada víctima; en el caso analizado aquí, la ruta del registro era:

Software\Classes\CLSID\{5abc7f42-1112-5099-b082-ce8d65ba0c47}\cAbRGHLg

Laclave raíz del registro es HKLM o HKCU, dependiendo de si el proceso actual se está ejecutando con privilegios elevados o no. La misma lógica se puede encontrar en otros componentes.

A continuación, el loader obtiene una clave RC4 específica de la máquina utilizando el UUID del sistema recuperado de la tabla de firmware SMBIOS sin procesar. Con esta clave, carga, descifra y ejecuta el shellcode. Es importante destacar que este método de derivación de claves garantiza que no se producirá el descifrado correcto si el loader se ejecuta en un ordenador diferente.

Curiosamente, el loader también puede configurarse mediante un indicador en su sección.data para utilizar una clave codificada para descifrar el shellcode, en lugar de la específica de la máquina.

En el recursoVERSIONINFO de este y otros componentes PE,hemos detectado un ataque con homoglifos que imita a Microsoft Corporation . Este método emplea distintos caracteres Unicode que parecen visualmente similares, pero en este caso no idénticos, a los caracteres originales, concretamente la letra mayúscula griega San (U+03FA, Ϻ) y la letra minúscula cirílica O (U+043E, о) en ϺicrоsоftCorpоratiоn.

Código shell del registro

El código shell del registro consta de dos partes: una rutina de descifrado y un cuerpo cifrado. Enprimer lugar, la rutina de descifrado gira cada byte del cuerpo cifrado uno a la izquierda (ROL 0x01). A continuación, se transfiere el control a este cuerpo descifrado. El cuerpo descifrado consta de un loader PE y un archivo PE, siendo este último el Executor, que representa la parte nativa del backdoor. Este loader se encarga de analizar y cargar el archivo PE asociado.

Executor

Executor es la parte nativa x64 del backdoor Deadglyph, que hace lo siguiente:

• carga su configuración,
• inicializa el tiempo de ejecución .NET,
• carga la parte .NET embebida del backdoor (el Orchestrator), y
• actúa como una biblioteca para el Orchestrator.

En primer lugar, se descifran mediante AES dos configuraciones predeterminadas incrustadas en la sección .data. Las configuraciones abarcan varios parámetros, incluyendo claves de cifrado, ajustes de seguridad y evasión, y el punto de entrada del componente posterior.

Durante la ejecución inicial, esas dos configuraciones predeterminadas se almacenan en el registro de Windows, desde donde se cargan en ejecuciones posteriores, lo que permite la implementación de actualizaciones. La ruta del registro para cada configuración se genera con el siguiente formato:

{HKCU|HKLM}\Software\Classes\CLSID\{<variable_GUID>}(Por defecto)

<variable_GUID> es un GUID generado, que es único para cada víctima.

A continuación, se inicializa el tiempo de ejecución de .NET y, a continuación, el  descifra con RC4 la parte .NET del backdoor, conocida como Orchestrator. El Orchestrator se encuentra en la sección.rsrc del Executor. La configuración especifica el método de ejecución del Orchestrator como punto de entrada. Además, se proporciona una estructura distinta para facilitar la accesibilidad de las funciones del Executor por parte de Orchestrator.

Después de lanzar el Orchestrator, el Executor actúa como una biblioteca de apoyo para Orchestrator. Executor contiene muchas funciones interesantes; describimos algunas de ellas en la siguiente sección, en el contexto de su utilización por el Orchestrator y otros módulos cargados.

Orchestrator

Escrito en .NET, Orchestrator es el componente principal del backdoor Deadglyph. La función principal de este componente consiste en establecer comunicación con el servidor de C&C y ejecutar comandos, a menudo facilitados a través de la función intermediaria de Executor. A diferencia de los componentes anteriores, Orchestrator está ofuscado, empleando .NET Reactor. Internamente, el backdoor se conoce como agente, que es un nombre común para la parte cliente en varios marcos de trabajo post-explotación.

Inicialización

El Orchestrator primero carga su configuración y dos módulos embebidos, cada uno acompañado por su propio conjunto de configuraciones, desde los recursos. Estos recursos están comprimidos con Deflate y encriptados con AES. Se hace referencia a ellos mediante un ID con hash SHA-1 en un nombre de recurso. En la tabla 1 seofrece una visión general de estos recursos .

Tabla 1. Recursos de Orchestrator

La configuración del Orchestrator y de los módulos integrados se almacena en formato XML. Un ejemplo de configuración de Orchestrator se muestra en Figura 4 .

La descripción de las entradas de configuración del Orchestrator se muestra en Tabla 2 .

Tabla 2. Entradas de configuración de Orchestrator

Una vez cargados los componentes de recursos, se crean varios subprocesos para llevar a cabo distintas tareas. Uno de estos hilos se encarga de realizar comprobaciones del entorno, función implementada dentro del Executor. Otro hilo se dedica a establecer comunicación periódica con el servidor C&C, permitiendo la recuperación de comandos. Por último, se emplea un conjunto de tres hilos para ejecutar los comandos recibidos y, posteriormente, transmitir al servidor de C&C los resultados generados.

El hilo de comprobación del entorno supervisa los procesos en ejecución para identificar los no deseados. Este hilo opera con dos listas distintas de nombres de procesos. Si se detecta un proceso en la primera lista, la comunicación con el C&C y la ejecución de comandos se detiene hasta que el proceso no deseado deje de existir. Si algún proceso de la segunda lista coincide, lel backdoor se cierra inmediatamente y se desinstala.

Ninguna de las dos listas estaba configurada en la instancia analizada, por lo que no sabemos qué procesos podrían comprobarse normalmente; creemos que probablemente su objetivo sea eludir las herramientas de análisis que podrían detectar actividad sospechosa y conducir al descubrimiento del backdoor.

Comunicación

Orchestrator utiliza dos módulos integrados para la comunicación C&C - Temporizador y Red. Al igual que el Orchestrator, estos módulos están ofuscados con .NET Reactor. La configuración para ambos módulos es suministrada por Orchestrator. Dentro de Orchestrator, se incluye una configuración preestablecida para los módulos; opcionalmente, también puede cargar una versión actualizada de la configuración desde el registro:

{HKCU|HKLM}\Software\Classes\CLSID\{<variable_GUID>}\<mod_cfg_res_ID>

El backdoor contiene una interesante medida de seguridad relacionada con la comunicación. Si el backdoor es incapaz de establecer comunicación con el servidor de C&C durante un tiempo superior a un umbral predefinido, configurado dentro del Executor, se activa un mecanismo de autodesinstalación. Este umbral de tiempo se especifica en horas y se fijó en una hora en el caso examinado.

Este enfoque tiene un doble objetivo. Por un lado, evita la generación de peticiones de red redundantes hacia un servidor inaccesible. Por otro lado, reduce las posibilidades de detección posterior si los operadores pierden el control sobre el backdoor.

Módulo temporizador

Este pequeño módulo ejecuta la llamada de retorno especificada en un intervalo configurable. Es utilizado por Orchestrator en combinación con el módulo de Red para comunicarse con el servidor de C&C periódicamente. Para prevenir la creación de patrones detectables en los registros de red, el intervalo de ejecución está sujeto a aleatoriedad, basado en un porcentaje especificado en la configuración. En el caso analizado, el intervalo se fijó en cinco minutos, con una variación de ±20% introducida para la aleatoriedad.

Otro método para evitar patrones de red detectables en la comunicación periódica puede encontrarse en la generación de peticiones enviadas al servidor C&C. Este mecanismo, implementado en el Executor, implica la inclusión de relleno de longitud variable, compuesto de bytes aleatorios, dentro de las peticiones, dando lugar a peticiones de diversos tamaños.

Módulo de red

El módulo Red implementa la comunicación con los servidores de C&C especificados en su configuración. Puede enviar datos a un servidor de C&C utilizando peticiones HTTP(S) POST. En particular, ofrece varios mecanismos para adquirir detalles de la configuración del proxy. Esta característica sugiere un enfoque potencial en entornos donde el acceso directo a Internet no está disponible.

Un ejemplo de una configuración desencriptada (y embellecida) se muestra en Figura 5 .

Las entradas de configuración contienen detalles relacionados con las comunicaciones de red - URLs de C&C, HTTP User-Agent, y opcionalmente una configuración proxy.

Cuando se comunica con el servidor C&C, se utiliza un protocolo binario personalizado con contenido encriptado bajo HTTPS.

Comandos

Orchestrator recibe comandos del servidor C&C en forma de tareas, que se ponen en cola para su ejecución. Hay tres tipos de tareas procesadas:

• Tareas de Orchestrator,
• Tareas de ejecutor y
• Tareas de carga.

Los dos primeros tipos se reciben del servidor C&C y el tercero se crea internamente para cargar la salida de comandos y errores.

Tareas de Orchestrator

Las tareas del Orchestrator ofrecen la posibilidad de gestionar la configuración de los módulos Red y Temporizador, y también de cancelar tareas pendientes. Lavisión general de las tareas de Orchertrator se muestra en Tabla 3 .

Tabla 3. Tareas de Orchestrator

Tareas ejecutoras

Las tareas ejecutoras ofrecen la posibilidad de gestionar el backdoor y ejecutar módulos adicionales. Cabe destacar que la funcionalidad tradicional del backdoor no está presente de forma inherente en el propio binario. En su lugar, estas funciones se obtienen del servidor de C&C en forma de archivos PE o shellcode. Se desconoce todo el potencial del backdoor sin estos módulos adicionales, que desvelan sus verdaderas capacidades. Una visión general de las tareas de los módulos se muestra en Tabla 4 , que incluye detalles sobre los pocos módulos identificados. Del mismo modo, Tabla 5 proporciona una visión general de las tareas de gestión asociadas con el Ejecutor.

Tabla 4. Tareas del ejecutor - módulos

Tabla 5. Tareas del ejecutor - gestión

El comando que establece la configuración del Ejecutor puede cambiar la:

• listas de procesos no deseados,
• umbral de tiempo de fallo de comunicación de C&C, y
• límite de tiempo de ejecución de módulos adicionales.

Módulos

Conseguimos obtener tres módulos únicos del servidor de C&C, cada uno correspondiente a un tipo de tarea de Ejecutor diferente, como se muestra en Tabla 4 . Basándonos en la información disponible, estimamos que hay entre nueve y catorce módulos en total. Como los módulos son de hecho comandos backdoor, tienen una operación básica que ejecutar y luego devolver opcionalmente su salida. Los módulos que obtuvimos son DLL con una exportación sin nombre (ordinal 1), en la que resuelven las funciones API necesarias y llaman a la función principal.

Cuando se ejecutan, los módulos disponen de una función de resolución de API, que puede resolver las API de Windows y las API de ejecutor personalizadas. Las API de Windows se referencian mediante un hash DWORD, calculado a partir del nombre de la API y su DLL. Los valores hash pequeños (<41) se tratan de forma especial, haciendo referencia a la función Executor API. La Executor API comprende un total de 39 funciones accesibles para los módulos. Estas funciones pertenecen a una variedad de operaciones, incluyendo:

• operaciones con archivos,
• cifrado y hashing,
• compresión,
• Carga de PE,
• suplantación de token de acceso, y
• utilidad.

En el resto de esta sección, describimos los módulos que hemos obtenido.

Creador de procesos

El módulo 0x69 ejecuta la línea de comandos especificada como un nuevo proceso y devuelve la salida resultante al Orchestrator. El proceso puede crearse bajo un usuario diferente, y su tiempo de ejecución puede limitarse. Cabe destacar que en la funcionalidad de este módulo se utiliza una API de trabajo poco habitual.

Este módulo fue servido con la línea de comandos cmd.exe /c tasklist /v.

Suponemos que sirve como comando inactivo emitido automáticamente, mientras los operadores esperan a que ocurra algo interesante en el ordenador comprometido.

Recopilador de información

El módulo 0x6C recopila información exhaustiva sobre el ordenador mediante consultas WMI y se la devuelve a Orchestrator. Se recopila información sobre lo siguiente

• sistema operativo,
• adaptadores de red,
• software instalado,
• unidades de disco,
• servicios,
• controladores,
• procesos,
• usuarios,
• variables de entorno y
• software de seguridad.

Lector de archivos

Elmódulo 0x64 lee el archivo especificado y devuelve el contenido a Orchestrator. Opcionalmente, puede eliminar el archivo después de la lectura.

Vimos este módulo utilizado para recuperar el archivo de datos de Outlook de la víctima

c:\Users\<redacted>\AppData\Local\Microsoft\Outlook\outlook.ost.

Cadena con downloader de shellcode

En el proceso de investigación de Deadglyph, encontramos un dudoso archivo CPL firmado con un certificado caducado y sin contrafirma con marca de tiempo, que había sido subido a VirusTotal desde Qatar. Tras un examen más detallado, se hizo evidente que este archivo CPL funcionaba como un downloader de shellcode multietapa, compartiendo ciertas similitudes de código con Deadglyph. Lacadena de carga se ilustra en Figura 6 .

En su forma inicial, que sirve como primera etapa, este archivo prevé tener una extensión.cpl (archivo del Panel de Control) y está destinado a ser ejecutado mediante una acción de doble clic. Una vez ejecutado de esta forma, el shellcode incrustado se somete a un descifrado XOR y se comprueban los procesos en ejecución para identificar un proceso host adecuado para su posterior inyección. 

Si se está ejecutando avp.exe (un proceso de seguridad de punto final de Kaspersky), se utiliza%windir%\system32\serAccountBroker.exe. De lo contrario, se utiliza el navegador por defecto. A continuación, crea el proceso host en un estado suspendido, inyecta el shellcode secuestrando su hilo principal y reanuda el hilo.

La segunda etapa, el shellcode, consta de dos partes. La primera parte del shellcode resuelve hashes de API, utilizando la misma técnica de cálculo de hash único empleada en Deadglyph, y descifra cadenas con nombres de procesos. Inicia un subproceso de autoborrado encargado de sobrescribir y posteriormente borrar el archivo de la primera etapa. A continuación, el shellcode procede a inspeccionar los procesos activos en ese momento, apuntando a una solución de seguridad.

Si se detecta alguno de los procesos especificados, el shellcode crea un subproceso durmiente con la prioridad más baja (THREAD_PRIORITY_IDLE) y le permite permanecer activo durante 60 segundos antes de finalizar su operación. Es probable que este intervalo se haya implementado como medida de precaución para eludir ciertos mecanismos de detección empleados por las soluciones de seguridad. Por último, el shellcode procede a invocar la ejecución de la segunda parte de su código.

La segunda parte del shellcode carga un archivo PE incrustado con la tercera etapa y llama a su exportación con el número ordinal 1.

La tercera etapa, una DLL, sirve como loader .NET y contiene la carga útil en su sección.rsrc.

Para cargar la carga útil, se inicializa el tiempo de ejecución de .NET. Durante la inicialización de .NET, se llevan a cabo dos técnicas intrigantes, aparentemente destinadas a evadir el escaneo de la Interfaz de Escaneo Antimalware de Windows (AMSI):

• El loader .NET engancha temporalmente la importación GetModuleHandleW en el clr.dll cargado , mientras llama a ICorRuntimeHost::Start. El gancho manipula el valor de retorno cuando se llama a GetModuleHandleW con NULL. Devuelve un puntero a un PE ficticio sin secciones.
• A continuación, parchea sutilmente la cadena de nombre de importación AmsiInitialize en la sección .rdata del clr.dll cargado a amsiinitialize.

La cuarta etapa es un ensamblado .NET, ofuscado con ConfuserEx, que sirve como downloader de shellcode. Primero, descifra XOR su configuración en formato XML a partir de sus recursos. Una versión embellecida de la configuración extraída se presenta en Figura 7 . Las entradas de configuración contienen detalles relacionados con la comunicación de red y los procesos bloqueados.

Antes de proceder, comprueba los procesos en ejecución comparándolos con una lista de procesos bloqueados de la configuración. Si se detecta una coincidencia, la ejecución se detiene. Es importante tener en cuenta que en el caso analizado, esta lista de bloqueo no estaba configurada.

A continuación, envía una solicitud HTTP GET al servidor de C&C para recuperar algún shellcode, utilizando los parámetros especificados en la configuración (URL, User-Agent y, opcionalmente, Proxy). Lamentablemente, durante nuestra investigación no pudimos obtener ningún shellcode del servidor de C&C. No obstante, nuestra hipótesis es que el contenido recuperado podría servir como instalador de Deadglyph.

A continuación, el shellcode recuperado se ejecuta en un subproceso recién creado. Tras esperar a que el hilo de shellcode termine de ejecutarse, el downloader de shellcode elimina todos los archivos ubicados en el directorio %WINDIR%\ServiceProfiles\LocalService\AppData\Local\Temp\TfsStore\Tfs_DAV.

Finalmente, hace un intento de borrarse a sí mismo después de un intervalo de 20 segundos, empleando el comando siguiente, antes de concluir su operación y salir:

cmd.exe choice /C Y /N /D Y /T 20 & Del /f /q <ruta_de_exceso_del_proceso_actual>

Este autoborrado no tiene sentido en esta cadena. Esto se debe al hecho de que el downloader de shellcode se ejecuta dentro de un navegador o proceso del sistema después de ser inyectado, en lugar de funcionar como un ejecutable independiente. Además, el archivo inicial ya se había eliminado en la segunda etapa. Esta observación sugiere que el downloader de Shell code podría no ser una carga útil exclusiva de esta cadena y que también podría utilizarse por separado en otras operaciones.

Conclusión

Hemos descubierto y analizado un sofisticado backdoor utilizado por el grupo Stealth Falcon al que hemos denominado Deadglyph. Tiene una arquitectura inusual, y sus capacidades de backdoor son proporcionadas por su C&C en forma de módulos adicionales. Conseguimos obtener trés de estos módulos, descubriendo una fracción de todas las capacidades de Deadglyph.

En particular, Deadglyph cuenta con una serie de mecanismos de contra-detección, incluyendo la monitorización continua de los procesos del sistema y la implementación de patrones de red aleatorios. Además, el backdoor es capaz de desinstalarse a sí mismo para minimizar la probabilidad de ser detectado en ciertos casos.

Además, nuestra investigación nos llevó al descubrimiento de una convincente cadena downloader de shellcode de múltiples etapas en VirusTotal. Sospechamos que es probable que esta cadena de descarga se aproveche en el proceso de instalación de Deadglyph.

IoCs

Archivos

Certificados

Servidores C&C

Técnicas ATT&CK de MITRE

Esta tabla se ha elaborado utilizando la versión 13 del marco MITRE ATT&CK.