Ataques recientes de FamousSparrow: nuevas versiones de SparrowDoor y uso de ShadowPad

En julio de 2024, ESET Research detectó actividad sospechosa en el sistema de un grupo comercial de Estados Unidos que opera en el sector financiero. Mientras ayudábamos a la entidad afectada a remediar el compromiso, hicimos un descubrimiento inesperado en la red de la víctima: herramientas maliciosas pertenecientes a FamousSparrow, un grupo APT alineado con China.

No se había documentado públicamente ninguna actividad de FamousSparrow desde 2022, por lo que se creía que el grupo estaba inactivo. FamousSparrow no sólo seguía activo durante este período, sino que también debía estar trabajando duro para desarrollar su conjunto de herramientas, ya que la red comprometida reveló no una, sino dos versiones previamente no documentadas de SparrowDoor, el backdoor insignia de FamousSparrow.

Ambas versiones de SparrowDoor suponen un notable avance con respecto a las anteriores, especialmente en términos de calidad del código y arquitectura. Una de ellas se parece al backdoor que los investigadores de Trend Micro denominaron CrowDoor y que atribuyeron al grupo Earth Estries APT en noviembre de 2024. El otro es modular y significativamente diferente de todas las versiones anteriores. Esta campaña es también la primera vez documentada que FamousSparrow utiliza ShadowPad, un backdoor de venta privada, conocido por ser suministrado únicamente a actores de amenazas alineados con China.

Además, descubrimos que, como parte de esta campaña, el autor de la amenaza logró acceder a un instituto de investigación en México sólo un par de días antes del ataque en Estados Unidos.

Al establecer un seguimiento basado en lo que descubrimos en estos ataques, hallamos una actividad adicional del grupo entre 2022 y 2024, que todavía estamos investigando. Entre otros objetivos, se encontraba una institución gubernamental de Honduras.

Este blogpost ofrece una visión general del conjunto de herramientas utilizadas en la campaña de julio de 2024, centrándose en las versiones no documentadas del backdoor SparrowDoor que descubrimos en la víctima estadounidense.

Puntos clave de este blogpost:

• Los investigadores de ESET descubrieron que FamousSparrow comprometió a un grupo comercial del sector financiero en Estados Unidos y a un instituto de investigación en México.
• FamousSparrow desplegó dos versiones previamente no documentadas del backdoor SparrowDoor, una de ellas modular.
• Ambas versiones constituyen un progreso considerable respecto a las anteriores e implementan la paralelización de comandos.
• También se observó al grupo APT utilizando por primera vez el backdoor ShadowPad.
• Discutimos las afirmaciones de atribución de Microsoft Threat Intelligence que vinculan a FamousSparrow con Salt Typhoon.

FamousSparrow es un grupo de ciberespionaje con vínculos con China, activo desde al menos 2019. Primero documentamos públicamente al grupo en un blogpost de 2021 cuando observamos que explotaba la vulnerabilidad ProxyLogon. El grupo era conocido inicialmente por atacar hoteles de todo el mundo, pero también ha atacado a gobiernos, organizaciones internacionales, empresas de ingeniería y bufetes de abogados. FamousSparrow es el único usuario conocido del backdoor SparrowDoor.

Aunque FamousSparrow parecía inactivo en el momento de nuestro descubrimiento, atribuimos esta actividad al grupo con un alto grado de confianza. Los payloads desplegados son nuevas versiones de SparrowDoor, un backdoor que parece ser exclusivo de este grupo. Aunque estas nuevas versiones muestran mejoras significativas en la calidad del código y la arquitectura, todavía se pueden rastrear directamente a versiones anteriores, documentadas públicamente.

Los loaders utilizados en estos ataques también presentan solapamientos sustanciales de código con muestras atribuidas anteriormente a FamousSparrow. En particular, utilizan el mismo reflective loader shellcode que la muestra de loader libhost.dll descrita en un informe de febrero de 2022 publicado por el Centro Nacional de Ciberseguridad del Reino Unido (NCSC). Su configuración también comparte el mismo formato específico, a excepción de la clave de cifrado que, en su lugar, está hardcodeada en el loader y el backdoor. El cifrado XOR también se ha sustituido por RC4.

