FamousSparrow centra sus operaciones en América Latina y despliega el nuevo backdoor SparroWocky

El monitoreo continuo de FamousSparrow por parte de ESET Research ha vuelto a dar frutos. Nuestro informe público anterior sobre FamousSparrow reveló que este grupo APT vinculado a China había desarrollado dos nuevas versiones de su backdoor personalizado llamado SparrowDoor. Esta vez descubrimos que FamousSparrow ha cambiado a un nuevo backdoor, SparroWocky, y lo ha estado desplegando en varios países de América Latina al menos desde agosto de 2025.

En lo que parece ser una reacción de China al creciente interés de Estados Unidos en América Latina, FamousSparrow incrementó su actividad en la región hasta concentrar sus operaciones casi exclusivamente en ella en julio de 2025. Un mes después, observamos que el grupo había comenzado a utilizar el nuevo backdoor SparroWocky, que rápidamente reemplazó a SparrowDoor como el principal implante de FamousSparrow.

SparroWocky es un backdoor modular desarrollado en C++. Su arquitectura y las técnicas utilizadas por sus autores indican un sólido conocimiento de las técnicas de evasión de análisis y de los mecanismos internos de Windows. Elegimos el nombre SparroWocky porque las primeras muestras que recopilamos contienen la primera estrofa de Jabberwocky, un poema sin sentido de Lewis Carroll. Afortunadamente, aunque es avanzada, la forma en que funciona SparroWocky es mucho menos enigmática de lo que su nombre podría sugerir, por lo que un análisis exhaustivo de su vorpal blade nos permitió elaborar un análisis detallado de este backdoor.

Puntos clave del artículo:

• FamousSparrow está intensificando sus ataques a organizaciones gubernamentales en América Latina.
• Desde agosto de 2025, el grupo parece estar reemplazando SparrowDoor por SparroWocky, un nuevo backdoor personalizado desarrollado en C++.
• Con la adopción de SparroWocky, FamousSparrow comenzó a incorporar código de proyectos de código abierto directamente en su malware.
• SparroWocky es un backdoor con amplias capacidades que manipula estructuras de bajo nivel en memoria y modifica código en tiempo de ejecución para evadir la detección.
• SparroWocky tiene la capacidad de cargar y ejecutar Beacon Object Files (BOF), un tipo especial de archivo ejecutable compatible con numerosas herramientas de red teaming y pruebas de penetración.

FamousSparrow es un grupo de ciberespionaje vinculado a China que se cree que ha estado activo al menos desde 2019. Documentamos públicamente al grupo por primera vez en una publicación de septiembre de 2021, cuando observamos que explotaba la vulnerabilidad ProxyLogon. Inicialmente era conocido por atacar hoteles en distintas partes del mundo, aunque también ha dirigido sus operaciones contra gobiernos, organizaciones internacionales, asociaciones comerciales, empresas de ingeniería y estudios jurídicos. FamousSparrow es el único usuario conocido del backdoor SparrowDoor.

Analizamos dos versiones de SparrowDoor en una publicación de 2025, en la que también abordamos las atribuciones relacionadas con el grupo. Como señaló Trend Micro, FamousSparrow está vinculado a Earth Estries; sin embargo, la naturaleza exacta de esa relación aún no se conoce por completo. El grupo también ha sido vinculado públicamente con Salt Typhoon, pero, debido a la falta de indicadores técnicos que confirmen esa relación, seguimos rastreándolos como actores independientes.

Según nuestra investigación, atribuimos con un alto grado de confianza la campaña más reciente y el backdoor SparroWocky a FamousSparrow. Esto se debe a que, en algunos de los primeros ataques en los que se empleó este backdoor, SparroWocky fue desplegado a través de SparrowDoor, una herramienta exclusiva de FamousSparrow. Además, no solo el perfil de las víctimas coincide con los objetivos históricos del grupo, sino que también hemos registrado intentos de desplegar SparroWocky en muchas de las mismas organizaciones que anteriormente habían sido atacadas con SparrowDoor.

