Stealth Falcon acechando los cielos del Medio Oriente con Deadglifo

Durante años, Oriente Medio ha mantenido su reputación como terreno fértil para amenazas persistentes avanzadas (APT). En medio del monitoreo rutinario de actividades sospechosas en los sistemas de clientes de alto perfil, algunos de ellos con sede en esta región, ESET Research se topó con una puerta trasera muy sofisticada y desconocida a la que hemos llamado Deadglyph. Derivamos el nombre de los artefactos encontrados en la puerta trasera (como 0xDEADB001, mostrado también en REF _Ref111452440h Mesa 1
), junto con la presencia de un homoglifo ataque. Hasta donde sabemos, este es el primer análisis público de esta puerta trasera no documentada anteriormente, utilizada por un grupo que exhibe un grado notable de sofisticación y experiencia. Con base en los objetivos y la evidencia adicional, atribuimos Deadglyph con alta confianza al grupo Stealth Falcon APT.

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

Los comandos tradicionales de puerta trasera no se implementan en el binario de puerta trasera; en cambio, los recibe dinámicamente desde el servidor de comando y control (C&C) en forma de módulos adicionales. Esta puerta trasera también presenta una serie de capacidades para evitar ser detectado.

En esta publicación de blog, analizamos más de cerca Deadglyph y brindamos un análisis técnico de esta puerta trasera, su propósito y algunos de los componentes adicionales que obtuvimos. También presentaremos nuestros hallazgos sobre Deadglyph en el LABScon 2023 conferencia.

Puntos clave de la publicación del blog:

• ESET Research descubrió una puerta trasera sofisticada con una arquitectura inusual a la que hemos llamado Deadglyph.
• Los componentes principales se cifran mediante una clave específica de la máquina.
• Los comandos de puerta trasera tradicionales se implementan a través de módulos adicionales recibidos de su servidor C&C.
• Obtuvimos tres de muchos módulos: creador de procesos, lector de archivos y recopilador de información.
• Atribuimos Deadglyph al grupo Stealth Falcon.
• Además, encontramos un descargador de shellcode relacionado; Postulamos que podría usarse potencialmente para la instalación de Deadglyph.

La víctima de la infiltración analizada es una entidad gubernamental de Medio Oriente que fue comprometida con fines de espionaje. También se subió a la plataforma de escaneo de archivos una muestra relacionada encontrada en VirusTotal desde esta región, específicamente desde Qatar. La región objetivo se muestra en el mapa en REF _Ref143614671h 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, se sabe que Stealth Falcon apunta a activistas políticos, periodistas y disidentes en Medio Oriente. Fue descubierto y descrito por primera vez por Citizen Lab, que publicó un análisis de una campaña de ataques de software espía en 2016.

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

En septiembre de 2019, nosotros investigación publicada en una puerta trasera, atribuida a Stealth Falcon, que utilizaba una técnica inusual, Servicio de transferencia inteligente en segundo plano, para comunicación C&C. Ahora revelamos el resultado de nuestro análisis en profundidad de lo que presumiblemente es la última incorporación al conjunto de herramientas de espionaje de Stealth Falcon.

Puerta trasera de glifo muerto

La cadena de carga de Deadglyph consta de múltiples componentes, como se ilustra en REF _Ref144978760h Figura 3
. El componente inicial es un cargador de código shell del registro, que carga el código shell del registro. Este código shell extraído, a su vez, carga la parte x64 nativa de la puerta trasera: el Ejecutor. Posteriormente, el Ejecutor carga la parte .NET de la puerta trasera: el Orquestador. En particular, el único componente en el disco del sistema como archivo es el componente inicial, que tiene la forma de una biblioteca de vínculos dinámicos (DLL). Los componentes restantes se cifran y almacenan dentro de un valor de registro binario.

Si bien aún no se ha determinado el método preciso del vector de compromiso inicial, sospechamos que un componente del instalador está involucrado en la implementación de componentes adicionales y el establecimiento de persistencia dentro del sistema.

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

Cargador de código shell de registro