Además, las comunicaciones con el servidor de C&C utilizan un formato muy similar al empleado en versiones anteriores de SparrowDoor.

En 2021, los investigadores de Kaspersky escribieron sobre un actor de amenazas al que rastrean como GhostEmperor. A pesar de algunas coincidencias de infraestructura con FamousSparrow, los rastreamos como grupos separados. En agosto de 2023, Trend Micro observó que algunas TTP de FamousSparrow se solapan con las de Earth Estries. También hemos observado solapamientos de código entre SparrowDoor y HemiGate de ese grupo. Estos se discuten con más detalle en la sección de Plugins. Creemos que los dos grupos se solapan al menos parcialmente, pero no disponemos de datos suficientes para evaluar plenamente la naturaleza y el alcance del vínculo entre ambos grupos.

FamousSparrow y Salt Typhoon

Antes de sumergirnos en el análisis del conjunto de herramientas de FamousSparrow, queremos discutir nuestra posición sobre los vínculos entre FamousSparrow y Salt Typhoon realizados por Microsoft Threat Intelligence.

En septiembre de 2024, el Wall Street Journal publicó un artículo (con paywall) informando de que los proveedores de servicios de Internet en los Estados Unidos habían sido comprometidos por un actor de amenazas llamado Salt Typhoon. El artículo se hace eco de las afirmaciones de Microsoft de que este actor de amenazas es el mismo que FamousSparrow y GhostEmperor. Es el primer informe público que confunde a estos dos últimos grupos. Sin embargo, como ya hemos dicho, consideramos que GhostEmperor y FamousSparrow son dos grupos distintos. Hay pocas coincidencias entre ambos, pero muchas discrepancias. Ambos utilizaron 27.102.113[.]240 como servidor de descargas en 2021. Ambos grupos fueron también los primeros en aprovechar la vulnerabilidad ProxyLogon(CVE-2021-26855) y han utilizado algunas de las mismas herramientas disponibles públicamente. Sin embargo, además de estas herramientas disponibles públicamente, cada actor de la amenaza tiene su propio conjunto de herramientas personalizadas.

Desde esa publicación inicial, los investigadores de Trend Micro han añadido Earth Estries a la lista de grupos vinculados a Salt Typhoon. En el momento de escribir este artículo, Microsoft, que creó el clúster Salt Typhoon, no ha publicado ningún indicador técnico ni detalles sobre las TTP utilizadas por el actor de la amenaza, ni ha proporcionado una explicación para esta atribución. Para evitar enturbiar aún más las aguas, seguiremos rastreando el clúster de actividad que vemos directamente vinculado a SparrowDoor como FamousSparrow hasta que dispongamos de la información necesaria para evaluar de forma fiable estas afirmaciones de atribución.

Basándonos en nuestros datos y en el análisis de los informes públicos disponibles, FamousSparrow parece ser un grupo independiente con vínculos poco claros con los otros grupos mencionados en esta sección. Creemos que esos vínculos se explican mejor postulando la existencia de un tercero compartido, como un intendente digital, que fusionando todos estos grupos dispares de actividad en uno solo.

Análisis técnico

Para obtener acceso inicial a la red afectada, FamousSparrow desplegó un webshell en un servidor IIS. Aunque no pudimos determinar el exploit exacto utilizado para desplegar las webshells, ambas víctimas ejecutaban versiones obsoletas de Windows Server y Microsoft Exchange, para las que existen varios exploits disponibles públicamente.

En cuanto al conjunto de herramientas utilizadas en la campaña, el autor de la amenaza empleó una mezcla de herramientas y malware personalizados junto con los compartidos por grupos APT alineados con China, así como de fuentes disponibles públicamente. Los payloads finales fueron SparrowDoor y ShadowPad. La imagen 1 ofrece una visión general de la cadena de compromiso desplegada en los ataques.

El actor de la amenaza descargó inicialmente un script por lotes a través de HTTP desde un servidor de descargas, 43.254.216[.]195. Este script contiene un webshell .NET codificado en base64 que escribe en C:\users\public\s.txt. Luego lo decodifica utilizando certutil.exe y guarda la salida decodificada en C:\users\public\s.ashx. Un módulo ASHX es un tipo de manejador HTTP para ASP.NET. Aunque son similares a los módulos ASPX, los módulos ASHX no incluyen ningún componente de interfaz de usuario. A continuación, el script recorre las unidades C: a I:, y P:, para encontrar el directorio de instalación de DotNetNuke; luego copia el webshell ASHX a <Directory_DotNetNuke>\DesktopModules\DotNetNuke.ashx.