América Latina en la mira

Como mencionamos anteriormente, FamousSparrow parece estar enfocado actualmente en objetivos de alto perfil en América Latina. Esta tendencia comenzó, como mínimo, en julio de 2025 y se ha mantenido con la llegada de SparroWocky. De hecho, entre mediados de 2025 y 2026, el 90 % de los objetivos del grupo registrados en nuestra telemetría se ubicaron en la región. Como muestra la Figura 1, hemos observado el despliegue del nuevo backdoor contra entidades gubernamentales de Argentina, Ecuador, Guatemala, Honduras, Panamá, Perú, Puerto Rico y Venezuela. Se trata de un caso poco habitual entre los grupos APT vinculados a China que monitoreamos actualmente, ya que normalmente sus operaciones se distribuyen entre distintas regiones del mundo durante períodos prolongados.

Creemos que este enfoque no es casual y probablemente refleje la respuesta de China a diversas iniciativas recientes de Estados Unidos en la región. De hecho, el segundo mandato presidencial de Donald Trump ha supuesto una reafirmación agresiva de los intereses estadounidenses en América Latina, algo que pone en riesgo varias inversiones estratégicas que China ha desarrollado en el continente durante la última década en sectores como la energía, la minería y las telecomunicaciones. Sospechamos que las actividades de FamousSparrow buscan ayudar a China a monitorear mejor y anticipar las reacciones de los gobiernos locales frente a las presiones actuales de Estados Unidos.

En algunos casos hemos observado indicios que parecen respaldar claramente esta hipótesis. Por ejemplo, una de las entidades panameñas que vimos entre los objetivos está directamente involucrada en la disputa comercial en torno a dos importantes puertos ubicados en el área del canal, que hasta hace poco eran operados por una empresa con sede en China. Dado que la concesión otorgada a esa compañía fue cuestionada legalmente por el gobierno panameño a comienzos de 2025, parece muy probable que la operación de FamousSparrow buscara obtener información anticipada y privilegiada sobre las intenciones de las autoridades locales respecto de este asunto.

Aún no está claro si el aparente foco del grupo en América Latina responde a un mandato geográfico formal o si se trata de una prioridad temporal impulsada por las circunstancias geopolíticas actuales.

Análisis de SparroWocky

SparroWocky es un backdoor modular desarrollado en C++ y diseñado con un fuerte énfasis en la modularidad y el sigilo. Apareció poco después de que FamousSparrow comenzara a enfocarse en América Latina y rápidamente se convirtió en el principal implante del grupo, reemplazando a SparrowDoor. Cabe destacar que SparroWocky no es una variante de SparrowDoor, sino una familia de malware completamente distinta. La transición hacia este nuevo backdoor también vino acompañada de una mayor integración de herramientas de código abierto en el flujo de trabajo de FamousSparrow. Mientras que anteriormente estas herramientas se desplegaban como componentes independientes junto a SparrowDoor, con SparroWocky algunas de ellas fueron incorporadas directamente al malware.

Entre las capacidades más destacadas de SparroWocky se encuentran la ejecución de archivos arbitrarios, la posibilidad de actuar como proxy TCP y la ejecución de comandos. El backdoor también recopila información general sobre el equipo comprometido, como el nombre del equipo, el nombre de usuario, el dominio, la versión de Windows y las direcciones IP de sus interfaces de red.

Además, SparroWocky puede exfiltrar archivos y capturar pantallas de forma periódica. La información exfiltrada se cifra mediante RC4 y se transmite a través del protocolo TLS. Dependiendo de su configuración, SparroWocky puede establecer persistencia mediante la creación de un servicio dedicado o a través de una entrada en una clave Run del Registro de Windows.

Loader

