C2Looper explicado: cómo funciona la puerta trasera para Windows basada en Rust

C2Looper es una nueva puerta trasera para Windows escrita en Rust. Permite a los atacantes hacerse con un punto de apoyo en el equipo comprometido, ejecutar comandos de forma remota, recopilar información del sistema y desplegar otras cargas maliciosas. Zscaler ThreatLabz identificó esta familia en julio de 2026 y considera probable que esté siendo utilizada por un actor relacionado con ransomware. Esa valoración no equivale a una atribución confirmada, y la posible vía de distribución también se considera de confianza baja o media.

Su evolución más llamativa es el cambio desde un mando y control —C2, por sus siglas en inglés— basado en HTTP en texto plano hacia una infraestructura alojada en GitHub. Para los equipos defensivos, esto se traduce en dos patrones que conviene buscar: balizas HTTP muy regulares en las primeras muestras y tareas basadas en archivos JSON dentro de repositorios en las variantes más recientes.

Por qué C2Looper preocupa a la defensa frente al ransomware

C2Looper no es un ransomware en sí mismo. Su función encaja mejor con las primeras fases de una intrusión: el atacante puede ejecutar comandos, inspeccionar el equipo, descargar archivos y desplegar herramientas adicionales después del compromiso inicial. Esas capacidades pueden ayudarle a mantener el acceso y ampliar su control antes de una posible operación de ransomware.

Los informes disponibles no establecen una atribución pública definitiva a un grupo de ransomware concreto. Las posibles similitudes con infraestructuras asociadas a otras familias de malware deben considerarse líneas de investigación, no una prueba de autoría o control operativo compartido.

Cómo funcionan las dos versiones conocidas de C2Looper

Versión antigua: mando y control directo por HTTP

Las primeras muestras se comunican con un servidor controlado por el atacante mediante HTTP en texto plano y utilizan tareas con formato JSON. Los informes describen consultas muy frecuentes, incluso con intervalos de aproximadamente un segundo, lo que puede generar una señal de comportamiento distintiva en el equipo o en la red.

La baliza del implante identifica a la víctima mediante datos como el nombre de usuario de Windows, el nombre DNS del equipo, el identificador del proceso de C2Looper en ejecución y un identificador de bot derivado del nombre del equipo y del usuario. La baliza se envía a la ruta /api/beacon, mientras que los resultados de los comandos se remiten a /api/result/.

El conjunto de órdenes ofrece al operador un control práctico sobre el sistema infectado. Incluye:

• Ejecución de comandos de shell o del sistema
• Reconocimiento del equipo y del entorno
• Descarga de archivos
• Actualización del implante y despliegue de cargas adicionales

Una función especialmente relevante es el comando upload. Puede descargar un ejecutable portable desde una URL indicada por el operador y guardarlo como una DLL en la carpeta local de OneDrive del usuario. Después, el malware puede detener el proceso de OneDrive y utilizar un ejecutable legítimo de este servicio para cargar la biblioteca colocada mediante DLL sideloading. En las muestras analizadas se observó el archivo wtsapi32.dll en %LocalAppData%\\Microsoft\\OneDrive.

La técnica consiste en situar código malicioso junto a un ejecutable legítimo y aprovechar el comportamiento normal de carga de bibliotecas de ese programa. Por eso, la señal importante para los defensores no es simplemente que OneDrive esté instalado, sino que un binario legítimo de OneDrive cargue una DLL inesperada desde una ubicación poco habitual o con permisos de escritura para el usuario.

Técnicas de evasión de las primeras muestras

C2Looper utiliza descifrado XOR en tiempo de ejecución para ocultar cadenas de texto, aparentemente con una clave reutilizada de ocho bytes. También resuelve dinámicamente las API de Windows mediante LoadLibrary y GetProcAddress. Estas técnicas pueden restar eficacia a una inspección estática sencilla y hacen más valiosa la telemetría de comportamiento recopilada por las herramientas de detección y respuesta en el endpoint —EDR—.

Versión nueva: GitHub como infraestructura de C2

Una compilación más reciente sustituye el servidor C2 convencional por repositorios de GitHub. Según los informes sobre esta variante, los repositorios sirven para distribuir tareas, registrar balizas, recibir resultados y alojar datos relacionados con cargas adicionales.

Cada equipo infectado recibe un directorio propio dentro del repositorio. El implante lee las instrucciones desde cmd.json, ejecuta la acción solicitada y escribe la salida en result.json, en ese mismo directorio. El operador obtiene así un flujo sencillo, basado en archivos, para enviar órdenes y recopilar resultados sin depender de un servidor C2 dedicado.

El uso de GitHub puede dificultar las estrategias basadas únicamente en bloquear dominios, porque la plataforma también forma parte de infraestructuras legítimas de desarrollo y negocio. La respuesta defensiva debe centrarse en el comportamiento: investigar accesos periódicos a repositorios o API de GitHub desde equipos que normalmente no necesitan ese servicio y distinguir la actividad JSON sospechosa por equipo de los flujos autorizados de desarrollo o integración continua.

