Autores
Introducción
Los trackers de torrents se usan desde hace tiempo para distribuir malware disfrazado de películas, juegos y otro contenido popular. En investigaciones anteriores, mostramos que los cibercriminales recurren con frecuencia a los torrents como vector inicial de infección, utilizando cracks e instaladores piratas troyanizados para alcanzar a un gran número de usuarios. Sumado a esto, las instrucciones de instalación de software pirata suelen indicar a los usuarios que desactiven el antivirus, lo que acostumbra a estos usuarios a ignorar las amenazas potenciales que ellos mismos invitan a sus equipos.
Durante el análisis de un malware que usa redes de blockchain para su infraestructura de C2, identificamos un framework modular de múltiples etapas hasta entonces desconocido, al que llamamos MovieReaper.
Este informe describe en detalle una nueva campaña de crimeware que comenzó con la infección masiva de usuarios a través de un repositorio de archivos comprometido, usado por trackers de torrents. Identificamos varios cientos de víctimas, entre usuarios individuales y organizaciones, en numerosos países, como Rusia, Turquía, Japón, Kenia, Uganda y Colombia, además de varios países europeos, entre ellos España, Países Bajos, Bélgica y Alemania.
En este posteo analizaremos los métodos que usan los atacantes para evadir la detección de las soluciones de seguridad y los sandboxes, además de examinar las capacidades de este framework modular.
Los productos de Kaspersky detectan esta amenaza como HEUR:Trojan.Win64.Agent.gen.
Detalles técnicos
Contexto
A mediados de agosto de 2026, durante la búsqueda de nuevas amenazas, identificamos una campaña de infección a gran escala que distribuía un malware hasta entonces desconocido, disfrazado de películas populares. La campaña afectó tanto a personas físicas como a organizaciones en varios países. Nuestro análisis inicial reveló un factor común entre las víctimas: todas usaban trackers de torrents. Este hallazgo nos llevó a investigar la campaña con mayor profundidad y a analizar su mecanismo de distribución, su alcance y los implantes maliciosos hasta entonces desconocidos.
Infección inicial y distribución
Los trackers comprometidos son el principal vector utilizado para distribuir el malware de esta campaña. Durante nuestra investigación, identificamos numerosos reportes de usuarios que describían la descarga de archivos sospechosos en lugar del contenido esperado.
Por ejemplo, un usuario de un popular tracker de películas reportó el siguiente caso:
Traducción
Independientemente de la película que intente descargar, el torrent siempre inicia la descarga del mismo archivo ejecutable
Un análisis más profundo mostró que los atacantes no habían comprometido los propios trackers, sino que habían vulnerado un repositorio público de archivos torrent ampliamente utilizado (itorrents[.]org). Como resultado, los trackers que dependían de este repositorio comenzaron a distribuir involuntariamente archivos torrent maliciosos a sus usuarios. Este enfoque es especialmente peligroso, ya que permite a los atacantes alcanzar a usuarios de varios trackers sin necesidad de vulnerar cada plataforma por separado. A la fecha de redacción de este informe, el repositorio sigue comprometido.
Cuando el usuario intenta descargar un torrent mediante un enlace magnet, el repositorio legítimo devuelve un archivo modificado, lo que provoca la descarga de un loader malicioso en lugar del archivo solicitado. Este loader se encarga de desplegar el framework que hemos denominado MovieReaper.
El loader inicia la cadena de infección que se ilustra en el siguiente diagrama. Cada etapa de la cadena se describe en detalle en las secciones siguientes.
Implantes maliciosos
La cadena de infección consta de varios pasos. El payload final se ejecuta directo en memoria, por lo tanto, el loader es el único archivo que se escribe en disco, permitiendo que las etapas posteriores evadan la detección.
El malware no presenta un alto nivel de ofuscación, a excepción de sus cadenas de texto, las cuales están protegidas mediante un cifrado de flujo personalizado. La mayoría de los mecanismos de defensa están orientados principalmente a evadir la detección en entornos de análisis (sandboxes).
Paso 1. El loader
El loader más propagado se distribuyó a través de trackers bajo diferentes nombres (por ejemplo, the odyssey (2026) [1080p] [webrip] [5.1].exe); sin embargo, el hash del archivo (MD5: A0B13781EDD7CFDAB13D79AFFF3C83C1) se mantenía idéntico en todas las descargas. Hemos identificado varias versiones de loaders en las que el ejecutable se bajaba un nombre de archivo largo, para ocultar la extensión .exe del final, y el ícono de una aplicación conocida, como VLC.
Después de que el usuario ejecuta manualmente la aplicación, esta crea un mutex global para garantizar que solo se ejecute una vez. En nuestras muestras observamos varias variantes de mutex que contienen una cadena generada al azar (por ejemplo, Global\fnulSktzSqvVLXHU).
A continuación, el ejecutable realiza una serie de operaciones para evadir la detección en entornos sandbox. Durante estas operaciones, el malware evita las llamadas a LoadLibrary y GetProcAddress para obtener las direcciones de las funciones necesarias. En su lugar, localiza las bibliotecas cargadas recorriendo la lista doblemente enlazada que se obtiene del campo Ldr de la estructura PEB. Luego, analiza manualmente cada DLL cargada para calcular la dirección de las funciones requeridas.
Una vez superadas todas las verificaciones iniciales, este binario se prepara para establecer una conexión de red con el servidor web de C2 para descargar el shellcode, mapearlo en memoria con permisos RWX y ejecutarlo. Para ello, el loader decodifica el nombre de dominio https://deadhub[.]org y, si la conexión falla, usa la dirección IP http://193.23.118[.]155 como respaldo, conectándose a ella mediante el protocolo HTTP sin cifrar. Luego, el malware selecciona un grupo aleatorio de cadenas y las usa para construir una dirección HTTP para descargar distintas partes del shellcode.
Ejemplos de URLs:
/cloud/v192.4/ui/sync-status-icons.png
/cloud/v192.4/onboarding/welcome-bg.jpg
/cloud/v192.4/ui/file-preview-placeholder.png
/cloud/v192.4/shared/link-banner.jpg
Una vez descargado el shellcode, el malware mapea el espacio de direcciones y lo ejecuta. El loader abusa del mecanismo de Vectored Exception Handling (VEH) para controlar el flujo de ejecución. Para ello, registra un handler y sobrescribe en memoria la dirección de su controlador para provocar intencionalmente un breakpoint. Esto no provoca el fallo del programa, sino que desvía el flujo de control hacia una función que, en la práctica, ejecuta directamente la llamada al sistema NtProtectVirtualMemory mediante la instrucción de llamada al sistema 0x0F 0x05, previamente localizada dentro de ntdll. A continuación, llama a la función no documentada de ntdll EtwpCreateEtwThread, una alternativa conocida a CreateThread para ejecutar código, e inicia el shellcode.
Paso 2. Shellcode
La segunda etapa de este malware realiza una solicitud HTTPS al endpoint /getAccountInfo de la blockchain de Solana para consultar la cuenta 6pnDGAiHgyPdmckM5Qt1YbanGzrX43WLEU159nRaNLDm. La respuesta incluye un campo data que contiene la dirección del segundo C2 codificada en base64 y cifrada con una clave XOR estática ubicada dentro del propio shellcode. Para almacenar los datos en esta cuenta, los atacantes usaron un smart contract de Solana (dirección: CSiY8bQLBYPdfPWkwipBzH6sijTVQVVsA279JQdvwHtL).
El uso de la red blockchain de Solana para almacenar las direcciones de los servidores de C2 dificulta significativamente la detección y el posterior bloqueo de la infraestructura de la campaña.
El payload malicioso de la segunda etapa se comunica con el servidor de C2 exclusivamente a través de HTTPS, implementando certificate pinning de TLS y la biblioteca nanopb para estructurar los datos transmitidos.
La lógica principal del implante de esta segunda etapa incluye varios comandos iniciales. El más relevante analiza un archivo COFF, lo carga en memoria y ejecuta su función module_init. Esto proporciona una interfaz conveniente para ampliar la lista de comandos disponibles y da paso a la siguiente etapa del payload.
Paso 3. Evasión del UAC y persistencia
Los módulos recuperados fueron compilados con símbolos de depuración, lo que facilitó y aceleró el proceso de ingeniería inversa. Tras obtener la siguiente etapa desde el segundo servidor de C2, el módulo recién cargado ejecuta varias tareas mediante la función module_init.
Esta tercera etapa evade el UAC y establece persistencia en el sistema mediante técnicas de dominio público. Como parte de este proceso, el binario se camufla como C:\ProgramData\Microsoft\Windows\Telemetry\msedge.exe y vuelve a ejecutarse.
El proceso reiniciado se ejecuta a partir del loader original, pero con un argumento de línea de comandos especial que le permite omitir la mayoría de las verificaciones de los entornos de sandbox e iniciar de inmediato la descarga del payload final. El ejecutable realiza los mismos pasos que antes, pero esta vez, en lugar de cargar el módulo de persistencia y evasión del UAC, se descarga un nuevo módulo desde el segundo servidor de C2. Esto se debe a que la solicitud al servidor remoto incluye un flag que indica si el implante se está ejecutando desde la carpeta Telemetry, lo que permite al C2 distinguir la primera ejecución de las posteriores (tras la persistencia y el reinicio).
Paso 4. Implante final
El módulo final (file manager) contiene 21 comandos que dan al atacante acceso al sistema de archivos del equipo infectado. Permite al operador remoto descargar, subir y leer archivos del sistema, así como ver y listar directorios. También permite manipular archivos mediante operaciones de creación, copia, renombrado, movimiento, eliminación, cambio de permisos y creación de enlaces simbólicos. Además, cuenta con comandos de vista previa y generación de miniaturas que permiten exfiltrar previsualizaciones de imágenes y archivos antes de descargarlos por completo.
Creemos que también se pueden cargar otros módulos bajo demanda, según las necesidades del operador.
Infraestructura
En esta campaña, los atacantes utilizaron servicios de diversos proveedores comerciales de hosting para alojar su infraestructura de C2. Además, como se mencionó anteriormente, la campaña abusó de la blockchain legítima de Solana, a través del endpoint RPC api.mainnet.solana.com, para obtener la dirección del servidor de C2 correspondiente a la segunda etapa.
Este enfoque proporciona a los atacantes un almacenamiento descentralizado para las direcciones de C2, lo que añade una capa de resiliencia y dificulta que los defensores interrumpan la campaña mediante el bloqueo de las direcciones IP de destino.
Víctimas
La campaña observada estuvo dirigida tanto a personas físicas como a organizaciones de Europa, Asia, África y América Latina, con intentos de infección identificados en países como Rusia, España, Alemania, Finlandia, Turquía, Japón, Nepal, Kenia, Tanzania, Ghana, Uganda, Colombia, los Países Bajos, Bélgica y otros. La campaña afectó a organizaciones de los sectores más diversos, incluidas empresas comerciales, el sector público, TI, consultoría, comercio minorista, transporte y agricultura.
Conclusión
Nuestra investigación permitió hacer un seguimiento retrospectivo de la actividad del actor, con operaciones detectadas desde octubre de 2025. Durante este período, la campaña evolucionó progresivamente: los autores del malware ampliaron su arsenal y dificultaron la detección del loader. Aun así, el esquema general se mantuvo igual: las cadenas codificadas y los fragmentos de shellcode se descargan mediante HTTP, mientras que se siguen utilizando las mismas técnicas para evadir sandboxes y máquinas virtuales.
El punto más efectivo para interrumpir esta campaña se encuentra en la primera etapa. Dado que los atacantes utilizan únicamente un nombre de dominio y una dirección IP específicos para distribuir el shellcode, bloquear ambos impide que la cadena de infección continúe. Esto también evita la ejecución del payload de la segunda etapa, que utiliza la red blockchain de Solana para su C2 y, por lo tanto, es más resistente a los métodos tradicionales de bloqueo de infraestructura.
Aun así, la autonomía, la modularidad y la ejecución de este framework directamente en la memoria RAM generan un alto potencial para su reutilización en futuras campañas con ajustes mínimos. Continuaremos monitoreando la actividad de este actor para identificar a tiempo posibles nuevas amenazas.
Indicadores de compromiso
Hashes de archivos
4334BBAEA8DE33BF9D845E9B4E4E3BC2
4843F9FAFCAE492F11E2D4D33DBB4CDD
5310CABAE3FBE6DB8742849B588093F9
A0B13781EDD7CFDAB13D79AFFF3C83C1
70060341CAF3338697A7DDFE0FB62875
AD4643EEA15AC286FA47D1131F9EF756
D0B967571AC8A3863C7F324BF5BDE99C
D88D550D0FB8E60CFFFF3EA61FF7A067
Ruta del archivo
%ProgramData%\Microsoft\Windows\Telemetry\msedge.exe
Mutexes
Global\E4AyDKzvEhe2hgAr
Global\fnulSktzSqvVLXHU
Dominios e IP maliciosos
C2 de primera etapa:
deadhub[.]org
193.23.118[.]155
C2 de segunda etapa:
208.64.33[.]90
208.94.246[.]53
Ulises y los troyanos, juntos de nuevo: MovieReaper ataca a usuarios de todo el mundo mediante torrents comprometidos