SparroWocky se despliega mediante el esquema habitual de loader tridente, que consta de un ejecutable legítimo, una DLL maliciosa que suplanta a una DLL requerida por ese ejecutable y un archivo que contiene un payload cifrado (ver Figura 2). El loader reside en la DLL mencionada y se ejecuta mediante DLL side-loading. Hemos observado que FamousSparrow utiliza una amplia variedad de objetivos para realizar side-loading; en la mayoría de los casos, se trata de una versión modificada de la DLL legítima que el ejecutable debería cargar normalmente. Aunque la mayor parte del archivo permanece intacta, una porción arbitraria de la sección .text es reemplazada por código malicioso y el encabezado del punto de entrada (entry point) se modifica para apuntar a esa región alterada.

Esta técnica ofrece ciertas capacidades de evasión de defensas. Al conservar los mismos metadatos y la misma lista de funciones exportadas que la DLL legítima, la DLL maliciosa puede pasar más desapercibida. Además, dado que el código insertado en la región modificada no se corresponde con las funciones exportadas ni con las llamadas presentes en la parte no alterada del archivo, las herramientas automatizadas de análisis pueden tener dificultades para identificar correctamente los límites entre funciones.

La función principal del loader es extraer y descifrar su payload desde un archivo. Estos archivos, que normalmente tienen el mismo nombre que el ejecutable, pero con la extensión .dat, presentan una estructura específica que se detalla en la Figura 3.

El archivo contiene un encabezado personalizado que comienza con un valor mágico de cuatro bytes (0x11328712), seguido por el tamaño de los datos de configuración, el tamaño del payload y una clave RC4 de 16 bytes. Esta clave RC4 se utiliza para descifrar el resto del archivo, que contiene tanto la configuración de SparroWocky (descrita en la sección Configuración) como el propio backdoor. Ponemos a disposición un script para descifrar archivos de payload de SparroWocky en nuestro repositorio de GitHub.

El payload del backdoor en texto plano tiene el formato de un archivo ejecutable portátil (PE) al que se le han eliminado los valores mágicos MZ y PE. Este payload ejecutable se carga de forma reflectiva directamente en memoria sin escribirse en disco. Por lo tanto, creemos que la eliminación de estos valores mágicos posiblemente sea un intento de evadir los mecanismos de defensa en memoria que utilizan reconocimiento simple de patrones para identificar o extraer secciones sospechosas de memoria.

SparroWocky

Nuestro análisis de SparroWocky se basa principalmente en una muestra compilada el 17 de noviembre de 2025, según la marca de tiempo de su PE (SHA-1: 44F0A22B143B79FA760BF31E14C8FFF714C8A2A1). La versión de este backdoor parece ser la 1.8, de acuerdo con la información recopilada por su comando de fingerprinting, explicado en la Tabla 3.

Como ya mencionamos, elegimos el nombre SparroWocky porque encontramos la primera estrofa de Jabberwocky de Lewis Carroll en varias de las muestras que recopilamos. Creemos que esta estrofa proviene de los vectores de prueba de la RFC 7539, que define el algoritmo de cifrado ChaCha20-Poly1305. Las muestras de SparroWocky también contienen otras cadenas utilizadas como vectores de prueba en dicha RFC. Sin embargo, SparroWocky no utiliza ChaCha20-Poly1305. Aunque desconocemos la versión exacta de Mbed TLS utilizada en el backdoor, esos vectores de prueba estaban presentes en esa biblioteca antes de la versión 4.0.0.

Cabe destacar que SparroWocky depende al menos de los siguientes proyectos públicos:

• Mbed TLS, una biblioteca en C que utiliza para establecer un canal de comunicación seguro con su servidor C&C.
• MinHook, una biblioteca de hooking de la API de Windows que utiliza para ocultar de los productos de seguridad la dirección de inicio de los threads recién creados.
• COFF Loader (o un proyecto similar), que utiliza para habilitar la carga y ejecución dinámica de plugins en memoria en forma de objetos COFF.

