Los investigadores de ESET descubrieron una campaña de Ballistic Bobcat dirigida a varias entidades en Brasil, Israel y los Emiratos Árabes Unidos, utilizando un nuevo backdoor que hemos denominado Sponsor.

Descubrimos Sponsor después de analizar una muestra interesante que detectamos en el sistema de una víctima en Israel en mayo de 2022 y analizamos el conjunto de víctimas por país. Tras examinar la muestra, nos dimos cuenta de que se trataba de un nuevo backdoor desplegado por el grupo Ballistic Bobcat APT.

Ballistic Bobcat, previamente rastreado por ESET Research como APT35/APT42 (también conocido como Charming Kitten, TA453 o PHOSPHORUS), es un supuesto grupo de amenazas persistentes avanzadas alineado con Irán que tiene como objetivo organizaciones educativas, gubernamentales y sanitarias, así como activistas de derechos humanos y periodistas. Es más activo en Israel, Oriente Próximo y Estados Unidos. En particular, durante la pandemia se dirigió contra organizaciones relacionadas con COVID-19, incluidas la Organización Mundial de la Salud y Gilead Pharmaceuticals, y contra personal de investigación médica.

Los solapamientos entre las campañas de Ballistic Bobcat y las versiones backdoor de Sponsor muestran un patrón bastante claro de desarrollo y despliegue de la herramienta, con campañas dirigidas a objetivos concretos y de duración limitada. Posteriormente descubrimos otras cuatro versiones del backdoor Sponsor. En total, vimos el despliegue de Sponsor en al menos 34 víctimas en Brasil, Israel y los Emiratos Árabes Unidos, como se indica en Figura 1 .

Puntos clave de este blogpost:

• Descubrimos un nuevo backdoor desplegado por Ballistic Bobcat que posteriormente denominamos Sponsor.
• Ballistic Bobcat desplegó el nuevo backdoor en septiembre de 2021, mientras concluía la campaña documentada en la alerta AA21-321A de CISA y la campaña PowerLess.
• El backdoor Sponsor utiliza archivos de configuración almacenados en disco. Estos archivos se despliegan discretamente mediante archivos por lotes y se diseñan deliberadamente para que parezcan inocuos, intentando así eludir la detección por parte de los motores de análisis.
• Sponsor se desplegó en al menos 34 víctimas de Brasil, Israel y los Emiratos Árabes Unidos; hemos denominado a esta actividad campaña Sponsor Access.

Acceso inicial

Ballistic Bobcat obtuvo el acceso inicial aprovechando vulnerabilidades conocidas en servidores Microsoft Exchange expuestos a Internet, realizando primero escaneos meticulosos del sistema o la red para identificar posibles puntos débiles o vulnerabilidades, y posteriormente atacando y explotando esos puntos débiles identificados. Se sabe desde hace tiempo que el grupo lleva a cabo esta conducta. Sin embargo, muchas de las 34 víctimas identificadas en la telemetría de ESET podrían describirse mejor como víctimas de oportunidad en lugar de víctimas preseleccionadas e investigadas, ya que sospechamos que Ballistic Bobcat llevó a cabo el comportamiento de escaneo y explotación descrito anteriormente porque no era el único actor de amenazas con acceso a estos sistemas. Hemos bautizado esta actividad de Ballistic Bobcat con el backdoor Sponsor como campaña Sponsoring Access.

El backdoor Sponsor utiliza archivos de configuración en el disco, que se eliminan mediante archivos por lotes, y ambos son inocuos para evitar los motores de escaneado. Este enfoque modular es uno de los que Ballistic Bobcat ha utilizado con bastante frecuencia y con modesto éxito en los últimos dos años y medio. En los sistemas comprometidos, Ballistic Bobcat también sigue utilizando diversas herramientas de código abierto, que describimos -junto con el backdoor Sponsor- en esta entrada de blog.

Victimología

La mayoría de las 34 víctimas se encontraban en Israel, y sólo dos en otros países:

• Brasil, en una cooperativa médica y un operador de seguros de salud, y
• Emiratos Árabes Unidos, en una organización no identificada.

En el cuadro 1 se describen los verticales, y los detalles organizativos, de las víctimas en Israel.

Tabla 1. Verticales y detalles organizativos de las víctimas en Israel

Atribución

