LunarWeb y LunarMail: dos backdoors que comprometieron misiones diplomáticas europeas

Los investigadores de ESET descubrieron dos backdoors, a los que denominamos LunarWeb y LunarMail, que comprometieron a un Ministerio de Asuntos Exteriores (MAE) europeo y a sus misiones diplomáticas en el extranjero. Creemos que el conjunto de herramientas Lunar se ha utilizado al menos desde 2020 y, dadas las similitudes entre las tácticas, técnicas y procedimientos (TTP) de las herramientas y las actividades anteriores, atribuimos estos ataques al infame grupo de ciberespionaje Turla, alineado con Rusia, con una confianza media.

Recientemente presentamos nuestras conclusiones de esta investigación en la conferencia ESET World de este año y proporcionamos más detalles sobre nuestros hallazgos en este blogpost.

Puntos clave del blogpost:

• ESET Research descubrió dos backdoors - LunarWeb y LunarMail - utilizados en el compromiso de un Ministerio de Asuntos Exteriores europeo y sus misiones diplomáticas.
• LunarWeb, desplegado en servidores, utiliza HTTP(S) para sus comunicaciones de C&C e imita peticiones legítimas, mientras que LunarMail, desplegado en estaciones de trabajo, se persiste como un complemento de Outlook y utiliza mensajes de correo electrónico para sus comunicaciones de C&C.
• Ambos backdoors emplean la técnica de la esteganografía, ocultando comandos en imágenes para evitar ser detectados.
• Ambos backdoors utilizan un loader que utiliza el nombre de dominio DNS para descifrar la carga útil, comparten partes de sus bases de código y tienen la capacidad inusual de poder ejecutar scripts Lua.
• El loader puede adoptar diversas formas, incluido el software de código abierto troyanizado, lo que demuestra las avanzadas técnicas utilizadas por los atacantes.

Turla, también conocido como Snake, está activo al menos desde 2004, y es posible que incluso se remonte a finales de la década de 1990. Turla, que se cree que forma parte del FSB ruso, se dirige principalmente a entidades de alto nivel, como gobiernos y organizaciones diplomáticas de Europa, Asia Central y Oriente Próximo. El grupo es conocido por vulnerar importantes organizaciones, como el Departamento de Defensa de Estados Unidos en 2008 y la empresa de defensa suiza RUAG en 2014. En los últimos años, hemos documentado gran parte del arsenal de Turla en WeLiveSecurity.

Nuestra investigación actual comenzó con la detección de un loader que descifraba y ejecutaba una carga útil, desde un archivo externo, en un servidor no identificado. Esto nos llevó al descubrimiento de un backdoor al que denominamos LunarWeb. Posteriormente, detectamos una cadena similar con LunarWeb desplegada en una institución diplomática de un MAF europeo. Cabe destacar que el atacante también incluyó un segundo backdoor -que denominamos LunarMail- que utiliza un método diferente para las comunicaciones de mando y control (C&C).

Durante otro ataque, observamos despliegues simultáneos de una cadena con LunarWeb en tres instituciones diplomáticas de este MAF en Oriente Medio, que se produjeron con pocos minutos de diferencia. El atacante probablemente tenía acceso previo al controlador de dominio del MAF y lo utilizó para el movimiento lateral a máquinas de instituciones relacionadas en la misma red.

Un examen más detallado permitió descubrir otras piezas del rompecabezas, como los componentes utilizados en la fase inicial del ataque y un número limitado de comandos emitidos por el agresor. Las marcas de tiempo de las muestras más antiguas y las versiones de las bibliotecas utilizadas sugieren que este conjunto de herramientas ha estado operativo desde al menos 2020, posiblemente antes. Nuestro análisis técnico se centra en las técnicas que emplean estas puertas traseras, como la esteganografía, y en los métodos de comunicación.

Victimología

Según la telemetría de ESET, las máquinas comprometidas que logramos identificar pertenecen a un MAF europeo y están relacionadas principalmente con sus misiones diplomáticas en Oriente Medio.

Análisis técnico

Acceso inicial