El webshell en sí es bastante genérico y no utiliza nada específico para DotNetNuke. Todos los datos que recibe y devuelve están encriptados en AES con la clave e2c99096bcecd1b5. En la primera petición, espera un archivo .NET PE. Este archivo ejecutable se carga en memoria y se guarda en una variable de sesión. En las siguientes peticiones, se crea una instancia de la clase LY contenida en ese ensamblado .NET y los datos recibidos se pasan a su método Equals. No recogimos ningun payload enviada a esta webshell, pero es obvio que el método Equals no sigue el contrato típico.

En los casos que observamos, esto se utilizaba para generar una sesión PowerShell remota interactiva. Una vez establecida esta sesión, los atacantes utilizaban herramientas legítimas de Windows para obtener información sobre el host y los dominios de Active Directory a los que estaba unido. A continuación, descargaron PowerHub, un marco de explotación posterior de código abierto, de un servidor controlado por el atacante y utilizaron la técnica de escalada de privilegios BadPotato para obtener privilegios de SYSTEM. Este exploit no está presente en el framework, pero parece que el grupo añadió el módulo de código abierto Invoke-BadPotato a su despliegue de PowerHub. Por último, el atacante utilizó el módulo Invoke-WebRequest integrado en PowerShell para descargar tres archivos del mismo servidor que componen el loader trident de SparrowDoor.

En un proceso muy similar al descrito en 2022 por el NCSC del Reino Unido, los archivos mencionados utilizan un esquema de carga tridente para ejecutar SparrowDoor. En este caso, el ejecutable utilizado para la carga lateral de DLL es una versión legítima de K7AntiVirus Messenger Scanner denominada K7AVMScn.exe, mientras que los archivos maliciosos DLL y de payload cifrado se denominan K7AVWScn.dll y K7AVWScn.doc, respectivamente. El archivo de payload se cifra utilizando una clave RC4 que está codificada tanto en el loader como en el payload descifrado resultante, pero que varía según las muestras.

El payload descifrada consiste en una configuración personalizada y un shellcode de loader reflexivo casi idéntico al descrito por el NCSC del Reino Unido, con la única diferencia de que el primer campo, que contenía la clave XOR de cuatro bytes, ha sido eliminado. Los últimos 202 bytes del archivo se cifran por separado, pero utilizando la misma clave RC4, y contienen la configuración del servidor de C&C.

SparrowDoor

Como se ha dicho, hemos observado dos nuevas versiones de SparrowDoor utilizadas en estos ataques. La primera es muy similar a lo que los investigadores de Trend Micro denominaron CrowDoor, en un artículo publicado en noviembre de 2024 sobre Earth Estries. Este malware fue documentado por primera vez por investigadores de ITOCHU y Macnica en una presentación en VirusBulletin en 2023. Desde nuestro punto de vista, se trata de una parte del esfuerzo continuado de desarrollo de SparrowDoor y no de una familia diferente. Podemos seguir la evolución desde la primera versión que describimos en 2021, pasando por las denominadas CrowDoor, hasta la versión modular que analizamos en la última parte de este blogpost.

Ambas versiones de SparrowDoor utilizadas en esta campaña constituyen avances onsiderables en la calidad del código y la arquitectura en comparación con las anteriores. El cambio más significativo es la paralelización de comandos que consumen mucho tiempo, como la E/S de archivos y el shell interactivo. Esto permite al backdoor seguir gestionando nuevos comandos mientras se realizan esas tareas. Explicaremos el procedimiento más adelante en el blogpost, cuando hablemos de los comandos en detalle.

Al igual que en versiones anteriores, el comportamiento del backdoor varía dependiendo del argumento de línea de comandos que se le pase. Estos se enumeran en la Tabla 1.

Tabla 1. Argumentos de línea de comandos para SparrowDoor