En agosto de 2021, la víctima israelí arriba mencionada que opera un mercado de seguros fue atacada por Ballistic Bobcat con las herramientas de las que CISA informó en noviembre de 2021. Los indicadores de compromiso que observamos son:

• MicrosoftOutlookUpdateSchedule,
• MicrosoftOutlookUpdateSchedule.xml,
• GoogleChangeManagement, y
• GoogleChangeManagement.xml.

Las herramientas Ballistic Bobcat se comunicaban con el mismo servidor de mando y control (C&C) que en el informe CISA: 162.55.137[.]20.

Después, en septiembre de 2021, la misma víctima recibió la siguiente generación de herramientas Ballistic Bobcat: la backdoor PowerLess y su conjunto de herramientas de apoyo. Los indicadores de compromiso que observamos fueron:

• http://162.55.137[.]20/gsdhdDdfgA5sS/ff/dll.dll,
• windowsprocesses.exe, y
• http://162.55.137[.]20/gsdhdDdfgA5sS/ff/windowsprocesses.exe.

El 18 de noviembrede 2021, el grupo desplegó otra herramienta (Plink) que aparecíaen el informe de CISA como MicrosoftOutLookUpdater.exe. Diez días después, el 28 de noviembre de 2021, Ballistic Bobcat desplegó el agente Merlin (la parte de agente de un servidor y agente de C&C de código abierto posterior a la explotación escrito en Go). En el disco, este agente Merlin se llamaba googleUpdate.exe, utilizando la misma convención de nomenclatura descrita en el informe CISA para ocultarse a plena vista.

El agente Merlin ejecutaba un shell inverso Meterpreter que devolvía en un nuevo servidor de C&C, 37.120.222[.]168:80. El 12 de diciembre de 2021, la shell inversa soltó un archivo por lotes, install.bat, y a los pocos minutos de ejecutarlo, los operadores de Ballistic Bobcat introdujeron su backdoor más reciente, Sponsor. Esta resultaría ser la tercera versión del backdoor.

Análisis técnico

Acceso inicial

Pudimos identificar un medio probable de acceso inicial para 23 de las 34 víctimas que observamos en la telemetría de ESET. Al igual que en los informes de PowerLess y CISA, Ballistic Bobcat probablemente explotó una vulnerabilidad conocida, CVE-2021-26855, en los servidores Microsoft Exchange para introducirse en estos sistemas.

En el caso de 16 de las 34 víctimas, parece que Ballistic Bobcat no era la única amenaza con acceso a sus sistemas. Esto puede indicar, junto con la gran variedad de víctimas y la aparente falta de valor de inteligencia sobre algunas víctimas, que Ballistic Bobcat se dedicó a un comportamiento de exploración y explotación, en lugar de una campaña dirigida contra víctimas preseleccionadas.

Conjunto de herramientas

Herramientas de código abierto

Ballistic Bobcat utilizó varias herramientas de código abierto durante la campaña Sponsoring Access. Dichas herramientas y sus funciones se enumeran en Tabla 2 .

Tabla 2. Herramientas de código abierto utilizadas por Ballistic Bobcat

Archivos por lotes

Ballistic Bobcat desplegó archivos por lotes en los sistemas de las víctimas momentos antes de desplegar el backdoor Sponsor. Las rutas de los archivos que conocemos son:

• C:\inetpub\wwwroot\aspnet_client\Install.bat
• %USERPROFILE%\Desktop\Install.bat
• %WINDOWS%\Tasks\Install.bat

Lamentablemente, no hemos podido obtener ninguno de estos archivos por lotes. Sin embargo, creemos que escriben en el disco archivos de configuración inocuos, que el backdoor Sponsor necesita para funcionar plenamente. Estos nombres de archivos de configuración fueron tomados de los backdoors Sponsor pero nunca fueron recogidos:

• config.txt
• nodo.txt
• error.txt
• Uninstall.bat

Creemos que los archivos por lotes y los archivos de configuración forman parte del proceso de desarrollo modular que Ballistic Bobcat ha favorecido en los últimos años.

Backdoor Sponsor

Los backdoor Sponsor están escritos en C++ con marcas de tiempo de compilación y rutas a la Base de Datos de Programas (PDB) como se muestra en Tabla 3 . Nota sobre los números de versión: la columna Versión representa la versión que rastreamos internamente basándonos en la progresión lineal de los backdoor Sponsor en los que se realizan cambios de una versión a la siguiente. La columna Versión interna contiene los números de versión observados en cada backdoor Sponsor y se incluyen para facilitar la comparación al examinar estas y otras posibles muestras de Sponsor.