No sabemos exactamente cómo se obtuvo el acceso inicial en ninguno de los casos comprometidos. Sin embargo, los componentes recuperados relacionados con la instalación y la actividad del atacante sugieren un posible spearphishing y un abuso del software de monitorización de redes y aplicaciones Zabbix mal configurado. Un componente de instalación LunarWeb que imita los registros de Zabbix y un comando backdoor recuperado utilizado para obtener la configuración del agente de Zabbix sugieren un posible abuso de Zabbix. Además, las pruebas de spearphishing incluyen un documento de Word que instala un backdoor LunarMail a través de una macro maliciosa.

A continuación, proporcionamos detalles de los componentes relacionados con la instalación y la actividad inicial del atacante.

Etapa 0 - Compromiso inicial del servidor LunarWeb

Aunque no tenemos la imagen completa del ataque inicial, encontramos un componente relacionado con la instalación en uno de los ataques al servidor: una versión compilada de una página web ASP.NET originada a partir de los siguientes archivos de origen:

• <IIS_web_root>\aspnet_client\system_web.aspx
• <IIS_web_root> <aspnet_client\system_web.cs

El nombre de archivo system_web.asp x es un IoC conocido de Hafnium, una APT alineada con China conocida por explotar vulnerabilidades en el software Microsoft Exchange Server. Sin embargo, creemos que se trata de una coincidencia o de una bandera falsa.

Cuando se solicita la página system_web.aspx, responde con un registro de agente Zabbix de aspecto benigno. Sin embargo, la página espera encubiertamente una contraseña en una cookie llamada SMSKey. Si se proporciona, la contraseña (combinada con la sal Microsoft.SCCM.Update.Manager) se utiliza para derivar una clave AES-256 y un IV para descifrar dos blobs incrustados, que luego se depositan en dos archivos temporales en un directorio excluido del análisis.

Aunque desconocemos la contraseña, el tamaño de los archivos coincide con otras etapas de la cadena de compromiso (el loader de la etapa 1 y el blob de la etapa 2) que contienen la puerta trasera LunarWeb. Por último, el atacante o un componente desconocido renombra y mueve los dos archivos temporales a sus destinos finales, y configura la persistencia.

Durante nuestra investigación, descubrimos que el atacante ya tenía acceso a la red, utilizó credenciales robadas para el movimiento lateral y tomó medidas cuidadosas para comprometer el servidor sin levantar sospechas. Los pasos del atacante incluyeron la copia de dos archivos de registro a través de la red; estos archivos fueron nombrados deliberadamente para imitar los registros del agente Zabbix. El atacante los movió al directorio web de IIS como la página system_web, y envió una petición HEAD a la página con una contraseña, lo que resultó en la creación de dos archivos con extensiones de nombre de archivo .tmp. A continuación, se eliminaron los archivos de la página system_web y los archivos .tmp eliminados que contenían las Etapas 1 y 2 se movieron a las siguientes ubicaciones:

• C:\Windows\System32\en-US\winnet.dll.mui
• C:\Windows\System32\DynamicAuth.bin

Finalmente, para mantener el acceso y ejecutar su código, el atacante configuró una extensión de directiva de grupo en el registro utilizando el servicio Remote Registry.

Etapa 0 - Compromiso del usuario inicial de LunarMail

En otro ataque, encontramos un documento de Word malicioso antiguo, probablemente procedente de un correo electrónico de spearphishing. A pesar de ser un archivo DOC, en realidad está en formato DOCX, que es un archivo ZIP que puede contener contenido adicional. Este documento tiene componentes inusuales: versiones de 32 y 64 bits de un loader de la fase 1, y un blob de la fase 2 que contiene el backdoor de LunarMail.

Se instalan mediante una macro VBA, ejecutada al abrir el documento, que hace lo siguiente:

1. Calcula un ID de víctima a partir del nombre del ordenador e informa a su servidor de C&C haciendo ping a una URL específica con el ID en su subdominio.
2. Crea el directorio %USERPROFILE%\Gpg4win y extrae los archivos apropiados del contenido extra en el ZIP/DOCX - Stage 1 loader a gpgol.dll y Stage 2 blob a tempkeys.dat.
3. Establece la persistencia a través de la configuración del registro del complemento de Outlook y hace ping a otra URL que contiene el ID.

No obtuvimos el documento completo, pero probablemente contiene un señuelo lo suficientemente tentador, ya que no se puede acceder a él de otro modo, para convencer a la víctima de que habilite las macros.

Las rutas y nombres utilizados imitan al complemento de Outlook de Gpg4win, GpgOL. Una vez desplegado, el loader de la fase 1 aparece en los complementos de Outlook, como se muestra en la Figura 1.