Cuando se ejecuta sin argumentos, el malware establece la persistencia. Primero intenta hacerlo creando un servicio llamado K7Soft que está configurado para ejecutarse automáticamente al inicio. Si esto falla, utiliza en su lugar una clave Run del registro con el mismo nombre. En ambos casos, el mecanismo de persistencia se configura para ejecutar el backdoor con un argumento de línea de comandos de 11. También se lanza inmediatamente con ese mismo argumento utilizando la API StartServiceA o ShellExecuteA.

Cuando se ejecuta con el argumento 11, el backdoor lanza la herramienta de gestión de color de Windows (colorcpl.exe) con un argumento de línea de comandos de 22 e inyecta su loader en el proceso recién creado.

Sólo cuando el argumento de línea de comandos se establece en 22, el backdoor ejecuta realmente su payload principal.

Después de que SparrowDoor se ejecuta en este modo de backdoor, termina, de forma indirecta, cualquier otra instancia que ya se esté ejecutando. El backdoor utiliza la API K32EnumProcesses para recorrer los ID de proceso (PID) de todos los procesos en ejecución e intenta crear un mutex llamado Global\ID(<PID>). Los PIDs de 15 o menos se omiten, probablemente como una forma de evitar matar algunos procesos esenciales del sistema. Si el mutex ya existe, el proceso se termina. Si no, el mutex se cierra inmediatamente. Cuando SparrowDoor termina de recorrer los PIDs, crea un nuevo mutex usando el mismo formato de nombre y su propio PID.

A continuación, el backdoor lee los últimos 202 bytes del archivo de carga cifrado y los descifra utilizando la misma clave RC4 utilizada por el loader. El texto plano resultante es la configuración del servidor de C&C, que consta de tres pares de direcciones y puertos, seguidos de cuatro valores numéricos que, respectivamente, representan el número de días, horas, minutos y segundos que el backdoor debe esperar después de haber probado todos los servidores de C&C configurados. Esto está relacionado con la funcionalidad que describiremos más adelante al hablar del comando que utiliza el backdoor para cambiar la configuración de C&C.

Después de cargar esta configuración, el backdoor intentará conectarse al primer servidor. Si no puede conectarse o si el servidor de C&C emite un comando que hace que la ejecución salga del bucle de comandos principal, SparrowDoor intentará conectarse al siguiente servidor, y así sucesivamente. Una vez que el último servidor en la configuración ha sido probado, el backdoor dormirá por el tiempo definido (seis minutos en la muestra que analizamos), recargará la configuración, y luego repetirá el proceso. Tenga en cuenta que, durante este tiempo, SparrowDoor no responde a los comandos. Sin embargo, los comandos paralelizados que ya se estaban ejecutando seguirán haciéndolo hasta que se completen, encuentren un error o sean terminados por el servidor.

El backdoor utiliza dos clases para gestionar sus conexiones: la clase abstracta CBaseSocket y su clase hija CTcpSocket. Estas son esencialmente envoltorios alrededor de los sockets TCP Winsock. Mientras que los nombres de las clases son genéricos y siguen la misma convención de nomenclatura utilizada en Microsoft Foundation Class Library (MFC), el código que contienen parece ser personalizado.

SparrowDoor utiliza un valor entero como identificador de la víctima o de la sesión. Se envía al servidor C&C cuando solicita información sobre el host y cada vez que se crea un nuevo socket. El valor se lee de la clave de registro HKLM\Software\CLASSES\CLSID\ID, volviendo a la misma ruta en la colmena HKCU si hay algún problema. Si no está presente, el identificador se obtiene del contador de rendimiento de la máquina y se escribe en la clave de registro antes mencionada. Aunque el valor en sí es benigno, el uso de esta clave de registro no estándar presenta una oportunidad de detección. De hecho, el nombre de cualquier clave de registro bajo Software\Classes\CLSID\ debe ser un CLSID válido, que se representan como un GUID rodeado de llaves. Aunque no es necesariamente un indicador de malicia, la presencia de claves con nombres no estándar bajo CLSID es inusual.

Comandos

La primera versión de SparrowDoor utilizada en esta campaña soporta más comandos, descritos en ..., que las versiones previamente documentadas. Aunque los ID de los comandos son diferentes de los utilizados en la versión analizada por Trend Micro, el orden y el desplazamiento entre los ID son los mismos. No hemos tenido acceso a esa muestra, por lo que no podemos decir si los comandos adicionales estaban ausentes o simplemente no estaban documentados públicamente por los autores.