El componente inicial de Deadglyph es una pequeña DLL con una única exportación, llamada 1. Este componente persiste usando Suscripción a eventos de Instrumental de administración de Windows (WMI) y sirve como cargador de código shell de registro. Se ejecuta a través de la línea de comando. rundll32 C:WINDOWSSystem32pbrtl.dll,#1.

El cargador de shellcode del registro comienza su operación descifrando la ruta al shellcode cifrado almacenado en el registro de Windows, utilizando RC4. Sospechamos que el camino es único para cada víctima; en el caso aquí analizado, la ruta del registro fue:

SoftwareClassesCLSID{5abc7f42-1112-5099-b082-ce8d65ba0c47}cAbRGHLg

La clave del registro raíz es HKLM or 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.

Después de esto, el cargador obtiene una clave RC4 específica de la máquina utilizando el UUID del sistema recuperado del tabla de firmware SMBIOS sin formato. Usando esta clave, carga, descifra y luego ejecuta el código shell. Es importante resaltar que este enfoque de derivación de claves garantiza que no se producirá un descifrado adecuado si el cargador se ejecuta en una computadora diferente.

Curiosamente, el cargador también se puede configurar mediante una bandera en su .datos sección para utilizar una clave codificada para descifrar el código shell, en lugar de la específica de la máquina.

Detectamos un ataque de homoglifos que imitaba a Microsoft Corporation en el INFORMACIÓN DE LA VERSIÓN recurso de este y otros componentes de PE. Este método emplea distintos caracteres Unicode que parecen visualmente similares, pero en este caso no idénticos, a los caracteres originales, específicamente la letra mayúscula griega San (U+03FA, Ϻ) y la letra minúscula cirílica O (U+043E, о) en Ϻicrоsоft corporaciónоratiоn.

Código shell de registro

Compuesto de dos partes, el shellcode del registro consta de una rutina de descifrado y un cuerpo cifrado. Primero, la rutina de descifrado rota cada byte del cuerpo cifrado hacia la izquierda uno (ROL 0x01). Posteriormente, el control se transfiere a este organismo descifrado. El cuerpo descifrado consta de un cargador PE y un archivo PE, siendo este último el Ejecutor, que representa la parte nativa de la puerta trasera. Este cargador es responsable de analizar y cargar el archivo PE asociado.

Ejecutor

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

• carga su configuración,
• inicializa el tiempo de ejecución de .NET,
• carga la parte .NET integrada de la puerta trasera (el Orchestrator) y
• Actúa como una biblioteca para el orquestador.

Primero, dos configuraciones predeterminadas integradas en el .datos La sección está descifrada en AES. Las configuraciones abarcan varios parámetros, incluidas claves de cifrado, configuraciones 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 de registro para cada configuración se genera con el siguiente formato:

{HKCU|HKLM}ClaseDeSoftwareCLSID{ }(Por defecto)

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

Después de esto, se inicializa el tiempo de ejecución de .NET y luego el Executor RC4 descifra la parte .NET de la puerta trasera conocida como Orchestrator. El orquestador está ubicado dentro del .rsrc sección del Ejecutor. 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 el acceso del Orquestador a las funciones del Ejecutor.

Después de iniciar Orchestrator, Executor actúa como biblioteca de soporte para Orchestrator. El Ejecutor contiene muchas funciones interesantes; Describimos algunos de ellos en la siguiente sección, en el contexto de su utilización por parte del Orchestrator y otros módulos cargados.

Orquestador

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

Inicialización

Orchestrator primero carga su configuración y dos módulos integrados, cada uno acompañado de su propio conjunto de configuraciones, desde los recursos. Estos recursos son Desinflar comprimido y AES cifrado. Se hace referencia a ellos mediante un ID que tiene un hash SHA-1 en un nombre de recurso. Se proporciona una descripción general de estos recursos en REF _Ref111452440h Mesa 1
.

Tabla 1. Recursos del orquestador