Lunar Toolset

Siguiendo nuestro análisis de los instaladores introducidos en la sección anterior, examinamos los loaderes y terminamos con el análisis de sus cargas útiles: dos backdoors previamente desconocidos. La Figura 2 muestra los componentes de las dos cadenas de compromiso observadas.

Etapa 1 - LunarLoader

La cadena de ejecución comienza con un loader que hemos denominado LunarLoader. Utiliza RC4, un cifrado de clave simétrica, para descifrar la ruta al blob de la Etapa 2 y lee de él una carga cifrada. Para asegurar que sólo una instancia del loader está activa, intenta abrir y luego crear un mailslot con un nombre único, en lugar de un objeto de sincronización común como mutex o event. También crea una clave de descifrado, derivada del hash MD5 del nombre de dominio DNS del ordenador, que verifica. A continuación, la carga útil se descifra utilizando AES-256, dando como resultado un archivo PE. LunarLoader asigna memoria para la imagen PE y descifra el nombre de una función exportada en el archivo PE, que se ejecuta en un nuevo hilo. Esta función contiene un loader reflexivo.

El uso del nombre de dominio DNS para el descifrado de la carga útil sirve como barrera de protección de la ejecución. El loader se ejecuta correctamente sólo en la organización objetivo, lo que puede dificultar el análisis si no se conoce el nombre de dominio.

LunarLoader puede tener una forma independiente o formar parte de un software de código abierto troyanizado. Observamos un caso de esto último, con un AdmPwd troyanizado, que forma parte de la Solución de contraseñas de administrador local (LAPS) de Windows.

Observamos que LunarLoader utiliza tres métodos de persistencia diferentes y varias rutas de archivos, como se muestra en la Tabla 1.

Tabla 1. Variantes de LunarLoader Variantes de LunarLoader

Etapa 2 blob - contenedor del payload

El blob utilizado en la Etapa 2 consta de cuatro entradas - incluyendo dos cadenas no utilizadas, donde el valor de una es la versión codificada en base64 de la cadena freedom or death o freedom or death (yeah,we are alive), como se muestra en la Figura 3, y versiones de 32 y 64 bits del payload.

Aunque el propósito de la cadena de freedom or death en el contexto dado no se explica explícitamente, es habitual que los autores de malware incluyan este tipo de cadenas por diversas razones posibles, como rastrear diferentes versiones de su malware, servir de distracción o pista falsa para los analistas, o simplemente como una forma de firma o tarjeta de visita. En algunos casos, encontramos cadenas en lugar de una carga útil de 32 bits, como la cadena shit happens.

Observamos dos backdoors diferentes utilizados como cargas útiles. Los backdoors parecen utilizar los siguientes nombres DLL en el directorio de exportación, con estos significados sospechosos:

• mswt[ e].dll - transporte web(LunarWeb)
• msmt[ e].dll - transporte de correo(LunarMail)

El sufijo e se utiliza para las versiones de 64 bits. Las rutas de archivo observadas para el blob se enumeran en la sección IoCs.

Payload de la fase 2 nº 1: backdoor LunarWeb

LunarWeb, la primera carga útil que descubrimos, es un backdoor que se comunica con su servidor de C&C mediante HTTP(S) y ejecuta los comandos que recibe. Observamos que LunarWeb se desplegaba únicamente en servidores, no en estaciones de trabajo de usuarios.

Durante su inicialización, LunarWeb intenta localizar o crear su archivo de estado, que contiene entradas relacionadas con su ejecución. A continuación, descifra cadenas, en su mayoría relacionadas con la comunicación, utilizando RC4 con la clave estática C1 82 A7 04 21 B6 40 C8 9A C3 79 AD F5 5F 72 86. También recopila datos de identificación de la víctima y los utiliza para calcular un ID de víctima, que se utiliza en las comunicaciones con el servidor de C&C.

Tras realizar las comprobaciones de seguridad, el backdoor espera unas horas antes de entrar en su bucle de comunicación. Este retraso se salta en la primera ejecución del backdoor. Las comprobaciones de seguridad incluyen un límite de intentos de contacto inicial con el servidor de C&C, la evaluación de la vida útil de la puerta trasera y la comprobación de la accesibilidad del servidor de C&C. Si falla alguna de las condiciones de seguridad, LunarWeb se autoelimina, borrando sus archivos, incluidos el loader de la Etapa 1 y el blob de la Etapa 2. Sin embargo, el método de persistencia para el loader de la Etapa 1 se mantiene, dejando rastros potencialmente detectables.

