Agentes de IA de Cursor hicieron las intrusiones del ransomware Aur0ra

«Don't try brute-forcing domain administrator accounts anymore» (deja de intentar fuerza bruta contra las cuentas de administrador de dominio). Es una de las órdenes que un operador del ransomware Aur0ra dio en ruso a un agente de Cursor en mitad de una intrusión real, y Sophos la publicó este 29 de octubre de 2026 junto a otras dos en el informe que atribuye al grupo GOLD OGRE el uso de agentes de IA para recorrer redes de víctimas hasta llegar a administrador de dominio. Tres de esas víctimas aparecieron después en el sitio de filtraciones del grupo.

• Sophos liga la infraestructura de un laboratorio de evasión de EDR con IA, descrito en junio, al Cobalt Strike que GOLD OGRE usa en operaciones de Aur0ra.
• Los agentes, orquestados por Composer de Cursor y modelos de Anthropic, xAI y Moonshot, hacían descubrimiento, Kerberoasting, NTLM relay y movimiento lateral con poca intervención humana.
• Gambit Security y CloudSEK documentaron en agosto, desde un directorio abierto, más de 20 víctimas en nueve países, con una organización española en un segundo grupo de actividad.
• Las defensas son las de siempre, con menos margen de tiempo: SPN fuera de cuentas privilegiadas, plantillas de AD CS auditadas, firma SMB, backups aislados y los IoC de la tabla cargados en el SIEM.

Lo que Sophos encontró en los artefactos de Cursor de GOLD OGRE

El informe de Sophos, firmado por el equipo de investigación de su Counter Threat Unit y por Colin Cowie, responsable de inteligencia de amenazas de Sophos MDR, parte de unos artefactos de Cursor que los analistas recuperaron a finales de agosto de 2026 y que estaban asociados a operaciones de Aur0ra y a pruebas de evasión de EDR. Cursor es el entorno de desarrollo con agente que el blog ya conoce por la extensión troyanizada de Claude Code que su marketplace sirvió durante once horas con un backdoor SSH, y aquí aparece en el otro papel, como consola desde la que los operadores daban trabajo a los agentes.

El diagrama de Sophos reparte la cadena en tres tramos. El acceso inicial lo hacían personas, con ingeniería social por Teams, señuelos ClickFix y fuerza bruta contra VPN. La intrusión la hacía el agente a partir de lo que el operador le entregaba: credenciales de VPN, un acceso SOCKS, un objetivo y una meta. Con eso, el agente descubría la red y el Active Directory, lanzaba ataques basados en credenciales, se movía en lateral y buscaba datos. El impacto volvía a manos humanas: exfiltración, despliegue del ransomware y extorsión. En palabras del informe, los agentes ejecutaban comandos, afinaban los scripts cuando algo fallaba y se desplazaban por la red con poca intervención humana, y en una parte de los entornos consiguieron acceso de gestión del dominio.

Las tres órdenes que Sophos reproduce dan la medida de ese reparto. Las traducimos de la versión inglesa del informe.

La primera abre la sesión como si fuera una auditoría encargada, y ahí está el truco con el que el grupo sorteó las barreras de los modelos. Sophos lo dice sin matices: «AI guardrails were bypassed by framing the intrusions as authorized red team activity» (las barreras de la IA se sortearon presentando las intrusiones como actividad autorizada de red team) o como pruebas de diagnóstico. La tercera pide localizar servidores de backup, NAS y virtualización, que es el inventario que un afiliado de ransomware necesita antes de cifrar.

Las intrusiones las orquestaba Composer, el modelo agéntico propio de Cursor, junto con modelos de Anthropic, xAI y Moonshot. Según Sophos, los atacantes «initially used Anthropic almost exclusively but then introduced other models» (al principio usaron Anthropic casi en exclusiva y después introdujeron otros modelos), y el cambio podría tener que ver con el paso de construir herramientas a ejecutar intrusiones. Los registros de los operadores contenían además pulsaciones en cirílico que corresponden a ps y ls tecleados con una distribución rusa, de donde Sophos deduce que son rusoparlantes.

De un laboratorio de evasión de EDR al Cobalt Strike de Aur0ra

La historia no empieza en agosto. Sophos sitúa en mayo de 2026 un informe de su Counter Threat Unit sobre un framework de postexplotación asistido por IA que probaba los EDR de varios fabricantes, incluido el agente de Sophos. Su blog lo publicó el 2 de junio con el título «Pointing a Cursor at evading detection»: casi 80 módulos para probar más de 70 técnicas contra Sophos, CrowdStrike y Microsoft Defender, con Claude Opus 4.5 como agente coordinador, el Model Context Protocol para pasar tareas y commits a Git y Ludus para levantar las máquinas de prueba. Todo salió a la luz porque un endpoint de un cliente generó alertas por payloads en la ruta C:\Users\User\Documents\test.

