Aurora, el ransomware que usa Cursor: meses de ataques diseñados con Claude Sonnet

El directorio abierto de una infraestructura vinculada al grupo Aurora permitió a CloudSEK y Gambit Security reconstruir meses de actividad: más de veinte organizaciones afectadas entre abril y julio de 2026, diez objetivos contra los que se utilizó el agente de Cursor y un cifrador escrito en Zig para Windows, Linux y ESXi. Los historiales de chat recuperados muestran que el operador planificaba los ataques en ruso y confiaba a Claude Sonnet tareas operativas concretas, no solo scripts genéricos.

La exposición de la infraestructura y las víctimas registradas

CloudSEK identificó un directorio abierto que dejó al descubierto meses de actividad del grupo de habla rusa conocido como Aurora o Aur0ra. En los datos figuran más de veinte organizaciones en nueve países, atacadas entre abril y julio de 2026; cuatro víctimas aparecieron posteriormente en el sitio de filtración de datos del grupo. El operador usaba Cursor para planificar los ataques en ruso, excluyendo sin excepción direcciones IP y dominios de los países de la Comunidad de Estados Independientes.

Aurora emergió públicamente a finales de mayo de 2026, cuando CYFIRMA describía sus ataques dirigidos principalmente a sistemas Windows y una continua actualización de funcionalidades. Según el sitio Ransomware.Live, al 31 de agosto de 2026 las víctimas registradas son 33, concentradas sobre todo en Estados Unidos, Alemania, Países Bajos, Canadá y Reino Unido.

Los nombres de las empresas afectadas no fueron divulgados por las firmas de seguridad, pero Reuters señaló a Christeyns, Teckentrup, Helideck Certification Agency, Bayou Title, un distribuidor farmacéutico argentino y un fabricante italiano.

La cadena de ataque desde el bombardeo de correo hasta el cifrador

Black Hills Information Security reconstruyó un caso a principios de agosto de 2026. El acceso inicial se obtuvo mediante un bombardeo de correo electrónico agresivo, seguido de llamadas telefónicas en las que el atacante se hacía pasar por personal del servicio de asistencia de TI. Tras convencer a la víctima, el grupo estableció acceso remoto a través de Xray-core, una utilidad de código abierto.

A partir de ahí, la cadena continúa con movimiento lateral mediante SMB, LDAP, WinRM, RDP y RPC, adquisición de cuentas de administrador con altos privilegios, borrado de registros y desactivación de Microsoft Defender. Solo después llegan la exfiltración de datos sensibles y la distribución del cifrador.

Cómo el operador usa Cursor Agent en los diez objetivos

Gambit Security observó al operador de Aurora usar Cursor Agent, que ejecuta Claude Sonnet de Anthropic, para actividades prácticas de explotación contra diez objetivos entre el 8 de abril y el 21 de mayo de 2026. En estos casos, al agente se le proporcionaban credenciales o una vía de acceso ya existente hacia la organización víctima; luego se le asignaban tareas de explotación.

A veces el atacante pedía al agente únicamente alcanzar un objetivo, por ejemplo «dime qué derechos tiene el usuario». En otros casos indicaba la herramienta a usar o imponía seguir un plan de ataque pregenerado. En algunas situaciones, el agente proponía una lista de pasos siguientes y el atacante respondía con un número.

Las tareas delegadas incluían:

• instalación de un cliente VPN o de proxychains, configuración y conexión a la víctima con credenciales proporcionadas o mediante un túnel SOCKS existente;
• escaneo de subredes internas con Nmap o NetExec;
• enumeración del dominio para informar los privilegios de un usuario específico, usando el recolector BloodHound de NetExec;
• intentos de ataque NTLM relay forzando la autenticación con PetitPotam, Coerce Plus y PrinterBug, usando Impacket ntlmrelayx para reenviar la autenticación resultante;
• ataques a certificados con Certipy.

La mayoría de los comandos no alcanzaba el objetivo al primer intento: se necesitaban continuos ajustes de comandos y scripts. Algunos finalmente tenían éxito, otros fallaban y devolvían al atacante solo un informe de los intentos.