Configuración y estado

La configuración de LunarWeb está codificada en el binario, probablemente a partir de cambios manuales en el código fuente. La configuración varía entre muestras, incluyendo los servidores C&C, su umbral de inalcanzabilidad, el formato de comunicación y la vida útil del backdoor.

La puerta trasera mantiene una estructura de estado de 512 bytes, actualizada durante la ejecución y almacenada en un archivo. Este archivo contiene tres ranuras de estado, a las que se accede por los índices 0, 1 ó 2, como se muestra en la Figura 4. Las dos primeras ranuras son modificables. Las dos primeras ranuras son modificables, pero no son utilizadas por esta puerta trasera; sólo se utiliza la tercera ranura. Las ranuras de estado se cifran utilizando RC4 con la clave 99 53 EA 6A AB 29 44 EF BE 36 12 9E F2 3B 5E C9.

Las ubicaciones observadas de los archivos de estado se enumeran en la sección IoCs.

Recopilación de información

LunarWeb recopila la siguiente información sobre el ordenador anfitrión:

• identificación única de la víctima obtenida mediante consultas WMI
  • versión del sistema operativo con número de serie,
  • Versión de la BIOS con número de serie, y
  • nombre de dominio.
• más información del sistema obtenida mediante comandos shell
  • información sobre el ordenador y el sistema operativo (salida de systeminfo.exe),
  • variables de entorno,
  • adaptadores de red,
  • lista de procesos en ejecución,
  • lista de servicios y
  • lista de productos de seguridad instalados.

La información se envía al servidor C&C en el primer contacto.

Comunicación

Tras la inicialización, LunarWeb se comunica con su servidor de C&C utilizando HTTP(S), bajo el cual se encuentra un protocolo binario personalizado con contenido cifrado.

LunarWeb emplea tres URLs (que contienen direcciones IP en lugar de dominios) para diferentes propósitos. Una URL se utiliza para el primer contacto, cargando información sobre el ordenador anfitrión como se describe en la sección anterior. Las dos URL restantes se utilizan para obtener comandos, estando cada una en un servidor diferente. A continuación nos referiremos a estas URL como URL de comandos.

Para ocultar sus comunicaciones de C&C, LunarWeb se hace pasar por tráfico de aspecto legítimo, falseando las cabeceras HTTP con dominios auténticos y atributos de uso común. También puede recibir comandos ocultos en imágenes. Los atributos suplantados de cada muestra observada de LunarWeb se muestran en la Tabla 2.

Tabla 2. Atributos suplantados Atributos suplantados

Ejemplos notables de suplantación incluyen servicios de Windows (Teredo, Windows Update) y actualizaciones de productos ESET. En los casos de suplantación de ESET, los atacantes copiaron el User-Agent (donde deslizaron una cabecera Host) y otras cabeceras utilizadas por las actualizaciones de nuestro producto. Curiosamente, suplantaron un dominio inexistente en la cabecera Host.

La identificación de la víctima se incluye en las peticiones HTTP, ya sea en una cookie o en un parámetro de consulta URL. El primer método utiliza cookies generadas aleatoriamente con un identificador de 16 bytes (posiblemente un ID de campaña) y un ID de víctima. El segundo método añade el identificador de la víctima dos veces a la URL. El ID de campaña sospechoso está presente en las muestras que utilizan el segundo método, pero no se utiliza. LunarWeb también puede utilizar un servidor proxy HTTP para las comunicaciones de C&C, si es necesario.

Recepción de comandos

LunarWeb recoge comandos del servidor de C&C a través de una petición GET a la URL del comando. La petición y el formato de respuesta varían a través de cinco formatos soportados, con un valor hardcoded determinando cual usar. La Tabla 3 proporciona una visión general de estos formatos. Observamos el uso de los formatos 2, 3 y 4.

Tabla 3. Formatos de comunicación para obtener comandos