Como se ha mencionado anteriormente, algunos de los comandos se han paralelizado. Cuando el backdoor recibe uno de estos comandos, crea un hilo que inicia una nueva conexión con el servidor de C&C. El identificador único de la víctima se envía a través de la red. El identificador único de la víctima se envía a través de la nueva conexión junto con un identificador de comando que indica el comando que dio lugar a esta nueva conexión. Esto permite al servidor de C&C realizar un seguimiento de qué conexiones están relacionadas con la misma víctima y cuáles son sus propósitos. Cada uno de estos hilos puede entonces manejar un conjunto específico de subcomandos. Para limitar su complejidad, no incluye estos subcomandos; los revisaremos por separado.

Tabla 2. Principales comandos implementados por SparrowDoor

Toda la comunicación entre el malware y su servidor de C&C utiliza el mismo formato de paquete base, definido en la Figura 2. El formato de la sección de datos depende del comando enviado, y puede estar vacío. En la mayoría de los casos, las respuestas utilizan el ID del comando al que responde el backdoor. Sin embargo, hay algunas excepciones; las describiremos cuando hablemos en detalle de los comandos relevantes.

Shell interactivo

Al recibir el comando shell interactivo, SparrowDoor crea un nuevo hilo y socket como se describió anteriormente, y realiza todas las acciones siguientes dentro de este hilo utilizando el nuevo socket. En primer lugar, el backdoor envía un mensaje de confirmación con el ID de comando 0x32341125 y el ID de víctima único en el campo de datos. A continuación, genera un proceso cmd.exe y utiliza un par de hilos y pipes con nombre para retransmitir los comandos y su salida entre el servidor de C&C y el shell.  \\.\pipe\id2<address> se utiliza para pasar los comandos recibidos del servidor de C&C al shell y \\.\pipe\id1<address> se utiliza para la salida resultante en STDOUT y STDERR. En ambos casos, <address> es la dirección de memoria, en forma decimal, de la instancia CTcpSocket. Estos comandos utilizan el ID 0x32341126  y los datos son, respectivamente, la línea de comandos a ejecutar y la salida sin procesar. Si el backdoor recibe un mensaje con el ID del comando establecido en cualquier otro valor, la sesión de shell interactiva finaliza.

Cambiando la configuración del C&C

La configuración del C&C se guarda en el archivo payload encriptado. Si el backdoor recibe el comando para cambiar esta configuración (0x3234112A), la estructura recibida es encriptada RC4 y luego los últimos 202 bytes del archivo encriptado son sobreescritos con el resultado. Curiosamente, la configuración no se recarga automáticamente. Como explicamos anteriormente, la configuración sólo se recarga cuando se han probado los tres servidores configurados. Para forzar la recarga de la configuración, el servidor puede emitir el comando 0x32341127 o un comando inválido, ambos causarán que SparrowDoor salga del bucle de comandos y se mueva al siguiente servidor. La configuración también es recargada si el backdoor es relanzado, por ejemplo usando el comando 0x3234112B.

Operaciones con archivos

Como con otros comandos procesados en paralelo, aquí todo se realiza en un nuevo hilo usando un nuevo socket. SparrowDoor envía un mensaje de confirmación con el mismo ID que el comando original. El cuerpo de este mensaje contiene el ID único de la víctima y el ID de operación enviado por el servidor C&C. Este ID de operación no parece tener ningún significado, y probablemente sólo es utilizado por el servidor para vincular la conexión al comando de operación de archivo si se ejecutan varios comandos de este tipo en paralelo. Los ID de comando 0x3234112E y 0x3234112F se utilizan, respectivamente, para lecturas y escrituras de archivos.

Para una lectura de fichero, el cuerpo del mensaje contiene el desplazamiento inicial, el tamaño a leer y la ruta al fichero. Si la lectura solicitada sobrepasa el final del archivo, se produce un error y no se envía ninguna respuesta. En caso contrario, el malware lee el archivo en trozos de 4kB, cada uno de los cuales se envía en el cuerpo de un mensaje con el ID de comando  0x32341130.