Tabla 3. Marcas de tiempo de compilación y PDB de Sponsor

La ejecución inicial de Sponsor requiere el argumento de tiempo de ejecución install, sin el cual Sponsor sale de forma elegante, probablemente una simple técnica anti-emulación/anti-sandbox. Si se le pasa ese argumento, Sponsor crea un servicio llamado SystemNetwork (en v1) y Update (en el resto de versiones). Establece el Startup Type del servicio en Automatic, y lo configura para que ejecute su propio proceso Sponsor, y le concede acceso total. A continuación, inicia el servicio.

Sponsor, ahora ejecutándose como un servicio, intenta abrir los archivos de configuración antes mencionados, previamente colocados en el disco. Busca config.txt y node.txt, ambos en el directorio de trabajo actual. Si falta el primero, Sponsor establece el servicio en Stopped y sale del mismo.

Configuración de la puerta trasera

La configuración de Sponsor, almacenada en config.txt, contiene dos campos:

• Un intervalo de actualización, en segundos, para contactar periódicamente con el servidor de C&C en busca de comandos.
• Una lista de servidores de C&C, denominados relays en los binarios de Sponsor.

Los servidores C&C se almacenan cifrados (RC4), y la clave de descifrado está presente en la primera línea de config.txt. Cada uno de los campos, incluida la clave de descifrado, tiene el formato que se muestra en Figura 3 .

Estos subcampos son:

• config_start: indica la longitud de config_name, si está presente, o cero, si no. Utilizado por el backdoor para saber dónde empiezan los config_data.
• config_len: longitud de config_data.
• config_name: opcional, contiene un nombre dado al campo de configuración.
• config_data: la configuración propiamente dicha, cifrada (en el caso de los servidores C&C) o no (todos los demás campos).

La Figura 4 muestra un ejemplo con contenidos codificados por colores de un posible archivo config.txt. Nótese que no se trata de un archivo real que hayamos observado, sino de un ejemplo fabricado.

Los dos últimos campos de config.txt se cifran con RC4, utilizando la representación de cadena del hash SHA-256 de la clave de descifrado especificada, como clave para cifrar los datos. Vemos que los bytes cifrados se almacenan codificados hexadecimalmente como texto ASCII.

Recopilación de información sobre el host

Sponsor recopila información sobre el host en el que se está ejecutando, reporta toda la información recopilada al servidor C&C, y recibe un ID de nodo, que se escribe en node.txt. La Tabla 4 enumera las claves y valores del registro de Windows que Sponsor utiliza para obtener la información, y proporciona un ejemplo de los datos recogidos.

Tabla 4. Información recopilada por Sponsor

Sponsor también recopila el dominio Windows del host utilizando el siguiente comando WMIC:

wmic computersystem get domain

Porúltimo, Sponsor utiliza las API de Windows para obtener el nombre de usuario actual (GetUserNameW), determinar si el proceso actual de Sponsor se está ejecutando como una aplicación de 32 o 64 bits (GetCurrentProcess, luego IsWow64Process(CurrentProcess)), y determinar si el sistema se está ejecutando con batería o está conectado a una fuente de alimentación de CA o CC (GetSystemPowerStatus).

Una rareza respecto a la comprobación de aplicaciones de 32 o 64 bits, es que todas las muestras observadas de Sponsor eran de 32 bits. Esto podría significar que algunas de las herramientas de la siguiente fase requieren esta información.

La información recopilada se envía en un mensaje codificado en base64 que, antes de codificarse, empieza por r y tiene el formato que se muestra en Figura 5 .

La información se cifra con RC4, y la clave de cifrado es un número aleatorio generado in situ. La clave se hashea con el algoritmo MD5, no SHA-256 como se ha mencionado anteriormente. Este es el caso de todas las comunicaciones en las que Sponsor tiene que enviar datos cifrados.

El servidor de C&C responde con un número utilizado para identificar el ordenador víctima en comunicaciones posteriores, que se escribe en node.txt. Nótese que el servidor de C&C se elige aleatoriamente de la lista cuando se envía el mensajer, y se utiliza el mismo servidor en todas las comunicaciones posteriores.

Bucle de procesamiento de comandos