Además, nuestro análisis reveló que los desarrolladores implementaron diversas técnicas para evadir las herramientas de monitoreo. Entre ellas se encuentra una variante de una técnica denominada SilentMoonwalk (o StackMoonwalk), que permite a SparroWocky falsificar los call stacks originados en las rutinas de MinHook. El backdoor también utiliza un algoritmo personalizado de API hashing para resolver dinámicamente las funciones de la API de Windows. Estas técnicas se explican con mayor detalle en la sección Técnicas antianálisis.

Configuración

El loader de SparroWocky extrae y descifra su configuración desde el archivo de payload .dat ubicado en el mismo directorio, tal como se explica en la sección Loader. La clave RC4 almacenada en el encabezado del payload se utiliza para descifrar la configuración, que se presenta en forma de una cadena de texto con campos separados por tabulaciones. Posteriormente, esta información es procesada y almacenada en una estructura interna. Los distintos campos de configuración y sus valores se describen en la Tabla 1, siguiendo el orden en que aparecen dentro de la configuración.

Tabla 1. Configuración de SparroWocky

Capacidades

Comportamiento controlado por argumentos

Tras procesar su configuración, el backdoor analiza la línea de comandos del proceso en el que se está ejecutando y adopta distintos comportamientos según la cantidad y el valor de los argumentos recibidos. Si no se proporcionan argumentos, SparroWocky simplemente establece persistencia y ejecuta la lógica principal del backdoor. En cambio, si recibe argumentos, el valor del primero determina qué acción debe realizar el malware, según se describe en la Tabla 2.

Tabla 2. Argumentos de la línea de comandos de SparroWocky y su significado

* Se explica en la sección «Comandos de Backdoor».

Cuando SparroWocky se ejecuta con la opción c, lee desde la entrada estándar (stdin) una lista adicional de parámetros separados por comas:

• a cadena de comando,
• un tiempo de espera (timeout) en segundos, y
• opcionalmente, el contenido de un archivo PE.

Si este último parámetro no está presente, el backdoor lee desde C:\Windows\System32\ el ejecutable especificado en la cadena de comando y carga el archivo MUI (Multilingual User Interface) asociado desde C:\Windows\System32\en-US\. Este proceso se describe en la sección Camuflaje del proceso host para PE cargados dinámicamente. De lo contrario, el archivo PE es ejecutado por el reflective loader de SparroWocky y la cadena de comando se pasa como línea de comandos. Es probable que esta funcionalidad esté diseñada para permitir que el backdoor ejecute fácilmente utilidades del sistema.

SparroWocky carga en memoria el ejecutable especificado y lo ejecuta con el comando proporcionado. Al mismo tiempo, el backdoor crea un nuevo thread que llama a ExitProcess para finalizar el proceso cuando expira el tiempo de espera definido. El proceso de carga implica la instalación de hooks y la falsificación de estructuras en memoria para camuflar el proceso host antes de ejecutar el ejecutable objetivo. Estas técnicas de evasión de análisis se explican con mayor detalle en la sección dedicada a Camuflaje del proceso host para PE cargados dinámicamente.

Además, cuando el malware se ejecuta sin argumentos o con la opción p, se inicia un mecanismo de sincronización de instancias. Esta función evita que múltiples instancias del backdoor se ejecuten simultáneamente mediante un mecanismo personalizado de comunicación entre procesos (IPC, Inter-Process Communication).

Cuando se inicia una nueva instancia, la instancia que ya está en ejecución se detiene y, si la nueva instancia se ejecuta desde una ubicación diferente, se eliminan los archivos y las configuraciones de persistencia establecidas por la instancia anterior.

Esto se logra mediante el uso de tres tipos de objetos globales: un mutex, un evento (event) y un bloque de memoria compartida (shared memory block), denominados respectivamente MyMutexName, MyEventName, y MySharedMemName.

Comandos del backdoor

