El primer ransomware delegado 100% a agentes de IA tardó menos de 10 horas en comprometer una red empresarial — y le dejó una auditoría de 80 páginas a la víctima

Durante años, el consenso en ciberseguridad fue que los ataques de ransomware sofisticados requerían tiempo: semanas de reconocimiento, movimiento lateral cuidadoso, persistencia. Un ataque bien ejecutado contra una empresa mediana tardaba típicamente entre dos y tres semanas desde el primer punto de acceso hasta el cifrado final. Eso también era una limitación —la ventana daba tiempo a que un SOC activo detectara la intrusión antes del daño irreversible.

Ese margen ya no existe. El equipo de amenazas Unit 42 de Palo Alto Networks documentó un ataque donde el operador humano no ejecutó ningún paso técnico directamente: los delegó todos a agentes de IA que usaban modelos de lenguaje frontier. El tiempo total desde la entrada hasta el cifrado completo de la red: menos de 10 horas.

Qué hicieron los agentes, paso a paso

El detalle que hace este caso notable no es solo la velocidad —es que los agentes no fueron herramientas auxiliares que aceleraron a un humano. El humano definió el objetivo, y los agentes ejecutaron de forma autónoma cada etapa de la cadena de ataque: reconocimiento de la red, identificación y explotación de vulnerabilidades, movimiento lateral entre sistemas, exfiltración de datos sensibles, y finalmente el despliegue del ransomware.

Según el reporte de Unit 42, el atacante usó marcos de agentes abiertos para orquestar los modelos. Cada agente tenía acceso a herramientas concretas —escáneres de red, exploits conocidos, comandos de shell— y los modelos de lenguaje tomaban decisiones en tiempo real sobre qué paso dar después según lo que encontraban. No era un script pregrabado: era razonamiento adaptativo sobre el estado actual del sistema comprometido.

Los 80 páginas que le dejaron a la víctima

El detalle más bizarro del caso es lo que pasó al final. Una vez completado el cifrado, los agentes generaron automáticamente y entregaron a la víctima una auditoría de seguridad de 80 páginas documentando en detalle cada vulnerabilidad que habían explotado, cada configuración incorrecta que encontraron y cada movimiento que realizaron dentro de la red.

El atacante, al negociar el rescate, mencionó directamente haber usado modelos de IA y marcos de agentes. La auditoría era parte del mensaje: "sabemos exactamente qué tan roto estás, y este documento lo prueba". Es una inversión retorcida del red teaming —las mismas técnicas que las empresas de seguridad venden para encontrar fallas antes de que lo haga un atacante, ahora como herramienta de presión en una negociación de rescate.

Por qué la velocidad cambia el cálculo de defensa

Dos semanas de intrusión activa es un tiempo en el que un equipo de seguridad con monitoreo básico puede detectar comportamiento anómalo, contener el movimiento lateral y aislar sistemas antes de llegar al cifrado. La mayoría de los planes de respuesta a incidentes asumen ese margen como parte de su modelo.

Menos de 10 horas comprime ese modelo a la nada. Desde las primeras conexiones anómalas hasta el cifrado completo, no hay margen para que una persona revise alertas al día siguiente. La única respuesta posible es detección y contención automática en tiempo real —o no hay respuesta.

Esto no es un problema exclusivo de empresas grandes. Cualquier servidor expuesto a internet con credenciales débiles, software sin parchear o configuraciones por defecto es un objetivo posible. La velocidad de los agentes no discrimina por tamaño de víctima.

Lo que cambió y lo que no

Lo que cambió: el costo de entrada para ejecutar un ataque sofisticado cayó a prácticamente cero en términos de habilidad técnica. El atacante de este caso no necesitaba saber usar las herramientas —los agentes lo hacían. Solo necesitaba saber delegar.

Lo que no cambió: las fallas que los agentes explotaron eran las mismas de siempre. Vulnerabilidades conocidas sin parchear, contraseñas débiles, servicios expuestos sin razón. Los agentes son más rápidos, pero siguen entrando por las mismas puertas que llevan abiertas años.

Para cualquier equipo que administra servidores, la implicación es directa: el modelo de "parcheo eventual" y "revisión mensual de alertas" ya no es suficiente. No porque antes fuera ideal —nunca lo fue— sino porque el margen de error que cubría ese modelo acaba de desaparecer.

Si querés que tu infraestructura sea el objetivo menos rentable para un ataque de este tipo, el punto de partida sigue siendo el mismo: superficie de ataque mínima, parches al día, y sin servicios expuestos que no necesiten estarlo. Un VPS o servidor dedicado bien configurado es la base —lo que pasa encima es tu responsabilidad, pero la base tiene que ser sólida.