El traslado a GitHub y la incorporación de nuevas capacidades de ejecución de cargas sugieren que C2Looper continúa en desarrollo activo.

Posible distribución mediante ingeniería social ClickFix

ThreatLabz considera, con un nivel de confianza bajo o medio, que C2Looper podría distribuirse mediante una cadena de infección ClickFix en varias etapas. En este tipo de campañas, la víctima ve una falsa verificación, un error del navegador, un CAPTCHA o un supuesto mensaje de reparación del sistema. A continuación, se la convence para copiar y ejecutar un comando en PowerShell, en el cuadro de diálogo Ejecutar de Windows o en otra interfaz de comandos.

Este método convierte la interacción humana en un punto clave de prevención y detección. Una página web o un mensaje del navegador nunca debería pedir al usuario que pegue comandos en PowerShell, Terminal o Ejecutar para completar una verificación o solucionar un supuesto problema.

Otros informes describen campañas de vishing a través de Teams y abusos de Quick Assist dentro de un ecosistema más amplio de ingeniería social. Sin embargo, las evidencias disponibles no demuestran que todas esas campañas hayan distribuido C2Looper. La relación debe tratarse como un contexto plausible, no como una atribución confirmada.

Qué deberían vigilar los equipos de seguridad

Las organizaciones pueden concentrarse en unos pocos comportamientos de alto valor, en lugar de intentar bloquear todas las herramientas o servicios que podrían estar relacionados con el malware:

• Balizas HTTP frecuentes en texto plano: investigar tráfico POST JSON inusualmente regular, especialmente solicitudes parecidas a /api/beacon y /api/result/, cuando estén asociadas a un proceso nuevo o sospechoso.
• Actividad sospechosa en GitHub: buscar accesos desde endpoints a repositorios o API de GitHub que sigan un patrón periódico o impliquen directorios por equipo con archivos cmd.json y result.json. No conviene bloquear GitHub de forma indiscriminada: deben contemplarse los flujos legítimos de desarrollo y automatización.
• DLL sideloading en OneDrive: generar alertas cuando un ejecutable legítimo de OneDrive se inicie desde una ruta inusual del perfil del usuario, cargue una DLL desde un directorio adyacente y modificable, o cree procesos secundarios inesperados.
• Ejecución de comandos y reconocimiento: utilizar la telemetría EDR para identificar PowerShell, cmd.exe, actividad del cuadro Ejecutar, descubrimiento del sistema, descargas por etapas y ejecución de shell desde binarios recién observados.
• Comportamiento de un implante en Rust: analizar conjuntamente la resolución dinámica de API, las cadenas cifradas, las consultas periódicas a la red y el despliegue de cargas, en vez de depender de una sola característica del archivo.

Prioridades de prevención

Los controles técnicos deben complementarse con medidas contra la ingeniería social. Cuando las necesidades del negocio lo permitan, las organizaciones deberían restringir o someter a control la ejecución de PowerShell por parte de usuarios, los intérpretes de comandos, los hosts de scripts, los binarios sin firma y la ejecución desde directorios con permisos de escritura para el usuario. Las listas blancas de aplicaciones también pueden reducir la capacidad de ejecutar una carga descargada.

Los equipos de seguridad y soporte deben formar a los empleados para que nunca peguen comandos proporcionados por una web, un CAPTCHA, una página de error del navegador o un contacto de soporte no solicitado. Las herramientas de asistencia remota deberían utilizar flujos aprobados, canales de soporte verificados, autenticación multifactor, registro de sesiones y revisión rápida de conexiones inusuales.

La segmentación de red, el principio de mínimo privilegio, la autenticación multifactor, la aplicación rápida de parches en sistemas expuestos a Internet y unas copias de seguridad probadas, desconectadas o inmutables pueden limitar el impacto de una intrusión. Si un endpoint muestra balizas sospechosas, actividad de shell o DLL sideloading, debe aislarse cuanto antes, preservando los registros del equipo, los datos de red y, cuando proceda, la memoria para la investigación.

En resumen

La importancia de C2Looper está en su evolución: ha pasado de ser una puerta trasera con un C2 HTTP relativamente directo a un implante más flexible que puede utilizar repositorios de GitHub como infraestructura operativa. Sus funciones de shell remoto, reconocimiento, descarga y actualización lo convierten en un punto de apoyo creíble para intrusiones relacionadas con ransomware. Aun así, las evidencias disponibles exigen una valoración prudente y no permiten confirmar una atribución definitiva.

La mejor defensa combina procesos de usuario resistentes a ClickFix con la búsqueda de comportamientos anómalos: ejecución inesperada de comandos, DLL sideloading en OneDrive, consultas HTTP extremadamente frecuentes y actividad inexplicada en repositorios de GitHub.