El backdoor primero establece comunicación con su servidor de Comando y Control (C&C) y luego ejecuta su lógica principal dentro de un bucle infinito, en el que procesa los comandos recibidos. Estos comandos son gestionados por una clase personalizada denominada WinHandler (derivada de otra clase personalizada llamada ServerHandler), según la información de tipos en tiempo de ejecución (RTTI, Runtime Type Information) presente en el malware. Los manejadores de un conjunto mínimo de comandos están codificados directamente (hardcoded) en el propio bucle de procesamiento de comandos. Por su parte, ServerHandler cuenta con un método virtual específico para gestionar comandos adicionales. Este método está implementado en WinHandler. Si bien no hemos observado otras implementaciones de este método, esta arquitectura facilitaría a los desarrolladores modificar el conjunto de comandos que el backdoor puede manejar. La lista de comandos compatibles se muestra en la Tabla 3.

Tabla 3. Comandos de SparroWocky

* Comando hardcodeado

El comando 0x14 utiliza una versión ligeramente modificada de RunCOFF, perteneciente al proyecto de código abierto COFF Loader, para cargar y ejecutar un Beacon Object File (BOF). Un BOF es un ejecutable en formato Common Object File Format (COFF) independiente de la posición en memoria, diseñado para ejecutarse directamente dentro de la memoria de un implante. Los BOF fueron introducidos originalmente en Cobalt Strike y posteriormente adoptados por otros frameworks populares de red teaming, como Brute Ratel, Metasploit y Sliver. La modificación realizada sobre RunCOFF se encuentra en el proceso de resolución de símbolos importados. SparroWocky redirige las llamadas a bibliotecas externas realizadas por el BOF hacia una subrutina de stack spoofing. De esta manera, las llamadas realizadas por el objeto BOF quedan ocultas y son canalizadas a través de dicha rutina. Una vez cargado el objeto, el loader de BOF localiza y ejecuta function_name, pasándole como parámetros los valores incluidos en function_arguments. La capacidad de cargar BOF permite a FamousSparrow aprovechar módulos y herramientas ya existentes diseñados para este tipo de archivos.

Self-deletion

Como se describió en la sección Comportamiento controlado por argumentos, SparroWocky puede eliminarse completamente del sistema. Esto puede realizarse desde el servidor de Comando y Control (C&C) mediante el comando 0x13. Primero se elimina el mecanismo de persistencia previamente configurado y luego se crea y ejecuta el archivo por lotes (batch) que se muestra en la Figura 4.

@echo off
timeout /t 2
del "<legitimate_executable>" /f /q
del "<loader_library>" /f /q
del "<payload_filepath>" /f /q
del "%%0" /f /q\n

Figura 4. Archivo por batches para la self-deletion

Este proceso elimina todos los componentes empleados por el backdoor: el ejecutable legítimo, la biblioteca utilizada para el side-loading y el archivo de payload. Al finalizar, el propio script también se elimina a sí mismo.

Técnicas anti-análisis

SparroWocky emplea varias técnicas destinadas a dificultar su análisis y evadir las soluciones de seguridad que puedan estar presentes en el sistema comprometido. Una técnica habitual utilizada por el backdoor es la resolución dinámica de APIs mediante API hashing, aunque también implementa mecanismos más sofisticados que se describen a continuación.

SilentMoonwalk

La primera técnica destacable se denomina SilentMoonwalk y, esencialmente, proporciona un mecanismo para falsificar pilas de llamadas (call stacks). Su objetivo es impedir que las herramientas y productos de análisis identifiquen al verdadero origen de determinadas funciones que suelen ser monitoreadas, como las APIs de Windows. Este método requiere varios pasos de inicialización:

• Localizar el desplazamiento (offset) de RtlUserThreadStart y BaseThreadInitThunk, dos funciones que generalmente aparecen al inicio (o al final) de cualquier pila de llamadas.
• Localizar un gadget JOP (jump-oriented programming) y un gadget ROP (return-oriented programming) dentro de la biblioteca legítima kernel32.dll, que serán utilizados para restaurar la pila de llamadas original.