Dependiendo del formato de comunicación, los datos recibidos del servidor C&C pueden necesitar decodificación usando el algoritmo base64 o extracción de una imagen. Los JPG se escanean en busca del marcador de comentario FF FE, mientras que los GIF se analizan utilizando la biblioteca giflib. En ambos casos, los datos interesantes están incrustados en las estructuras del formato de imagen y no ocultos en píxeles individuales de una imagen, como en la esteganografía LSB, por ejemplo.

Los formatos de comunicación 0 y 1, aunque no se observan, simplemente descifran los datos resultantes utilizando RSA-4096. Los formatos 2, 3 y 4 son más complejos. Los datos resultantes comienzan con una semilla AES cifrada, descifrada con RSA-4096 y utilizada para obtener una clave de sesión. Esta clave de sesión se utiliza entonces para descifrar el resto de los datos mediante AES-256, seguido de la descompresión zlib.

Tras el descifrado y, si es necesario, la descompresión, los datos recibidos dan lugar a un paquete de comandos. Este paquete, que posee un ID único, se compara con el último ID procesado, almacenado en el estado del backdoor. Si son diferentes, la puerta trasera procesa el paquete y actualiza el último ID. El paquete puede contener varios comandos. Cada comando se ejecuta, y su salida se envía al servidor de C&C en un único formato, sin esteganografía, como se describe en la siguiente sección Exfiltración de datos.

Para realizar operaciones criptográficas, LunarWeb utiliza una biblioteca TLS Mbed enlazada estáticamente. Tiene dos claves RSA-4096 incrustadas: una para descifrar los datos entrantes y otra para cifrar los salientes. Ambas utilizan parámetros estándar y están descritas en nuestro repositorio de GitHub.

Exfiltración de datos

En primer lugar, los datos se comprimen con zlib y se cifran utilizando AES-256, con una clave de sesión y un IV derivados del tamaño de los datos, produciendo también un código de autenticación de mensajes basado en hash(HMAC).

Para el cifrado AES, se genera una semilla AES aleatoria de 32 bytes y se cifra utilizando RSA-4096. La semilla se utiliza para derivar una clave de sesión de una manera similar a PBKDF, SHA-256 hash de la semilla y un IV 8.192 veces. La misma derivación de clave se realiza al descifrar los datos recibidos. El algoritmo de derivación y el código de cifrado se copiaron de un antiguo programa de ejemplo TLS de Mbed que se retiró de la biblioteca en 2021.

Por último, se envían los datos cifrados, junto con los metadatos de descifrado e integridad. Si los datos de salida superan 1,33 MB tras la compresión, se dividen en varias partes de tamaño aleatorio(384-512 KB).

Las peticiones POST al servidor C&C incluyen cabeceras de suplantación e identificación de la víctima, y su envío se retrasa entre 34 y 40 segundos. Curiosamente, cada paquete de comandos recibido contiene una URL de salida, que es donde enviar el resultado. Puede tratarse de una URI diferente en el mismo servidor de C&C, o de un servidor completamente distinto. En el número limitado de paquetes de comandos que observamos, la URL de salida era la misma que la URL del comando.

Comandos

LunarWeb soporta capacidades comunes de backdoor, incluyendo operaciones de archivos y procesos, y la ejecución de comandos shell, incluyendo algunos a través de PowerShell. Destaca uno de los comandos, con la capacidad poco común de poder ejecutar código Lua.

La lista completa de comandos soportados, con detalles adicionales, se muestra en la Tabla 4.

Tabla 4. Visión general de los comandos de LunarWeb

Algunos de los comandos pueden mostrar un mensaje de error refiriéndose a los comandos como tareas - Format of the task is incorrect.

Pudimos recuperar un paquete de comandos que contenía múltiples comandos shell utilizados para el reconocimiento ejecutados a través del comando 1, recopilando lo siguiente: información del sistema y del SO, información de usuario, configuración y conexiones de red, variables de entorno, tareas programadas, programas instalados y productos de seguridad, configuración del cortafuegos, listados de directorios, tickets y sesiones Kerberos, recursos compartidos, directiva de grupo y pertenencia a grupos locales. Además, se utilizó un comando de lectura de archivos(7) para recuperar la configuración de Zabbix desde una ruta de archivo especificada.

Carga útil de la fase 2: puerta trasera LunarMail

El segundo backdoor, al que llamamos LunarMail, comparte muchas similitudes con LunarWeb. La principal diferencia es el método de comunicación: LunarMail utiliza el correo electrónico para comunicarse con su servidor de C&C.