Sophos X-Ops resumió aquel hallazgo en este episodio de The X-Ops Brief, en inglés, que explica cómo el actor convenció a modelos comerciales para que trabajaran para él y montó una especie de empresa de agentes que diseñaba, probaba y refinaba malware. Lo nuevo del informe de octubre es la conexión: los analistas observaron la misma infraestructura alojando Cobalt Strike en apoyo de operaciones de Aur0ra, con uso rutinario de Cobalt Strike para las intrusiones y de almacenamiento compatible con S3 para guardar lo robado. Sophos avisó a los clientes potencialmente afectados y trabajó con las fuerzas del orden para notificar a otras víctimas.

La tabla con la que Sophos compara el laboratorio y las operaciones de Aur0ra muestra casi la misma lista de herramientas y técnicas a ambos lados: planificación asistida por IA, ejecución de tareas por agentes, pivotaje SOCKS, enumeración LDAP, BloodHound, abuso de AD CS con Certipy, NTLM relay con PrinterBug y PetitPotam, Kerberoasting, AS-REP roasting, crackeo con hashcat y objetivos ESXi. Solo el despliegue del ransomware falta en el lado del laboratorio. La infraestructura compartida es mínima, una única IP de SOCKS (45.59.113.63) aparece en los dos, y por eso Sophos basa su valoración de alta confianza en las herramientas y no en las direcciones: GOLD OGRE usó IA para probar la evasión en un framework con Cursor y después cedió tecnología parecida a sus asociados para las operaciones de Aur0ra.

El directorio abierto de 172.86.113.245 que Gambit y CloudSEK leyeron en agosto

Sophos no fue el primero en mirar dentro de Aur0ra. El 27 de agosto de 2026, Gambit Security y CloudSEK publicaron sendos informes que, según Sophos, parecen basarse en el mismo directorio abierto en 172.86.113.245. CloudSEK lo describe como el directorio personal de Linux del operador, servido sin autenticación en el puerto 8888, con tickets Kerberos, volcados de SAM y LSA, exportaciones de directivas de grupo, colecciones de BloodHound, el historial de la shell, los registros de chat de Cursor y el propio cifrador.

La captura de CloudSEK del listado muestra las carpetas .cursor, .nxc (NetExec), .evil-winrm, .john y .msf4 una junto a otra, el equipo de trabajo completo de un afiliado. Hunt.io lo resumió en X el 28 de agosto: el agente de Cursor ayudó en la actividad posterior al compromiso dentro de las redes entre abril y mayo.

Gambit, en el informe firmado por Eyal Sela, su director de inteligencia de amenazas, cuenta diez organizaciones atacadas con Cursor Agent y el modelo claude-4.5-sonnet-thinking entre el 8 de abril y el 21 de mayo de 2026. Su gráfico de sesiones va de las 41 órdenes ejecutadas contra una aseguradora estadounidense el 8 de abril a las 581 contra un fabricante belga de bienes de consumo a finales de ese mes, con 532 órdenes repartidas en cinco sesiones contra una empresa británica de inspección. Al agente le tocaba instalar el cliente VPN o proxychains y conectarse con las credenciales recibidas, escanear subredes con Nmap o NetExec, enumerar el dominio con el colector de BloodHound, forzar autenticaciones con PetitPotam, Coerce Plus y PrinterBug para reenviarlas con ntlmrelayx y lanzar ataques de certificados con Certipy. No era infalible: «The majority of the commands failed to achieve the stated objective on the first attempt» (la mayoría de los comandos no lograron el objetivo al primer intento), y el operador iba corrigiendo.

El registro de chat que publica CloudSEK enseña cómo era ese diálogo. El operador escribe en ruso una sola línea, conéctate a la VPN, y el agente razona en voz alta, comprueba qué clientes hay con which openvpn openconnect vpnc, deduce por el formato de la URL que es un portal SSL VPN de Pulse Secure o Juniper e intenta la conexión con openconnect. En otros casos, según Gambit, el agente proponía una lista de pasos y el operador respondía con el número del que quería. Ese mismo operador repetía tres prohibiciones en cada víctima: nada de DCSync («dcsync делать категорически нельзя», hacer dcsync está terminantemente prohibido), nada de bloquear cuentas con los sprays de contraseñas y nada de añadir un equipo al dominio, tres cosas que un SOC detecta con facilidad.

CloudSEK amplía el recuento a más de veinte organizaciones en nueve países entre abril y julio de 2026, con acceso de dominio o interactivo en diecisiete y cuatro que acabaron en el sitio de filtraciones. Su gráfico de países reparte las 19 víctimas localizadas: seis en Estados Unidos, dos en Italia y dos en Australia, una en Alemania, Países Bajos, Bélgica, Argentina, México y Francia, y tres sin identificar. Ni una sola dirección ni dominio de la CEI aparece en tres meses de listas de objetivos, y CloudSEK valora con alta confianza que se trata de «a Russian-speaking Aurora affiliate operating directly, not a broker selling access onward» (un afiliado rusoparlante de Aurora que opera por su cuenta, no un intermediario que revende accesos).