Nombre del recurso	ID (decimal)	ID (hexadecimal)	Descripción
43ed9a3ad74ed7ab74c345a876b6be19039d4c8c	2570286865	0x99337711	Configuración del orquestador.
3a215912708eab6f56af953d748fbfc38e3bb468	3740250113	0xDEEFB001	Módulo de red.
42fb165bc9cf614996027a9fcb261d65fd513527	3740250369	0xDEEFB101	Configuración del módulo de red.
e204cdcf96d9f94f9c19dbe385e635d00caaf49d	3735924737	0xDEADB001	Módulo temporizador.
abd2db754795272c21407efd5080c8a705a7d151	3735924993	0xDEADB101	Configuración del módulo temporizador.

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

La descripción de las entradas de configuración de Orchestrator se muestra en REF _Ref111452782h Mesa 2
.

Tabla 2. Entradas de configuración del orquestador

Una vez cargados los componentes del recurso, se crean varios subprocesos para realizar distintas tareas. Uno de estos subprocesos es responsable de realizar comprobaciones del entorno, una función implementada dentro del Ejecutor. Otro hilo está dedicado 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 subprocesos con el fin de ejecutar los comandos recibidos y posteriormente transmitir cualquier salida generada al servidor C&C.

El hilo de verificación del entorno monitorea 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 C&C y la ejecución de comandos se pausan hasta que el proceso no deseado ya no exista. Si hay una coincidencia para algún proceso en la segunda lista, la puerta trasera se cierra inmediatamente y se desinstala.

Ninguna lista se configuró en la instancia analizada, por lo que no sabemos qué procesos normalmente se pueden verificar; Creemos que probablemente tenga como objetivo evadir las herramientas de análisis que podrían detectar actividades sospechosas y conducir al descubrimiento de la puerta trasera.

Comunicación

Orchestrator utiliza dos módulos integrados para la comunicación C&C: temporizador y red. Al igual que Orchestrator, estos módulos están ofuscados con .NET Reactor. La configuración de ambos módulos la proporciona Orchestrator. Dentro del Orchestrator, se incluye una configuración preestablecida para los módulos; Opcionalmente, Orchestrator también puede cargar una versión de configuración actualizada desde el registro:

{HKCU|HKLM}ClaseDeSoftwareCLSID{ }

La puerta trasera contiene una interesante medida de seguridad relacionada con la comunicación. Si la puerta trasera no puede establecer comunicación con el servidor C&C durante un período que supera un umbral predefinido, configurado dentro del Ejecutor, 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 propósito. Por un lado, evita la generación de solicitudes de red redundantes hacia un servidor inaccesible. Por otro lado, reduce las posibilidades de detección posterior si los operadores pierden el control sobre la puerta trasera.

Módulo temporizador

Este pequeño módulo ejecuta la devolución de llamada especificada en un intervalo configurable. El orquestador lo utiliza en combinación con el módulo de red para comunicarse periódicamente con el servidor C&C. Para evitar la creación de patrones detectables en los registros de red, el intervalo de ejecución está sujeto a aleatorización, según un porcentaje especificado en la configuración. En el caso analizado, el intervalo se estableció en cinco minutos, con una variación de ±20% introducida por aleatoriedad.

Otro método para evitar patrones de red detectables en la comunicación periódica se puede encontrar en la generación de solicitudes enviadas al servidor C&C. Este mecanismo, implementado en el Ejecutor, implica la inclusión de relleno de longitud variable, compuesto por bytes aleatorios, dentro de las solicitudes, lo que resulta en solicitudes de diversos tamaños.

Módulo de red

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

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

Las entradas de configuración contienen detalles relacionados con las comunicaciones de red: URL de C&C, agente de usuario HTTP y, opcionalmente, una configuración de proxy.

Al comunicarse con el servidor C&C, se utiliza un protocolo binario personalizado con contenido cifrado debajo de HTTPS.

Comandos

El orquestador 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 del orquestador,
• Tareas del ejecutor, y
• Subir tareas.

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 del orquestador

Las tareas de Orchestrator ofrecen la posibilidad de gestionar la configuración de los módulos de Red y Temporizador, y también de cancelar tareas pendientes. La descripción general de las tareas de Orchestrator se muestra en REF _Ref111101783h Mesa 3
.

Tabla 3. Tareas del orquestador

Tareas del ejecutor