Sponsor solicita comandos en un bucle, entrando en espera según el intervalo definido en config.txt.

Los pasos son:

1. Enviar un mensaje chk=Test repetidamente, hasta que el servidor C&C responda Ok.
2. Envía un mensajec (IS_CMD_AVAIL) al servidor C&C, y recibe un comando de operador.
3. Procese el comando
   • Si hay output para ser enviado al servidor C&C, envía un mensajea (ACK), incluyendo el output (encriptada), o
   • Sil a ejecución falló, envía un mensajef (FAILED). El mensaje de error no se envía.
4. Sleep

El mensaje c se envía para solicitar un comando a ejecutar, y tiene el formato (antes de la codificación base64) que se muestra en Figura 6 .

El campo encrypted_none de la figura es el resultado de cifrar la cadena hardcoded None con RC4. La clave para el cifrado es el hash MD5 de node_id.

La URL utilizada para contactar con el servidor C&C se construye como: http://<IP_or_domain>:80. Esto puede indicar que 37.120.222[.]168:80 es el único servidor de C&C utilizado a lo largo de la campaña Sponsoring Access, ya que fue la única dirección IP a la que observamos que las máquinas de las víctimas contactaban a través del puerto 80.

Comandos del operador

Los comandos del operador se describen en Tabla 5 y aparecen en el orden en que se encuentran en el código. La comunicación con el servidor de C&C se produce a través del puerto 80.

Tabla 5. Comandos del operador y descripciones Comandos de operador y descripciones

Actualizaciones del patrocinador

Los codificadores de Ballistic Bobcat hicieron revisiones de código entre Sponsor v1 y v2. Los dos cambios más significativos de esta última son:

• Optimización del código donde varias funciones más largas fueron minimizadas en funciones y subfunciones, y
• Enmascaramiento de Sponsor como programa actualizador mediante la inclusión del siguiente mensaje, traducido al español, en la configuración del servicio:

Las actualizaciones de aplicaciones son excelentes tanto para los usuarios como para las aplicaciones: las actualizaciones significan que los desarrolladores siempre están trabajando para mejorar la aplicación, teniendo en cuenta una mejor experiencia del cliente con cada actualización.

Infraestructura de red

Además de aprovecharse de la infraestructura de C&C utilizada en la campaña PowerLess, Ballistic Bobcat también introdujo un nuevo servidor de C&C. El grupo también utilizó múltiples IPs para almacenar y entregar herramientas de soporte durante la campaña Sponsoring Access. Hemos confirmado que ninguna de estas IPs está operativa en este momento.

Conclusión

Ballistic Bobcat sigue operando con un modelo de exploración y explotación, buscando objetivos de oportunidad con vulnerabilidades sin parchear en servidores Microsoft Exchange expuestos a Internet. El grupo sigue utilizando un variado conjunto de herramientas de código abierto complementado con varias aplicaciones personalizadas, incluido su backdoor Sponsor. Una buena práctica para proteger a las organzacioens sería parchear todos los dispositivos expuestos a Internet y permanecer atentos a las nuevas aplicaciones que aparezcan.

Para cualquier consulta sobre nuestra investigación publicada en WeLiveSecurity, póngase en contacto con nosotros 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

Rutas de archivos

A continuación se muestra una lista de las rutas en las que se desplegó el backdoor Sponsor en las máquinas víctimas.

%SYSTEMDRIVE%\inetpub\wwwroot\aspnet_client\

%USERPROFILE%\AppData\Local\Temp\file

%USERPROFILE%\AppData\Local\Temp\2\low\

%USERPROFILE%\Desktop\

%USERPROFILE%\Downloads\a\a

%WINDIR%\

%WINDIR%INF\MSExchange Delivery DSN\a

%WINDIR%\Tasks

%WINDIR%\Temp\%WINDIR%\Temp\crashpad\1\Files

Red

IP	Provider	First seen	Last seen	Details
162.55.137[.]20	Hetzner Online GMBH	2021-06-14	2021-06-15	PowerLess C&C.
37.120.222[.]168	M247 LTD	2021-11-28	2021-12-12	Sponsor C&C.
198.144.189[.]74	Colocrossing	2021-11-29	2021-11-29	Support tools download site.
5.255.97[.]172	The Infrastructure Group B.V.	2021-09-05	2021-10-28	Support tools download site.

Técnicas ATT&CK deMITRE

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