Este backdoor está diseñado para desplegarse en estaciones de trabajo de usuarios, no en servidores, porque es persistente y está pensado para ejecutarse como un complemento de Outlook. En la Figura 5 se muestra un resumen de alto nivel del funcionamiento de LunarMail.

LunarMail comparte ideas de su funcionamiento con LightNeuron, otro backdoor de Turla que utiliza mensajes de correo electrónico para fines de C&C. Aunque ambos utilizan un método de exfiltración similar, no encontramos ninguna similitud de código entre los dos backdoors. Otros backdoors de Turla con funcionamiento similar incluyen Outlook backdoor.

Inicialización

Durante su inicialización, el backdoor descifra una cadena utilizada para inicializar un objeto regex que se utiliza como filtro para buscar el perfil de correo electrónico a utilizar con fines de C&C, que describiremos más adelante. La expresión regex, y otras cadenas de la puerta trasera, se cifran utilizando RC4 con la clave estática E3 7C 9E B0 DF D1 46 48 B4 AE 8A 5F 2A A1 78 7B.

Para interactuar con Outlook, el backdoor resuelve dinámicamente las funciones necesarias de la API de mensajería de Outlook (MAPI ).

En cada ejecución, el backdoor crea un directorio en la ruta %TEMP%\{<random_guid>}, utilizado como directorio de almacenamiento para la filtración de datos.

Configuración y estado

Al igual que LunarWeb, las entradas de configuración de LunarMail están codificadas en el binario. También mantiene un archivo de estado, con un único estado (a diferencia de LunarWeb, que tiene múltiples ranuras de estado).

La configuración probablemente consiste en condiciones para encontrar un perfil de Outlook para las comunicaciones C&C, la configuración de exfiltración por defecto y el límite de vida útil del backdoor.

El estado se guarda en el archivo %LOCALAPPDATA%\Microsoft\Outlook\outlk.share con una estructura de 668 bytes, que se actualiza durante la ejecución. Almacena, entre otros, una marca de tiempo del último comando ejecutado y el directorio de preparación actual. En ejecuciones posteriores, el directorio de almacenamiento anterior se elimina y se sustituye por uno nuevo.

Recogida de información

En la primera ejecución, la puerta trasera de LunarMail recopila la siguiente información:

• variables de entorno, y
• destinatarios de todos los mensajes de correo electrónico enviados (direcciones de correo electrónico).

Además, se descifra un archivo por lotes con comandos de shell para obtener más información del sistema, pero nunca se ejecuta.

En determinados casos de error, como la imposibilidad de recopilar la información mencionada, se recopilan las direcciones de correo electrónico de los perfiles de Outlook disponibles.

Comunicación y comandos

Al ejecutarse dentro de Outlook, la puerta trasera LunarMail se comunica con su servidor de C&C -recibiendo comandos y extrayendo datos- mediante mensajes de correo electrónico, a través de la API de mensajería de Outlook (MAPI).

Búsqueda de perfiles

Para comunicarse, LunarMail busca primero los perfiles de Outlook adecuados proporcionados por Microsoft Exchange. Las condiciones del perfil incluyen tener sólo cuatro carpetas predeterminadas (Bandeja de entrada, Enviados, Eliminados y Bandeja de salida), contener el dominio de la institución objetivo en la dirección de correo electrónico y no coincidir con un patrón regex para varios correos electrónicos institucionales legítimos.

El primer perfil coincidente envía la información inicial. Para la comunicación posterior, se buscan en las bandejas de entrada de los perfiles candidatos los correos electrónicos que contengan comandos. Este enfoque evita la codificación rígida de perfiles y dificulta la identificación. Además, los comandos pueden establecer un perfil específico para su uso, que se mantiene en el estado de la puerta trasera.

Recepción de comandos

LunarMail identifica un perfil con comandos buscando mensajes de correo electrónico e intentando analizar sus archivos adjuntos. El archivo adjunto debe ser una única imagen PNG con la extensión .png, con un tamaño inferior o igual a 10 MB. A continuación, intenta analizar los fragmentos IDAT del archivo PNG, buscando una semilla AES, una configuración de exfiltración y fragmentos de comandos. Todos estos componentes están comprimidos con zlib y cifrados, el primero con RSA-4096 y los dos últimos con AES.