España entra por un segundo grupo de actividad que Gambit atribuye a un operador de Aurora con confianza media, posiblemente distinto del anterior: ocho organizaciones víctimas en Israel, Alemania, Austria, España, Estados Unidos y Argentina, atacadas con xp_cmdshell en SQL Server, escalada a SYSTEM con GodPotato, DCSync y exfiltración con s5cmd a un almacenamiento S3 propio. Uno de los nodos de ese almacenamiento, 152.236.4.14, es la misma dirección que Sophos identifica en octubre como servidor de exfiltración de Aur0ra. En el momento de escribir esta noticia, el 2 de noviembre de 2026, ni INCIBE-CERT ni CCN-CERT han publicado aviso sobre Aur0ra y la víctima española no está identificada.

Zig, ESXi y un rescate de 900.000 en el panel de Aur0ra

El cifrador tiene dos caras compiladas desde un único código en Zig, un lenguaje poco habitual en malware: sap.exe para Windows y encrypt.out para Linux y ESXi. La versión Windows habilita privilegios de backup, borra las instantáneas de volumen, reduce el almacenamiento de sombra y desactiva Restaurar sistema desde el registro. La de ESXi, según el análisis de Gambit, cifra en el sitio con ChaCha20 y envuelve cada clave de sesión con una RSA-4096 embebida, lista con esxcli los World ID de las máquinas virtuales en ejecución, las mata una a una con esxcli vm process kill --type=force para liberar los bloqueos de los discos y respeta los volúmenes del sistema para que el hipervisor arranque y la víctima pueda leer la nota. Esa nota no se deja en un fichero: se escribe en /etc/ssh/sshd-banner y aparece antes del inicio de sesión a quien entre por SSH. Un módulo propio de NetExec, esxi_finder.py, localiza antes los hosts ESXi y los vCenter por los puertos 443 y 902.

Con las claves recuperadas del cifrador, CloudSEK entró en el panel de negociación. La captura muestra el final de una conversación: la víctima ofrece 750.000 como oferta final y el operador la rechaza, deja una cartera de bitcoin, exige 900.000 y cierra el hilo con la amenaza de publicar los datos el lunes. La cartera tenía 7 BTC en el momento del análisis. Con TRM Labs, CloudSEK siguió los pagos y encontró repartos entre afiliado y operador de 35/65, 21/79, 46/54 y 40/60, sin una proporción fija, y calcula que solo una de cada cinco víctimas confirmadas llega a la extorsión pública. Entre el acceso registrado y la aparición en el sitio de filtraciones pasaron 14 días en el caso más rápido y nunca más de un par de meses.

CloudSEK publica una regla Sigma experimental para auditd que detecta la entrega de la nota en ESXi por la combinación de tres acciones: editar sshd_config, crear un fichero llamado sshd-banner y reiniciar SSH desde init.d en la misma secuencia.

title: Aurora Locker - ESXi SSH Banner Ransom Note Delivery
status: experimental
logsource:
    product: linux
    service: auditd
detection:
    selection_config:
        CommandLine|contains: '/etc/ssh/sshd_config'
    selection_banner_file:
        CommandLine|contains: 'sshd-banner'
    selection_restart:
        CommandLine|contains|all: ['init.d', 'SSH', 'restart']
    condition: all of selection_*
level: critical

El cifrador Linux lleva también un vigilante de entropía que avisa si el pool del kernel está agotado antes de generar el material de cifrado, un detalle de autocrítica raro en este tipo de herramientas.

Indicadores que publican Sophos, Gambit y CloudSEK

Los tres informes coinciden en el directorio abierto y en parte de los pivotes SOCKS. Esta tabla reúne los indicadores de mayor confianza de cada uno, con los hashes de los dos cifradores y la infraestructura de mando y control de Cobalt Strike que solo da Sophos. Las listas completas, con los pivotes de confianza media de Gambit, están en los enlaces anteriores.

Sophos añade los nombres de sus contramedidas Taegis, que sirven de lista de comprobación en cualquier plataforma: túnel SOCKS con Chisel, enumeración de equipos por WMI, consultas LDAP de relaciones de confianza, Nmap, BloodHound, SharpShares, procesos de NetExec, ficheros de salida de Certipy, PetitPotam, scripts de Kerberoasting en PowerShell y los named pipes y el stager de Cobalt Strike. Son las señales que cualquier plataforma de simulación de brechas y ataques genera cuando se la deja correr, con la diferencia de que aquí el motor es un agente al que nadie ha dado alcance.