Las tareas del ejecutor ofrecen la capacidad de administrar la puerta trasera y ejecutar módulos adicionales. Es notable que la funcionalidad tradicional de puerta trasera no esté inherentemente presente dentro del propio binario. En cambio, estas funciones se obtienen del servidor C&C en forma de archivos PE o código shell. El alcance total del potencial de la puerta trasera sigue siendo desconocido sin estos módulos adicionales, que efectivamente desbloquean sus verdaderas capacidades. Una descripción general de las tareas del módulo se muestra en REF _Ref117677179h Mesa 4
, que incluye detalles sobre los pocos módulos identificados. Similarmente, REF _Ref117677188h Mesa 5
proporciona una descripción general de las tareas de gestión asociadas con el Ejecutor.

Tabla 4. Tareas del ejecutor – módulos

Tipo de Propiedad	Descripción
0x??–0x63	Desconocido
0x64	Lector de archivos
0x65	Desconocido
0x66	Desconocido
0x67	Desconocido
0x68	Desconocido
0x69	Creador de procesos
0x6A	Desconocido
0x6B	Desconocido
0x6C	Recopilador de información
0x6D	Desconocido
0x6E	Desconocido

Tabla 5. Tareas del ejecutor – gestión

Tipo de Propiedad	Descripción
0x6F-0x76	No se ha implementado
0x77	Establecer la configuración del ejecutor
0x78	Obtener la configuración del Ejecutor
0x79-0x7C	No se ha implementado
0x7D	Actualizar
0x7E	Dejar
0x7F	Desinstalar

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

• listas de procesos no deseados,
• Umbral de tiempo de falla de comunicación C&C, y
• límite de tiempo para la ejecución de módulos adicionales.

Módulos

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

Cuando se ejecutan, los módulos cuentan con 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 están referenciadas 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 API Executor comprende un total de 39 funciones a las que pueden acceder los módulos. Estas funciones pertenecen a una variedad de operaciones, que incluyen:

• operaciones de archivos,
• cifrado y hash,
• compresión,
• carga de PE,
• acceder a la suplantación de tokens, y
• utilidad.

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

Creador de procesos

Módulo 0x69 ejecuta la línea de comando especificada como un nuevo proceso y proporciona el resultado resultante al Orchestrator. El proceso se puede crear con un usuario diferente y su tiempo de ejecución puede ser limitado. Cabe destacar una inusual API de trabajo se utiliza en la funcionalidad de este módulo.

Este módulo fue servido con la línea de comando. cmd.exe /c lista de tareas /v.

Suponemos que sirve como un comando inactivo emitido automáticamente, mientras los operadores esperan que suceda algo interesante en la computadora comprometida.

Recopilador de información

Módulo 0x6C recopila amplia información sobre la computadora a través de consultas WMI y la devuelve al Orchestrator. Se recopila información sobre lo siguiente:

• sistema operativo,
• adaptadores de red,
• software instalado,
• unidades,
• servicios,
• conductores,
• procesos,
• usuarios,
• variables de entorno, y
• programa de seguridad

Lector de archivos

Módulo 0x64 lee el archivo especificado y devuelve el contenido al orquestador. Opcionalmente, puede eliminar el archivo después de leerlo.

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

c: Usuarios AppDataLocalMicrosoftOutlookoutlook.ost.

Cadena con descargador de shellcode

En el proceso de investigación de Deadglyph, encontramos un archivo CPL dudoso firmado con un certificado caducado y sin firma con marca de tiempo, que había sido subido a VirusTotal desde Qatar. Tras un examen más detenido, se hizo evidente que este archivo CPL funcionaba como un descargador de código shell de varias etapas, compartiendo ciertas semejanzas de código con Deadglyph. La cadena de carga se ilustra en REF _Ref143693067h Figura 6
.

En su forma inicial, que sirve como primera etapa, este expediente prevé tener una .cpl extensión (archivo del Panel de control) y debe ejecutarse mediante una acción de doble clic. Tras la ejecución de esta manera, el código shell incorporado se somete a un descifrado XOR y se verifican los procesos en ejecución para identificar un proceso host adecuado para la inyección posterior.