Una vez cumplidos estos requisitos, cuando SparroWocky realiza una llamada ofuscada a una función de la API de Windows, primero guarda el contexto actual del proceso (los registros); luego crea una pila de llamadas falsa utilizando los gadgets identificados anteriormente e inserta la dirección de una rutina encargada de restaurar tanto la pila como el contexto originales. Como resultado, parece que las llamadas a las APIs de Windows se originan en RtlUserThreadStart y BaseThreadInitThunk, ocultando así el verdadero origen de la ejecución. La Figura 5 muestra la vista de la pila de llamadas obtenida durante una sesión de depuración con WinDbg.

En el caso de SparroWocky, esta técnica se utiliza para ofuscar las llamadas realizadas por plugins en formato BOF (comando 0x14) o por la biblioteca de hooking MinHook, enlazada estáticamente.

Ocultación de la dirección de inicio de los threads

SparroWocky utiliza la biblioteca MinHook para aplicar un hook sobre la función CreateThread con el objetivo de ocultar a las soluciones de seguridad el valor original del parámetro lpStartAddress . En esencia, cualquier thread creado por SparroWocky tendrá como dirección de inicio la función AnimateWindow, algo que probablemente sería considerado legítimo por un producto de seguridad. El parche aplicado a AnimateWindow la convierte en un trampoline que simplemente ejecuta la dirección de inicio original, tal como se muestra en la Figura 6.

Camuflaje del proceso host para PE cargados dinámicamente

El último componente de código destacable de SparroWocky es su PE loader personalizado, utilizado cuando se ejecuta con la opción c. Si bien implementar PE loaders es una práctica bastante habitual entre los desarrolladores de malware, los autores de SparroWocky fueron un paso más allá e integraron mecanismos de camuflaje del proceso host.

Como se describió en la Tabla 2, cuando SparroWocky se ejecuta con la opción c, carga un archivo PE en memoria y lo ejecuta. Si el archivo no se proporciona como argumento, el PE loader analiza la línea de comandos especificada para extraer el nombre del archivo. Luego busca ese archivo en el directorio C:\Windows\System32\ y, lo que es más importante, recupera el archivo de localización MUI (Multilingual User Interface) en inglés asociado con el PE objetivo (almacenado como C:\Windows\System32\en-US\<exe_name>.mui).

En ese caso, el archivo PE se carga en memoria y se configuran varios hooks para garantizar que cualquier llamada realizada por el PE cargado para recuperar datos de recursos, como RtlLoadString  o RtlFindMessage, sea redirigida a los datos del archivo .mui. Este proceso replica el comportamiento normal de Windows al cargar archivos PE y reduce el riesgo de errores inesperados.

La línea de comandos obtenida desde stdin se analiza y SparroWocky aplica hooks a las siguientes funciones, utilizadas para recuperar información sobre los argumentos de la línea de comandos, con el fin de que apunten a dicha línea de comandos:

• GetCommandline[AW]
• __(w}getmainargs
• __p___argc
• __p___{w}argv

El PE loader también es capaz de registrar los manejadores de excepciones (exception handlers) del ejecutable recién cargado, una incorporación poco habitual pero crítica, ya que permite que las excepciones se gestionen correctamente.

Por último, antes de llamar al entry point del archivo PE cargado, SparroWocky falsifica e inserta una estructura LDR_DATA_TABLE_ENTRY falsa dentro de la lista doblemente enlazada de la estructura PEB_LDR_DATA. Esta lista doblemente enlazada es utilizada por Windows para realizar el seguimiento de los módulos cargados y suele ser monitoreada por productos de seguridad. La Figura 7 muestra un fragmento del código utilizado para configurar algunos de sus campos.