Qué revisar en un Active Directory antes de que lo recorra un agente

Sophos cierra con una frase que vale como diagnóstico: la IA «reduce the level of technical aptitude needed to conduct an attack» (reduce el nivel de aptitud técnica necesario para ejecutar un ataque). Las defensas que propone son las de siempre, con menos tiempo para aplicarlas. Con sus recomendaciones y las mitigaciones de CloudSEK, este es el orden de trabajo.

1. Busca las siete IP de Sophos y los hashes de sap.exe y encrypt.out en firewall, proxy y EDR, y en los registros de VPN las sesiones hacia los pivotes SOCKS de Gambit y CloudSEK. Una coincidencia con 152.236.4.14 en el puerto 54410 es tráfico de exfiltración con VeeamTransport hacia un bucket S3.
2. Quita los SPN de las cuentas privilegiadas, empezando por la cuenta Administrator integrada, y pasa las cuentas de servicio a gMSA. Es la medida que deja sin efecto el Kerberoasting que los agentes lanzan en cada entorno.
3. Audita las plantillas de AD CS contra ESC1, ESC6 y ESC8, retira el flag ENROLLEE_SUPPLIES_SUBJECT o exige aprobación del CA Manager, y activa la auditoría de solicitudes y emisión de certificados.
4. Desactiva LLMNR y NBT-NS, exige firma SMB y Extended Protection for Authentication, restringe WinRM a los hosts de administración y elimina SMBv1, en especial en los controladores de dominio. Sin eso, PetitPotam, PrinterBug y DFSCoerce siguen funcionando.
5. Si sospechas de compromiso del dominio, rota la contraseña de krbtgt dos veces con un intervalo completo de replicación entre ambas y alerta de cualquier ticket Kerberos cuya validez supere la directiva del dominio.
6. Aísla la infraestructura de backup, Veeam incluido, con credenciales y segmentos propios. La tercera orden del operador pide exactamente ese inventario, y CloudSEK observa credenciales de backup validadas como indicador previo al cifrado.
7. En ESXi, despliega la regla Sigma anterior, revisa que /etc/ssh/sshd-banner no exista y limita el acceso SSH a los hosts de gestión.
8. Revisa quién tiene privilegios de administrador de dominio, aplica gestión de accesos privilegiados y control de aplicaciones, y exige MFA resistente al phishing en VPN y accesos administrativos. Las empresas pueden notificar un incidente a INCIBE-CERT y las administraciones, al CCN-CERT.

El segundo punto se comprueba en un minuto con el módulo de Active Directory de PowerShell. Esta consulta lista las cuentas con SPN que pertenecen a grupos privilegiados.

Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties ServicePrincipalName, MemberOf, PasswordLastSet |
  Where-Object { $_.MemberOf -match "Domain Admins|Enterprise Admins|Administrators" } |
  Select-Object SamAccountName, PasswordLastSet, @{n="SPN";e={$_.ServicePrincipalName -join ", "}}

Son las cuentas que un Kerberoasting convierte en hashes crackeables, así que la lista que devuelve debería estar vacía. Cada cuenta que aparezca es un objetivo que el agente encontrará en su primera pasada de enumeración, porque la secuencia que CloudSEK observó en todas las víctimas empieza por LDAP, la directiva de contraseñas, AS-REP roasting y Kerberoasting, siempre en ese orden y con los mismos nombres de fichero de salida. Ese patrón repetitivo es, a la vez, su punto débil para quien practique la caza de amenazas con regularidad.

Esta noticia continúa el hilo que el blog abrió con el framework ARTEX de Storm-0940 y siguió con el exploit del kernel Linux escrito por un modelo de Anthropic en menos de una hora. Aur0ra aporta la pieza que faltaba, el uso cotidiano por parte de un afiliado de ransomware corriente, sin patrocinio estatal ni laboratorio propio. A nuestro juicio, el dato que más pesa del informe de Sophos es la frase sobre el cambio de proveedor y no el nombre de los modelos: pasaron de un proveedor a otros sin que el flujo de trabajo cambiara, y la historia del red team autorizado bastó para sortear las barreras. Las barreras de los proveedores ayudan, pero la defensa que no depende de ellas es la que se describe en la lista anterior. Lo que cabe esperar, y Sophos lo da por muy probable, es que otros grupos de ransomware incorporen agentes como Cursor en sus operaciones, y el aviso conjunto de FBI y CISA sobre SafePay ya mostraba que el acceso inicial con cuentas robadas de VPN sigue siendo la puerta más usada. Lo que el agente hace después de esa puerta tarda ahora minutos y no días, y el plazo de 14 días entre acceso y extorsión que midió CloudSEK es la referencia con la que conviene medir el tiempo de respuesta del propio SOC.