If avp.exe (un proceso de seguridad de endpoints de Kaspersky) se está ejecutando, %windir%system32UserAccountBroker.exe se utiliza. De lo contrario, se utiliza el navegador predeterminado. Luego, crea el proceso host en un estado suspendido, inyecta el código shell secuestrando su hilo principal y reanuda el hilo.

La segunda etapa, el código shell, consta de dos partes. La primera parte del código shell resuelve los hashes de API, utilizando la misma técnica única de cálculo de hash empleada en Deadglyph, y descifra cadenas con nombres de procesos. Inicia un hilo de autoeliminación encargado de sobrescribir y posteriormente borrar el archivo de la primera etapa. Después de esto, el código shell procede a inspeccionar los procesos actualmente activos, apuntando a una solución de seguridad.

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

La segunda parte del código shell carga un archivo PE incrustado con la etapa tres y llama a su exportación con un número ordinal. 1.

La tercera etapa, una DLL, sirve como cargador .NET y contiene la carga útil en su .rsrc .

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

• El cargador .NET engancha temporalmente el ObtenerModuleHandleW importar en el cargado clr.dll, mientras llama ICorRuntimeHost::Inicio. El gancho altera el valor de retorno cuando ObtenerModuleHandleW se llama con NULL. Devuelve un puntero a un PE ficticio sin secciones.
• Luego parchea sutilmente el AmsiInicializar importar cadena de nombre en el .rdata sección de la cargada clr.dll a amsiinicializar.

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

Antes de continuar, compara los procesos en ejecución con una lista de procesos bloqueados de la configuración. Si se detecta una coincidencia, la ejecución se detiene. Es importante señalar que en el caso analizado, esta lista de bloqueo no estaba configurada.

A continuación, envía una solicitud HTTP GET al servidor C&C para recuperar algún código shell, utilizando los parámetros especificados en la configuración (URL, Agente de usuario y, opcionalmente, Proxy). Lamentablemente, durante nuestra investigación no pudimos adquirir ningún código shell del servidor C&C. No obstante, planteamos la hipótesis de que el contenido que se recupera podría servir como instalador de Deadglyph.

Después de esto, el código shell recuperado se ejecuta dentro de un hilo recién creado. Después de esperar hasta que el subproceso Shellcode finalice la ejecución, el descargador de Shellcode elimina todos los archivos ubicados en el directorio. %WINDIR%ServiceProfilesLocalServiceAppDataLocalTempTfsStoreTfs_DAV.

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

elección de cmd.exe /CY /N /DY /T 20 & Del /f /q

Esta autoeliminación no tiene sentido en esta cadena. Esto se debe al hecho de que el descargador 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 fue eliminado en la segunda etapa. Esta observación sugiere que el descargador de shellcode podría no ser una carga útil exclusiva de esta cadena y también podría usarse por separado en otras operaciones.

Conclusión

Hemos descubierto y analizado una sofisticada puerta trasera utilizada por el grupo Stealth Falcon a la que hemos bautizado como Deadglyph. Tiene una arquitectura inusual y sus capacidades de puerta trasera las proporciona su C&C en forma de módulos adicionales. Logramos obtener tres de estos módulos, descubriendo una fracción de las capacidades completas de Deadglyph.

En particular, Deadglyph cuenta con una variedad de mecanismos de contradetección, incluido el monitoreo continuo de los procesos del sistema y la implementación de patrones de red aleatorios. Además, la puerta trasera es capaz de desinstalarse sola para minimizar la probabilidad de su detección en determinados casos.

Además, nuestra investigación nos llevó al descubrimiento de una convincente cadena de descarga de shellcode de varias etapas en VirusTotal. Sospechamos que esta cadena de descarga probablemente se aproveche del proceso de instalación de Deadglyph.

Para cualquier consulta sobre nuestra investigación publicada en WeLiveSecurity, contáctenos en amenazaintel@eset.com.
ESET Research ofrece fuentes de datos e informes de inteligencia APT privados. Para cualquier consulta sobre este servicio, visite el Inteligencia de amenazas de ESET .

IoC

archivos