Esta última técnica demuestra que los desarrolladores de SparroWocky poseen un profundo conocimiento del mecanismo de carga de archivos PE de Windows y están dispuestos a ir un paso más allá para camuflar el proceso host y confundir al software de monitoreo.

Protocolo de red

Para comunicarse con su servidor de Comando y Control (C&C), SparroWocky utiliza el protocolo de cifrado TLS. Internamente, el backdoor emplea la biblioteca Mbed TLS, y el único detalle destacable es que utiliza la cadena de personalización acdbenus al inicializar el generador determinístico de bits aleatorios, como se muestra en la Figura 8.

Antes del handshake inicial de TLS, se establece una conexión TCP con el servidor C&C utilizando uno de tres modos de conexión.

El modo de conexión 0 indica que SparroWocky utiliza el proxy configurado actualmente en el equipo o una conexión TCP directa si no existe un proxy de sistema configurado. Esta configuración se obtiene consultando el valor de registro ProxyServer ubicado en la clave:HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings. Si la conexión al servidor proxy falla, SparroWocky intenta conectarse mediante el modo 1 y posteriormente mediante el modo 2.

El modo de conexión 1 corresponde a una conexión a través de un proxy HTTP. Esta conexión utiliza autenticación Negotiate (Kerberos o NTLM) o Basic, empleando el nombre de usuario y la contraseña definidos en la configuración. Ambos métodos utilizan encabezados HTTP genéricos con la cadena User-Agent configurada como Mozilla/5.0.

El modo de conexión 2 utiliza un proxy SOCKS5, ya sea sin autenticación (campo AUTH configurado en 0x00) o mediante autenticación con usuario y contraseña (campo AUTH configurado en 0x02). Los valores utilizados en este último caso se obtienen de la configuración del malware

Mensajes de comando

Una vez completado el handshake TLS, SparroWocky envía los bytes 0x11223344 (big-endian) para indicar que está listo para recibir comandos en la sesión principal. El backdoor utiliza un formato simple para recibir comandos y enviar resultados, como se ilustra en la Figura 9.

Si el campo command_arg_size es distinto de 0, significa que después del encabezado se enviarán o recibirán datos adicionales. En ese caso, los datos (ya sean argumentos de comandos o resultados) se cifran mediante RC4, y cada mensaje utiliza una nueva clave de ocho bytes generada dinámamente, que se incluye en el encabezado.

Infraestructura de red

SparroWocky utiliza directamente la dirección IP de sus servidores C&C para establecer las conexiones, generalmente a través del puerto 443. En algunos casos también lo hemos observado operando sobre el puerto 8080. ; Si bien hemos detectado certificados autofirmados reutilizados en múltiples servidores, no contamos con un fingerprint confiable que pueda utilizarse como indicador genérico

Conclusión

Durante la segunda mitad de 2025 y la primera mitad de 2026, FamousSparrow concentró sus operaciones en objetivos ubicados en América Latina. Este cambio representa una desviación respecto de su estrategia previa de alcance global. Como parte de esta evolución, el grupo desarrolló SparroWocky, que reemplazó a SparrowDoor como su principal implante. Aunque no parece estar basado en el mismo código fuente, observamos que SparroWocky conserva diversas funcionalidades y conceptos presentes en el backdoor anterior del grupo, que analizamos en una publicación previa. Sin embargo, incorpora técnicas de evasión más sofisticadas para pasar desapercibido.

FamousSparrow continúa recurriendo a herramientas ofensivas de código abierto con fines maliciosos. Anteriormente, estas herramientas solían desplegarse junto al backdoor del grupo como componentes independientes. Con SparroWocky observamos además que el grupo cuenta con las capacidades de desarrollo necesarias para integrar código de proyectos de código abierto directamente dentro de su propio backdoor personalizado.

IoCs

En nuestro repositorio de GitHub se puede encontrar una lista exhaustiva de indicadores de compromiso (IoC) y muestras.

Archivos

Red

Técnicas de MITRE ATT&CK

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