El proceso es similar para la escritura de archivos. El mensaje inicial del C&C contiene el tamaño total de los datos que se van a escribir, seguido de la ruta del archivo de destino. Curiosamente, la escritura sólo se realiza si este tamaño es mayor que el tamaño actual del archivo de destino. Los datos son entonces enviados por el servidor C&C en trozos de 4kB, usando el mismo ID de comando de  0x32341130.

Listado de archivos

Cuando se recibe el comando de listado de archivos, el backdoor envía primero un mensaje de confirmación con el ID de comando  0x32341133. A continuación, utiliza las funciones de la API FindFirstFileW y FindNextFileW para recorrer, de forma no recursiva, los archivos del directorio de destino. Para cada archivo, SparrowDoor envía un mensaje, con el mismo ID de comando que el comando listar archivo (0x32341132) y la información descrita en la figura 3. Observe que, aunque la longitud del nombre del archivo no se especifica directamente, puede obtenerse restando el tamaño del resto de los campos (0x16) del valor data_lenght de la cabecera.

Una vez finalizada la iteración, se envía un mensaje con el ID de comando 0x32341134 y sin datos para indicar que la operación de listado de ficheros ha finalizado con éxito.

Proxy

Esta funcionalidad permite a el backdoor actuar como un proxy TCP entre el servidor de C&C y una máquina arbitraria. Al igual que con otros comandos procesados en paralelo, lo siguiente se realiza en un nuevo hilo utilizando su propio socket. SparrowDoor envía un mensaje de acuse de recibo con el mismo ID que el comando original; el cuerpo de este mensaje contiene el ID único de la víctima. El ID del comando 0x32341139 es entonces enviado por el servidor para iniciar realmente el proxy. La funcionalidad proxy se consigue creando dos nuevos sockets, uno conectado al servidor C&C y otro conectado a una dirección y puerto proporcionados por el servidor en esa nueva conexión. SparrowDoor utiliza entonces un par de estructuras Winsock y eventos para realizar un seguimiento de los paquetes entrantes y retransmitirlos entre las dos partes. La adición de la funcionalidad proxy a SparrowDoor puede ser un indicio de que el grupo está siguiendo la tendencia de los actores de amenazas alineados con China de construir y utilizar redes de cajas de retransmisión operativas (ORB).

SparrowDoor modular

La versión modular de SparrowDoor es significativamente diferente de las anteriores. En el lado de la comunicación de red, la cabecera del comando se envía separada del cuerpo y los datos se cifran RC4 con la clave codificada iotrh^%4CFGTj. Las clases personalizadas usadas para la comunicación de red en esta versión todavía usan sockets Winsock TCP y son muy similares a las que mencionamos anteriormente - la diferencia más notable es que la clase hija se llama engañosamente CShttps en lugar de CTcpSocket. Como se ve en la Tabla 3, este es uno de los comandos presentes en versiones anteriores de SparrowDoor, ésta sólo implementa los comandos relacionados con la gestión de la configuración del C&C y la desinstalación del backdoor. La información sobre la máquina anfitriona se envía automáticamente después del mensaje de conexión inicial e incluye una lista de productos de seguridad instalados, además de lo que se enviaba en versiones anteriores.

Todos los demás comandos están relacionados con el manejo de plugins. Creemos que la funcionalidad eliminada simplemente se ha trasladado a uno o más módulos. Aunque todavía no hemos observado ningún plugin de este tipo, podemos compartir ideas basadas en nuestro análisis del código que implementa esta funcionalidad.

Tabla 3. Comandos implementados en la versión modular de SparrowDoor

Plugins

Los plugins instalados se referencian a través de una lista estándar de C++; cada entrada consta de una máscara de bits y una dirección de función manejadora. La máscara de bits se utiliza para determinar qué ID de comando maneja el plugin y corresponde al nibble bajo del tercer byte del ID del comando (es decir, CommandID & 0xF0000).