Curiosamente, los chunks deben ajustarse al formato PNG con CRC verificados, lo que da como resultado una imagen válida pero de aspecto ruidoso debido al contenido cifrado y comprimido.

LunarMail utiliza la misma criptografía que LunarWeb, incluyendo la librería Mbed TLS, dos claves RSA-4096 (listadas en nuestro repositorio GitHub), y el uso de AES-256 con el mismo algoritmo de derivación de claves. El fragmento descomprimido con contenido cifrado mediante AES tiene una estructura similar a la que se ve en LunarWeb.

La configuración de exfiltración descifrada y descomprimida tiene una estructura específica que incluye el ID de configuración, la dirección de correo electrónico, el asunto, el cuerpo y el nombre y extensión del archivo adjunto.

La estructura de la configuración de exfiltración refleja los metadatos del paquete de comandos de LunarWeb, especificando el destino de las salidas de comandos y un ID para evitar la duplicación de comandos, almacenados en estado. Una vez descifrados y descomprimidos, los comandos de LunarMail tienen una estructura idéntica a los de LunarWeb. Cada comando analizado se ejecuta, almacenando la salida en el directorio de preparación para la exfiltración.

En particular, los mensajes de correo electrónico que no se analizan en busca de comandos tienen sus ID almacenados en caché para evitar el análisis repetido, aunque la caché no se mantiene y se vuelve a crear en cada ejecución del backdoor. Los mensajes de correo electrónico analizados correctamente en busca de comandos se eliminan tras su procesamiento.

Comandos

En términos de capacidades de comandos, LunarMail es más simple y cuenta con un subconjunto de los comandos que se encuentran en LunarWeb. Puede escribir un archivo, crear un nuevo proceso, y únicamente, tomar una captura de pantalla y modificar la dirección de correo electrónico de comunicación del C&C. Aunque LunarMail carece de comandos separados para ejecutar comandos shell o PowerShell, sí soporta scripts Lua. Cuando se ejecutan, los comandos escriben su salida en archivos en el directorio de montaje.

La lista completa de comandos soportados se muestra en la Tabla 5.

Tabla 5. Comandos de LunarMail Visión general de los comandos de LunarMail

Exfiltración de datos - preparación

LunarMail busca en su directorio de almacenamiento los archivos de salida producidos por la puerta trasera, y los prepara para la exfiltración incrustándolos en una imagen PNG o en un documento PDF (dependiendo de la extensión del archivo adjunto en la configuración de la exfiltración). Tanto los archivos PNG como los PDF se crean utilizando una plantilla de contenido válida.

Para los archivos PNG, se utiliza una plantilla que coincide con el logotipo de la institución comprometida, lo que indica conocimiento previo y preparación de la puerta trasera. Para crear un PNG que contenga archivos de salida, LunarMail genera primero una semilla AES aleatoria de 32 bytes, utilizada para el cifrado. A continuación, crea trozos IDAT con datos y los añade a la plantilla PNG. Los chunks son similares a los comandos recibidos, conteniendo lo siguiente:

• Chunk con semilla AES - encriptado RSA-4096, comprimido zlib.
• Chunk(s) con nombre de archivo y contenido - encriptado AES-256, comprimido zlib.

Antes de la compresión y el cifrado, el nombre de archivo de salida y el contenido se envuelven en una estructura que también contiene una cadena mágica 001035 que podría ser la versión backdoor. Al igual que en los PNG de comandos recibidos, los trozos creados siguen la especificación PNG y se calcula su suma de comprobación CRC, lo que garantiza una imagen válida. Para finalizar la imagen, se añade el trozo de pie de página IEND .

El segundo método, que produce un archivo PDF, utiliza una plantilla cifrada del archivo %TEMP%\l4_mgrT.tmp. No hemos observado este archivo de datos y se desconoce el contenido de la plantilla, pero probablemente se trate de un documento benigno y poco sospechoso.

Los archivos de salida con metadatos se insertan al final del último flujo de la plantilla PDF, antes de la palabra clave de endstream. Se insertan en el siguiente formato y orden:

1. Archivos de salida - tamaño variable, comprimidos con zlib, cifrados con AES-256.
2. Metadatos - tamaño fijo (512 bytes), encriptados RSA-4096.