Los historiales de chat también muestran un plan completo de explotación de Active Directory Certificate Services escrito en ruso, señal de que Cursor se usaba para diseñar fases enteras de la campaña.

El cifrador Zig compartido entre Windows, Linux y ESXi

CloudSEK identificó versiones Windows y Linux de Aurora escritas en Zig. Los dos binarios — sap.exe para Windows y encrypt.out para Linux/ESXi — son compilaciones estáticas derivadas de una única base de código Zig compilada para objetivos diferentes, no una reescritura separada. El binario de Windows contiene en su interior ejemplos de uso de la compilación de Linux, residuo de un árbol de código fuente compartido.

La variante de Windows impide la restauración del sistema eliminando las instantáneas de volumen y desactivando la Restauración del sistema directamente mediante el Registro. La variante de Linux/ESXi intenta, en cambio, terminar forzosamente cada máquina virtual presente en el host antes de iniciar el cifrado.

En las campañas que involucran la versión Linux se utilizó un script Python llamado esxi_finder.py para localizar hipervisores VMware ESXi y servidores vCenter en la red de la víctima.

Una clave recuperada del cifrador habría permitido acceder a una negociación de rescate y a un clúster de cuatro monederos de criptomonedas. Los datos muestran repartos variables: los afiliados reciben entre el 54 % y el 79 % del rescate, proporción decidida por víctima según el importe solicitado y los ingresos de la organización; el resto va a los administradores.

Gryxa, el kit de herramientas construido por IA contra 324 hosts

ReliaQuest descubrió un conjunto de herramientas distinto, llamado Gryxa, utilizado por un actor con motivación económica para una operación de acceso inicial contra 324 hosts. Según los investigadores, es el primer caso observado en el que la IA construyó toda la operación, desde el kit de herramientas hasta la consola de gestión.

Gryxa convierte software legítimo de monitoreo y gestión remota en acceso encubierto, mantiene la persistencia con mecanismos de reinicio independientes y roba credenciales guardadas en navegadores basados en Chromium. Cuando la conexión con el atacante se interrumpe, intenta desactivar o desinstalar el agente de protección de endpoints, por ejemplo Microsoft Defender, en un plazo de 10 a 13 minutos. Cuando el relé vuelve a estar accesible, reactiva Defender.

Las evidencias indican que el actor hizo jailbreak a un agente de codificación de IA, presentando el desarrollo como un «despliegue interno autorizado». El conjunto de herramientas probablemente se distribuye mediante correos de phishing; una vez ejecutado, establece persistencia con tareas programadas y puede eludir las protecciones de cifrado vinculado a aplicaciones de Chromium. Las credenciales recopiladas se transmiten a través de Telegram.

El aspecto más inusual es el registro de las actividades de corrección: tras la eliminación del implante RMM visible, un componente oculto recopila registros de Windows y artefactos del host y los carga en la infraestructura del atacante. La consola incluye un trabajo predefinido llamado collect-forensics, lo que indica una capacidad rutinaria, no una respuesta a un incidente aislado. Gryxa rota los archivos de registro cuando superan los 200 KB, preservando la actividad reciente para quienes responden con rapidez.

Defensa: qué buscar y por qué las barreras de protección no bastan

No se han publicado recomendaciones de mitigación específicas por parte de los investigadores. El panorama técnico ofrece, no obstante, indicadores útiles para los defensores: tráfico hacia Xray-core, presencia de Nmap, NetExec, BloodHound, Certipy o Impacket ntlmrelayx, intentos de ataque NTLM relay y modificaciones anómalas en las instantáneas de volumen o en el Registro. En el caso de Gryxa, se deben monitorizar los procesos RMM no autorizados, las tareas programadas sospechosas y el envío de archivos a través de Telegram.

El caso Aurora muestra que las barreras de protección de los proveedores de modelos de IA no impidieron el uso operativo de Cursor Agent. El atacante no tuvo que escribir exploits originales: proporcionó al agente accesos ya válidos y lo guió con objetivos, números y planes pregenerados. El riesgo no es la IA que se vuelve autónoma, sino la IA que reduce el coste de cada paso dentro de una red ya comprometida.