Esta versión de SparrowDoor puede usar cinco IDs de comando diferentes para invocar comandos del plugin. De ellos, tres (0x3A76, 0x3A77, y 0x3A7B) siguen casi exactamente el mismo camino en el código - la única diferencia es el ID de respuesta del mensaje de reconocimiento. Hay algunas diferencias menores en el proceso de handshake entre este conjunto de comandos y los otros dos. Sin embargo, en todos los casos, el comando se paraleliza utilizando el mismo método que describimos en la sección Comandos. En el nuevo socket, el backdoor envía el ID de respuesta correspondiente, el ID de host único, y los datos que recibió inicialmente del servidor de C&C. Estos datos parecen funcionar como el ID de operación mencionado en la sección Operaciones de archivo. Una vez completado este apretón de manos, los cinco comandos llaman a la misma función para manejar realmente el comando plugin. Esta función recibe el ID del comando y los datos del servidor de C&C, luego itera a través de los plugins instalados para enviar el comando al controlador correcto. El proceso se repite hasta que el backdoor recibe un mensaje de comando con un formato incorrecto.

Por defecto, sólo se instala un plugin, con una máscara de bits de 0x10000. Este plugin maneja la instalación de nuevos plugins enviados por el servidor C&C. Los plugins son enviados por el servidor como archivos PE y nunca son almacenados en disco. Junto con el conjunto de funciones reducidas presentes en el backdoor base, esto probablemente está destinado a evadir la detección. Después de recibir un plugin de este tipo, se mapea manualmente en memoria y se llama a su exportación fmain. Esta función devuelve un puntero a una estructura que contiene la dirección de una función que devuelve la máscara de bits para el plugin y la dirección de la función manejadora. Si ningún plugin instalado tiene la misma máscara de bits, el plugin recién recibido se añade a la lista.

Enlaces a versiones anteriores

También hemos identificado muestras anteriores que presentan solapamientos significativos de código con esta versión modular, incluyendo código similar para manejar plugins. Estas muestras corresponden al backdoor que Trend Micro denominó HemiGate en un artículo de agosto de 2023. Algunas de las muestras incluso utilizan la misma clave RC4 mencionada en ese artículo. En lugar de ser enviados por el C&C, los plugins se implementan como clases C++ que heredan de una clase abstracta llamada PluginInterface. Estos plugins siguen el mismo patrón descrito en el párrafo anterior: tienen un método que devuelve una máscara de bits, utilizada para despachar comandos, y un segundo método para manejar comandos. Creemos que HemiGate representa un paso anterior en la evolución de el backdoor modular. Por lo tanto, es probable que los plugins que contiene sean representativos de los utilizados en la versión modular más reciente. ...presenta una visión general de los plugins y su funcionalidad.

Tabla 4. Resumen de los plugins contenidos en HemiGate

Estas similitudes son prueba de que el cluster que rastreamos como FamousSparrow se solapa, al menos parcialmente, con Earth Estries. Dado que HemiGate es anterior a las dos versiones de SparrowDoor detalladas anteriormente en este informe, también puede ser un indicio de que las versiones modular y paralelizada de SparrowDoor se están desarrollando en paralelo.

ShadowPad

Una vez detectado SparrowDoor en la red de la víctima estadounidense, se utilizó para ejecutar un loader basado en MFC con similitudes a los loaders ShadowPad previamente documentados por Cisco Talos.

Este loader ShadowPad es una DLL llamada imjpp14.dll, destinada a ser cargada a través de DLL side-loading por la versión legítima y obsoleta de más de 14 años del ejecutable Microsoft Office IME, imecmnt.exe, renombrado a imjp14k.exe. El loader comprueba en primer lugar si el proceso actual es el host de carga lateral esperado, realizando una coincidencia de patrones en el offset 0.xE367 en memoria. Una vez que esta validación tiene éxito, la DLL maliciosa descifra el archivo llamado imjpp14.dll.dat que se encuentra en el mismo directorio que la DLL y su host de carga lateral. Finalmente, el payload descifrado se inyecta en un proceso wmplayer.exe (Windows Media Player).

Aunque no recuperamos el payload cifrado, se produjo una detección ShadowPad en memoria en un procesowmplayer.exe, con imjpp14k.exe como proceso padre. Además, se conectaba a un servidor de C&C de ShadowPad (IP: 216.238.106[.]150). Aunque no observamos ninguna muestra de ShadowPad utilizándolo, uno de los servidores de C&C de SparrowDoor tenía un certificado TLS que coincidía con una huella digital conocida de ShadowPad.

Además, detectamos loaders de ShadowPad y el backdoor de ShadowPad en la memoria de varias máquinas de la red de la víctima.