SHA-1	Nombre del archivo	Detección	Descripción
C40F1F46D230A85F702DAA38CFA18D60481EA6C2	pbrtl.dll	Win64/Deadglifo.A	Cargador de código Shell de registro.
740D308565E215EB9B235CC5B720142428F540DB	N/A	Win64/Deadglifo.A	Puerta trasera de Deadglifo – Ejecutor.
1805568D8362A379AF09FD70D3406C6B654F189F	N/A	MSIL/Deadglifo.A	Puerta trasera de Deadglyph – Orquestador.
9CB373B2643C2B7F93862D2682A0D2150C7AEC7E	N/A	MSIL/Deadglifo.A	Módulo de red del orquestador.
F47CB40F6C2B303308D9D705F8CAD707B9C39FA5	N/A	MSIL/Deadglifo.A	Módulo de temporizador del orquestador.
3D4D9C9F2A5ACEFF9E45538F5EBE723ACAF83E32	N/A	Win64/Deadglifo.A.gen	Módulo creador de procesos.
3D2ACCEA98DBDF95F0543B7C1E8A055020E74960	N/A	Win64/Deadglifo.A	Módulo lector de archivos.
4E3018E4FD27587BD1C566930AE24442769D16F0	N/A	Win64/Deadglifo.A	Módulo recopilador de información.
7F728D490ED6EA64A7644049914A7F2A0E563969	N/A	Win64/Inyector.MD	Primera etapa de la cadena de descarga de shellcode.

Certificados

Número de serie	00F0FB1390F5340CD2572451D95DB1D92D
Impresión del pulgar	DB3614DAF58D041F96A5B916281EA0DC97AA0C29
Asunto CN	RHM LIMITADO
Sujeto O	RHM LIMITADO
Sujeto L	St. Albans
Asignaturas	Hertfordshire
Sujeto C	GB
Correo electrónico	rhm@rhmlimited[.]co.uk
Válida desde	2021-03-16 00:00:00
Válido hasta	2022-03-16 23:59:59

Servidores C&C

IP	Dominio	Visto por primera vez	Comentario
185.25.50[.]60	ajedrezyenlaces[.]com	2021-08-25	Servidor C&C de Deadglifo.
135.125.78[.]187	easymathpath[.]com	2021-09-11	Servidor C&C de Deadglifo.
45.14.227[.]55	únete a salud[.]com	2022-05-29	Servidor C&C del descargador de Shellcode.

Técnicas MITRE ATT & CK

Esta tabla fue construida usando Versión 13 del marco MITRE ATT & CK.

Táctica	ID	Nombre	Descripción
Desarrollo de recursos	T1583.001	Adquirir infraestructura: dominios	Stealth Falcon ha registrado dominios para servidores C&C y para obtener un certificado de firma de código.
	T1583.003	Adquirir Infraestructura: Servidor Privado Virtual	Stealth Falcon ha utilizado proveedores de alojamiento VPS para servidores C&C.
	T1587.001	Desarrollar capacidades: malware	Stealth Falcon ha desarrollado malware personalizado, incluidos cargadores personalizados y la puerta trasera Deadglyph.
	T1588.003	Obtener capacidades: certificados de firma de código	Stealth Falcon ha obtenido un certificado de firma de código.
Ejecución	T1047	Instrumental de administración de Windows	Deadglyph usa WMI para ejecutar su cadena de carga.
	T1059.003	Intérprete de comandos y secuencias de comandos: Shell de comandos de Windows	Usos del descargador de Shellcode cmd.exe para borrarse a sí mismo.
	T1106	API nativa	Un módulo Deadglifo utiliza CrearProcesoW y CrearProcesoComoUsuarioW Funciones API para su ejecución.
	T1204.002	Ejecución del usuario: archivo malicioso	La cadena de descarga de Shellcode requiere que el usuario haga doble clic y la ejecute.