El nombre del archivo de salida y el contenido se envuelven en la misma estructura que con el PNG, incluida la cadena mágica, que luego se comprime y encripta.

Los metadatos contienen la información necesaria para analizar y descifrar las estructuras de los archivos de salida, incluida la semilla AES y las posiciones del archivo de salida en el archivo PDF.

Tras el procesamiento y la incrustación en el archivo PNG o PDF, se eliminan los archivos creados para la exfiltración. El archivo creado reside temporalmente en el directorio de puesta en escena hasta la exfiltración.

Exfiltración de datos - transmisión

Las imágenes PNG preparadas o los documentos PDF que contienen archivos de salida se transmiten como archivos adjuntos en correos electrónicos a una bandeja de entrada controlada por el atacante, según la configuración de exfiltración. La configuración predeterminada de LunarMail incluye un correo electrónico específico del destinatario, el encabezado del asunto, el cuerpo del mensaje y el nombre del archivo adjunto. El contenido del correo electrónico, aunque está en el idioma de la AMF europea comprometida, parece traducido automáticamente debido a su redacción poco natural.

La configuración de exfiltración de un comando recibido anula la configuración por defecto. No hemos recuperado ningún comando, por lo que no sabemos si se utilizan diferentes destinatarios, asuntos, cuerpos o nombres o tipos de archivos adjuntos en varios comandos.

Si es compatible, el cuerpo del correo electrónico utiliza el formato HTML. El PNG se incrusta como imagen en el cuerpo, a diferencia del PDF. La Figura 6 muestra una ilustración de un correo electrónico de exfiltración basado en la configuración predeterminada. El correo fue traducido, redactado y el logo fue cambiado por ESET Research, para no revelar la institución comprometida.

Los mensajes de correo electrónico de exfiltración se envían con la bandera PR_DELETE_AFTER_SUBMIT. Además, se eliminan todos los mensajes enviados a la dirección de exfiltración.

Conclusión

Hemos descrito dos puertas traseras desconocidas hasta ahora utilizadas para comprometer las instituciones de un gobierno europeo, que atribuimos con una confianza media al grupo APT Turla, alineado con Rusia.

Los backdoors comparten un loader, presentan solapamientos de código y admiten comandos similares, pero adoptan métodos de comunicación de C&C diferentes. El primer backdoor, LunarWeb, utiliza HTTP(S) e intenta pasar desapercibido imitando el tráfico de servicios legítimos como Windows Update. El segundo, LunarMail, se apoya en Outlook y se comunica a través de mensajes de correo electrónico, utilizando imágenes PNG o documentos PDF para filtrar datos.

Observamos distintos grados de sofisticación en los ataques; por ejemplo, la cuidadosa instalación en el servidor afectado para evitar el escaneado por parte del software de seguridad contrasta con los errores de codificación y los distintos estilos de codificación (que no son objeto de este artículo) en las puertas traseras. Esto sugiere que es probable que varias personas participaran en el desarrollo y el funcionamiento de estas herramientas.

Aunque las amenazas descritas son más recientes, nuestros hallazgos muestran que estas puertas traseras han evadido la detección durante un período más largo y han estado en uso desde al menos 2020, basándonos en los artefactos encontrados en el conjunto de herramientas Lunar.

IoCs

Puede encontrar una lista completa de IoCs y muestras en nuestro repositorio GitHub.

Archivos

Rutas de archivos

Etapa 2 blob

C:WindowsSystem32DynamicAuth.bin

C:\Program Files\LAPS\CSE\admpwd.cache

C:ArchivosDeProgramaMicrosoftWinThumbadcache.clb

C:\Windows\System32\perfcache.dat

%USERPROFILE%\Gpg4win\tempkeys.dat

Archivo de estado de LunarWeb

C:\ProgramData\Microsoft\Windows\Templates\content.tpl

C:\ProgramData\Microsoft\WinThumb\thumb.clb

C:ProgramaDatosMicrosoftWinThumb.clb

C:\Windows\System32\perfconfm.dat

Archivo de estado de LunarMail

%LOCALAPPDATA%Microsoft\Outlook\outlk.share

Red

Claves del registro

HKCU\SOFTWARE\Classes\CLSID\{3115036B-547E-4673-8479-EE54CD001B9D}\

Técnicas ATT&CK de MITRE

Esta tabla se construyó utilizando la versión 15 del marco MITRE ATT&CK.