Es la primera vez que observamos que FamousSparrow utiliza el backdoor ShadowPad.

Otras herramientas

Durante el ataque, además de los programas maliciosos mencionados anteriormente, también observamos lo siguiente:

• Un script por lotes básico que vuelca el registro con los siguientes comandos:

• • reg save HKLM\SYSTEM C:\users\public\sys.hiv,
  • reg save HKLM\SAM C:\users\public\sam.hiv, and
  • reg save hklm\security C:\users\public\security.hiv.

• impacket o NetExec, detectados por nuestro cortafuegos, pero no hemos recogido ninguno de los comandos.
• Un loader para una versión del RAT de código abierto Spark que fue modificado para incluir código de un loader de código shell Go de código abierto.

También observamos el uso de una herramienta para volcar la memoria de LSASS con la función no documentada de la API MiniDumpW. Esta herramienta está dividida en dos DLL almacenadas en el disco como %HOME%\dph.dll and %WINDIR%\SysWOW64\msvc.dll. Esta última probablemente está pensada para mezclarse con las bibliotecas legítimas para Microsoft Visual C++ (MSVC) que están almacenadas en el mismo directorio. La primera se carga a través de una versión legítima del generador de caché de VLC (vlc-gen-cache.exe), renombrada a dph.exe, e importa funciones de la segunda. Dado que los plugins de VLC pueden ser DLL nativas, su generador de caché contiene naturalmente código para cargar y ejecutar dichas bibliotecas.

Infraestructura de red

El servidor de C&C de ShadowPad utiliza un certificado TLS autofirmado, con una huella SHA-1 de BAED2895C80EB6E827A6D47C3DD7B8EFB61ED70B, que intenta falsificar los utilizados por Dell. Sigue el formato descrito por Hunt Intelligence en un artículo de febrero de 2024. Aunque este patrón puede utilizarse para rastrear servidores ShadowPad, no está vinculado a ningún actor de amenazas específico. Uno de los servidores de C&C utilizados por SparrowDoor (45.131.179[.]24:80)  tenía un certificado TLS, en el puerto 443, con el mismo Nombre Común (CN) que el certificado utilizado por el servidor de C&C de ShadowPad antes mencionado. Este servidor es también el único que estaba presente en ambas versiones de SparrowDoor.

Observamos tres servidores únicos de C&C de SparrowDoor en esta campaña, todos los cuales utilizaban el puerto 80. La muestra modular estaba configurada con amelicen[.]com como su tercer servidor de C&C. Cuando la muestra fue detectada por primera vez, este dominio apuntaba a la dirección IP mencionada en el párrafo anterior. Uno de los servidores de C&C configurados en la muestra modular (43.254.216[.]195:80) también fue utilizado por el loader SparrowDoor. Esto es extraño, ya que SparrowDoor utiliza TCP plano y los archivos se descargaron a través de HTTP. Sin embargo, hay un intervalo de casi dos semanas entre las descargas, el 30 de junio de 2024, y la compilación del SparrowDoor modular, el 12 de julio de 2024. No sabemos si el servicio que escucha en ese puerto se cambió entre esos dos sucesos o si el servidor de C&C de SparrowDoor incluye funcionalidad para servir archivos a través de HTTP.

Conclusión

Debido a la falta de actividad y de informes públicos entre 2022 y 2024, se presumía que FamousSparrow estaba inactivo. Sin embargo, nuestro análisis de la red estadounidense comprometida en julio de 2024 reveló dos nuevas versiones de SparrowDoor, lo que demuestra que FamousSparrow sigue desarrollando su backdoor insignia. Una de estas nuevas versiones también se encontró en una máquina en México. Mientras establecíamos el rastreo basado en lo cubierto en este blogpost, descubrimos actividad adicional del grupo durante este periodo, incluyendo el ataque a una institución gubernamental en Honduras. Esta nueva actividad indica que no sólo el grupo sigue operando, sino que también estaba desarrollando activamente nuevas versiones de SparrowDoor durante este tiempo.

Seguiremos vigilando e informando sobre la actividad de FamousSparrow, y también continuaremos siguiendo el debate en torno a los posibles vínculos entre FamousSparrow y Salt Typhoon.

IoCs

Archivos

Red

Técnicas ATT&CK de MITRE

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