Persistencia	T1546.003	Ejecución desencadenada por eventos: suscripción a eventos del Instrumental de administración de Windows	El cargador inicial de Deadglyph persiste mediante la suscripción de eventos WMI.
Evasión de defensa	T1027	Archivos o información ofuscados	Los componentes de Deadglifo están cifrados. Deadglyph Orchestrator y los módulos integrados están ofuscados con .NET Reactor. El descargador de shellcode está ofuscado con ConfuserEx.
	T1070.004	Eliminación del indicador: eliminación de archivos	Deadglyph puede desinstalarse solo. La cadena de descarga de shellcode se elimina a sí misma y elimina archivos en el caché WebDAV.
	T1112	Modificar registro	Deadglyph almacena su configuración y carga útil cifrada en el registro.
	T1134	Manipulación de tokens de acceso	Deadglifo puede hacerse pasar por otro usuario.
	T1140	Desofuscar / decodificar archivos o información	Deadglifo descifra cadenas cifradas. La cadena de descarga de shellcode descifra sus componentes y configuraciones.
	T1218.011	Ejecución de proxy binario del sistema: Rundll32	El cargador inicial de Deadglyph se ejecuta usando rundll32.exe.
	T1480.001	Barandillas de ejecución: clave ambiental	Deadglifo se cifra utilizando una clave específica de la máquina derivada del UUID del sistema.
	T1562.001	Debilitar defensas: deshabilitar o modificar herramientas	El descargador de shellcode evita el escaneo AMSI mediante parches clr.dll en memoria .
	T1620	Carga de código reflectante	Deadglifo carga reflexivamente sus módulos utilizando un cargador PE personalizado.
Descubrimiento de moléculas	T1007	Descubrimiento de servicios del sistema	A El módulo Deadglyph descubre servicios mediante la consulta WMI SELECCIONE * DE Win32_Service.
	T1012	Registro de consultas	La cadena de descarga de shellcode consulta el registro para encontrar el navegador predeterminado.
	T1016	Descubrimiento de la configuración de la red del sistema	Un módulo Deadglyph descubre adaptadores de red mediante consultas WMI SELECCIONE * DE Win32_NetworkAdapter y SELECCIONE * DE Win32_NetworkAdapterConfiguration donde InterfaceIndex=%d.
	T1033	Descubrimiento de propietario/usuario del sistema	Un módulo Deadglyph descubre usuarios con la consulta WMI SELECCIONAR * DE Win32_UserAccount.
	T1057	Descubrimiento de procesos	Un módulo Deadglyph descubre procesos mediante consultas WMI SELECCIONAR * DE Win32_Process.
	T1082	Descubrimiento de información del sistema	Un módulo Deadglyph descubre información del sistema, como la versión del sistema operativo, unidades, variables de entorno y controladores mediante consultas WMI.
	T1518	Descubrimiento de software	Un módulo Deadglyph descubre el software instalado mediante una consulta WMI SELECCIONAR * DE Win32_Product.
	T1518.001	Descubrimiento de software: Descubrimiento de software de seguridad	Un módulo Deadglyph descubre software de seguridad mediante consultas WMI SELECCIONAR * DEL Producto AntiVirus, SELECCIONAR * DEL Producto AntiSpyware y SELECCIONAR * DE FirewallProducto. La cadena de descarga de shellcode verifica los procesos en ejecución en busca de una solución de seguridad.
Colecciones	T1005	Datos del sistema local	Deadglyph tiene un módulo para leer archivos.
Comando y control	T1071.001	Protocolo de capa de aplicación: protocolos web	Deadglyph y el descargador de shellcode se comunican con el servidor C&C a través del protocolo HTTP.
	T1090	apoderado	Deadglyph y el descargador de shellcode pueden usar un proxy HTTP para la comunicación C&C.
	T1573.001	Canal cifrado: criptografía simétrica	Deadglyph utiliza AES para cifrar las comunicaciones de C&C.
exfiltración	T1041	Exfiltración sobre canal C2	Deadglyph utiliza el canal C&C para la exfiltración.

• Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
• PlatoData.Network Vertical Generativo Ai. Empodérate. Accede Aquí.
• PlatoAiStream. Inteligencia Web3. Conocimiento amplificado. Accede Aquí.
• PlatoESG. Carbón, tecnología limpia, Energía, Ambiente, Solar, Gestión de residuos. Accede Aquí.
• PlatoSalud. Inteligencia en Biotecnología y Ensayos Clínicos. Accede Aquí.
• Fuente: https://www.welivesecurity.com/en/eset-research/stealth-falcon-preying-middle-eastern-skies-deadglyph/