El atacante de 31 segundos: qué significa para la recuperación el primer ataque de ransomware autónomo

Cuando el atacante dejó de necesitar a un humano

El 1 de julio de 2026, el Sysdig Threat Research Team publicó su análisis de una operación de ransomware a la que llamó JADEPUFFER. En palabras de Sysdig, se trata de "what we assess to be the first documented case of agentic ransomware: a complete extortion operation driven end-to-end by a large language model (LLM)" (lo que la firma considera el primer caso documentado de ransomware agéntico: una operación de extorsión completa dirigida de principio a fin por un modelo de lenguaje de gran tamaño, o LLM).

No es otra historia sobre correos de phishing redactados por IA o llamadas con voces falsificadas mediante deepfake. En los payloads que Sysdig capturó, el agente explotó una aplicación expuesta a Internet, recopiló credenciales, pasó a un segundo servidor, tomó el control de su servicio de configuración, cifró y eliminó datos y dejó una demanda de rescate. Cuando un paso fallaba, diagnosticaba el fallo y volvía a intentarlo sin esperar instrucciones.

En BackupSec creemos que JADEPUFFER importa menos como incidente aislado que como anticipo. Es uno de los primeros datos sobre una pregunta que toda arquitectura de backup y recuperación tendrá que responder tarde o temprano: ¿qué ocurre cuando el ciclo de decisión del otro lado se reduce de horas a segundos?

Dentro de la cadena de ataque de JADEPUFFER

A grandes rasgos, es una kill chain de la que los equipos de seguridad llevan años defendiéndose. Sysdig lo dice claramente: "None of the individual techniques were novel or sophisticated" (ninguna de las técnicas por separado era novedosa ni sofisticada). Lo nuevo fue quién las ejecutó. La secuencia siguiente sigue el informe de Sysdig:

1. Acceso inicial. El agente explotó CVE-2025-3248 en Langflow, un framework de código abierto para crear aplicaciones basadas en LLM. NVD la describe como una inyección de código en el endpoint /api/v1/validate/code que permite a "a remote and unauthenticated attacker" (un atacante remoto y no autenticado) ejecutar código arbitrario, y le asigna una puntuación CVSS de 9,8. La corrección llegó en Langflow 1.3.0 el 31 de marzo de 2025, y CISA incorporó la vulnerabilidad a su catálogo Known Exploited Vulnerabilities el 5 de mayo de 2025. El parche existía; no se había aplicado.
2. Recolección de credenciales. En el host de Langflow, el agente enumeró el sistema y rastreó el entorno en busca de claves de API de proveedores de LLM, credenciales de nube, monederos de criptomonedas y credenciales de bases de datos, y después volcó la propia base de datos Postgres de Langflow. Encontró un almacén de objetos MinIO accesible desde el host, inició sesión con las credenciales predeterminadas de MinIO (minioadmin:minioadmin) y listó buckets que, según Sysdig, incluían "application data, backups, ML artifacts, and a terraform-state bucket" (datos de aplicaciones, copias de seguridad, artefactos de ML y un bucket de estado de Terraform). De uno de ellos extrajo un archivo credentials.json que contenía un par de clave de acceso y secreto.
3. Persistencia. Instaló una entrada de crontab en el host de Langflow que envía una señal a la infraestructura del atacante cada 30 minutos.
4. Salto al objetivo real. Según Sysdig, el verdadero objetivo de la operación era un servidor de producción independiente, expuesto a Internet, que ejecutaba MySQL y un servicio de configuración Alibaba Nacos. El agente se conectó como root al puerto de MySQL expuesto. Sysdig no observó de dónde procedían esas credenciales de root: "Their origin is unknown" (su origen es desconocido).
5. Toma de control de Nacos. El agente atacó Nacos por varias vías a la vez: la familia de omisión de autenticación de CVE-2021-29441 (según NVD, en las versiones de Nacos anteriores a la 1.4.1 el filtro de autenticación puede eludirse con una cabecera user-agent falsificada), un JSON Web Token falsificado con la clave de firma predeterminada de Nacos, que está documentada públicamente, y una cuenta de administrador con puerta trasera escrita directamente en la base de datos de Nacos gracias a su acceso root. La vía del JWT fracasó ("custom secret in use", es decir, había un secreto personalizado en uso) y fue abandonada. La cuenta con puerta trasera funcionó, tras la corrección de 31 segundos que se describe más abajo.
6. Impacto. El agente cifró los 1.342 elementos de configuración de Nacos con la función AES_ENCRYPT() de MySQL, eliminó las tablas originales de configuración y de historial, y a continuación eliminó esquemas de base de datos completos. La nota de rescate afirma que se usó AES-256; Sysdig señala que AES_ENCRYPT() utiliza por defecto AES-128-ECB salvo que el servidor se haya reconfigurado. El detalle que más importa para la recuperación: la clave se imprimió una sola vez y nunca se guardó ni se envió, de modo que, en palabras de Sysdig, "The victim cannot recover the encrypted configurations even with payment" (la víctima no puede recuperar las configuraciones cifradas ni siquiera pagando). Solo una copia tomada antes del ataque, y mantenida fuera del alcance del atacante, podría devolver esos datos.
7. Extorsión. Creó una tabla README_RANSOM con la demanda, una dirección de Bitcoin y un contacto de Proton Mail.

La advertencia honesta

Queremos ser precisos sobre lo que significa aquí "autónomo", porque exagerarlo debilitaría el argumento que vamos a exponer.

Sysdig menciona dos cosas que no puede ver. No observó cómo obtuvo el agente las credenciales de root de MySQL que usó en el paso cuatro. Y, según sus propias palabras, tiene "no visibility into JADEPUFFER's system prompt or agent configuration" (ninguna visibilidad sobre el prompt de sistema ni la configuración del agente de JADEPUFFER), así que no puede decir qué objetivo o qué recursos le dio una persona al agente antes de ejecutarlo. Alguien lo construyó, lo configuró y lo lanzó.

Lo que Sysdig sí documenta es el comportamiento dentro de las sesiones que capturó: más de 600 payloads distintos, código que narra su propio razonamiento y fallos diagnosticados y corregidos en segundos. Con esas pruebas concluye que "the evidence points to an autonomous agent driving the operation rather than a human operator or a fixed toolkit" (las pruebas apuntan a un agente autónomo al mando de la operación, y no a un operador humano o a un conjunto fijo de herramientas).

Esa distinción importa, y creemos que refuerza el argumento en lugar de debilitarlo. Incluso una cadena en la que una persona fija el objetivo y el agente se encarga de la ejecución elimina la mayor fuente de latencia de una operación de ransomware tradicional: el tiempo que un operador humano dedica a pensar, a consultar con quien lo dirige y a decidir qué intentar a continuación.

Por qué 31 segundos importan más de lo que parece

Los 31 segundos no son la duración total del ataque. Sysdig no publica una duración de principio a fin para la cadena, y no vamos a inventarnos una. Lo que sí publica es una secuencia con marcas de tiempo de la toma de control de Nacos. El agente insertó su cuenta de administrador con puerta trasera, intentó iniciar sesión a las 19:34:36 UTC y falló. Probó en paralelo dos posibles causas y, a las 19:35:07, lanzó un payload correctivo de 15 líneas que reconstruyó la cuenta correctamente. El inicio de sesión se completó a las 19:35:18. En palabras de Sysdig: "The window between the failed login and the correct multi-step fix is 31 seconds" (el intervalo entre el inicio de sesión fallido y la corrección correcta de varios pasos es de 31 segundos). Sysdig informa del mismo patrón en otros puntos de la sesión. Cuando una petición devolvió XML en lugar de JSON, el siguiente payload analizó XML. Cuando un DROP DATABASE falló por una restricción de clave externa, el siguiente desactivó primero esa comprobación.

Compárelo con lo que hace un operador humano cuando falla un paso. Se detiene. Vuelve a evaluar. En una operación estructurada de ransomware como servicio, puede que envíe un mensaje a quien lo dirige y espere instrucciones. Lo vuelve a intentar en plazos de minutos u horas, a veces con un cambio de turno de por medio. Esa latencia, el hueco entre un fallo y el siguiente intento, siempre ha sido una de las pocas cosas que jugaban a favor de los defensores. Es la razón por la que una alerta de las 2 de la madrugada todavía puede revisarla una persona a las 8 de la mañana sin que el incidente se haya agravado necesariamente de forma drástica entretanto.

Un agente que reduce ese hueco a 31 segundos no solo va más rápido. Elimina la suposición implícita en casi todos los runbooks de respuesta a incidentes: que existe una ventana a escala humana entre el primer intento fallido de un atacante y el siguiente, y que un proceso de detección y respuesta que opera a una escala de tiempo humana similar puede esperar razonablemente intervenir dentro de ella.

Las cifras que ya eran ciertas antes de que llegara la IA

La infraestructura de backup no se convirtió en objetivo por culpa de la IA agéntica. Ya lo era, y los datos al respecto son dos años anteriores a JADEPUFFER.

• El 2024 Ransomware Trends Report de Veeam, una encuesta a 1.200 participantes de organizaciones que sufrieron al menos un ataque de ransomware en 2023, concluyó que "backup repositories are targeted in 96% of attacks, with bad actors successfully affecting the backup repositories in 76% of cases" (los repositorios de backup son objetivo en el 96 % de los ataques, y los atacantes consiguen afectarlos en el 76 % de los casos). Veeam repite la cifra del 96 % en su propio blog.
• La investigación de Sophos de 2024 sobre copias de seguridad comprometidas, basada en 2.974 profesionales de TI y ciberseguridad cuyas organizaciones habían sufrido un ataque de ransomware el año anterior, concluyó que "The median overall ransomware recovery costs for organizations whose backups were compromised ($3M) came in eight times higher than that of organizations whose backups were not impacted ($375K)" (la mediana del costo total de recuperación de las organizaciones cuyas copias de seguridad se vieron comprometidas, 3 millones de dólares, fue ocho veces superior a la de las organizaciones cuyas copias no se vieron afectadas, 375.000 dólares).

Esas cifras describen un mundo de atacantes humanos que ya entendían que destruir o cifrar la capa de backup es la jugada de mayor impacto disponible una vez que una operación de ransomware se afianza. Nada de la IA agéntica cambia ese cálculo. Lo que cambia es quién, o qué, puede ejecutarlo a escala, a todas horas, sin necesidad de dormir, hacer un descanso entre turnos ni esperar la aprobación de quien lo dirige antes de probar la siguiente credencial.

El 2026 X-Force Threat Intelligence Index de IBM añade la tendencia. IBM X-Force observó un aumento del 44 % en los ataques que comenzaron con la explotación de aplicaciones expuestas públicamente, que es exactamente el vector de entrada que usó JADEPUFFER, y los grupos activos de ransomware y extorsión crecieron un 49 % interanual. La superficie de ataque ya estaba creciendo antes de que nada de esto necesitara un operador autónomo.

De las ventanas de detección a la certeza de recuperación

Explotar una vulnerabilidad conocida ya es la vía de entrada más habitual. El mismo informe de IBM dice que la explotación de vulnerabilidades "became the leading cause of attacks, accounting for 40% of incidents observed by X-Force in 2025" (se convirtió en la principal causa de los ataques y representó el 40 % de los incidentes observados por X-Force en 2025). La brecha entre las vulnerabilidades conocidas y las cerradas es demasiado grande, y se renueva de forma demasiado continua, como para que la prevención perfecta sea realista. JADEPUFFER encaja en el patrón: Sysdig señala que el ataque contra el objetivo real "leaned on years-old issues, a 2021 Nacos auth-bypass and an unchanged default signing key" (se apoyó en problemas de hace años: una omisión de autenticación de Nacos de 2021 y una clave de firma predeterminada que nadie cambió). JADEPUFFER no cambia ese argumento. Lo hace más evidente.

Si la suposición de trabajo del sector ha sido que un proceso de detección y respuesta a ritmo humano puede esperar razonablemente detectar una intrusión en algún punto entre el acceso inicial y el impacto irreversible, un agente que se autocorrige en 31 segundos cuestiona directamente esa suposición. La respuesta no puede ser "detectar y responder más rápido que una máquina", porque esa no es una carrera que los defensores puedan esperar seguir ganando indefinidamente. La respuesta tiene que ser arquitectónica: hacer que se pueda sobrevivir al resultado de una intrusión rápida y adaptativa, por mucho más rápido que llegue a ser el atacante.

En concreto, las propiedades que importan en la infraestructura de backup y recuperación no cambian porque el atacante sea un agente de IA en lugar de una persona. Pasan de ser aspiraciones a ser innegociables:

• Separación de credenciales e identidades que no dependa de que una persona detecte a tiempo una actividad inusual. Si las credenciales que dan acceso a su entorno de backup son las mismas que un agente puede recopilar en segundos de un host comprometido, el aislamiento tiene que ser estructural, no procedimental.
• Inmutabilidad validada, no solo configurada. Un bloqueo de retención que una credencial con suficientes privilegios puede desactivar sin hacer ruido es un control que da por hecho que un atacante humano dudará. Un agente no dudará.
• Pruebas de recuperación que asuman que el atacante ya conoce su entorno. El agente de JADEPUFFER se adaptó en tiempo real a los pasos fallidos. Un plan de recuperación que solo se ha probado frente a un único escenario de fallo previsto es un plan pensado para un adversario más lento y más predecible que el que ahora se ha demostrado posible.

Qué significa esto para los responsables de riesgo empresarial

JADEPUFFER es una campaña documentada, no una prueba de que todas las operaciones de ransomware sean ya autónomas. Pero si la evaluación de Sysdig se sostiene, algo que antes era teórico ya se ha observado: un agente LLM ejecutando una cadena de ataque real contra un objetivo real, con un ciclo de autocorrección medido en segundos.

Para los responsables de riesgo, la pregunta práctica ya no es si el ransomware agéntico será más común. Sysdig dice que los defensores "should expect the volume and breadth of such campaigns to rise as agentic tooling matures" (deben esperar que el volumen y el alcance de este tipo de campañas aumenten a medida que maduren las herramientas agénticas), e IBM X-Force "expects adversaries to automate complex tasks like reconnaissance and advanced ransomware attacks" (espera que los adversarios automaticen tareas complejas como el reconocimiento y los ataques avanzados de ransomware). La pregunta práctica es si las suposiciones de su arquitectura de recuperación se construyeron para un adversario a ritmo humano o para uno que ya no necesita serlo.

El papel de BackupSec

En BackupSec construimos nuestro enfoque sobre una premisa que JADEPUFFER hace más urgente: la prevención fallará, y la capa que decide el resultado es la que está construida para sobrevivir a ese fallo, por muy rápido que se moviera lo que lo causó.

• ZeroMON monitorea Veeam Backup & Replication. Se despliega on-premises como OVA, se conecta con una cuenta de solo lectura y no envía nada a BackupSec ni a terceros. Supervisa el estado de los trabajos de backup, registra los cambios de configuración en Veeam (quién cambió qué y cuándo), muestra el estado de inmutabilidad tal como lo indica la propia configuración de repositorios de Veeam y mantiene a la vista la lista de comprobación del Security Analyzer de Veeam. Sus reglas de alerta cubren los movimientos que un intruso hace en el lado de Veeam contra las copias de seguridad, como cambios de credenciales, modificaciones de retención y de programación, trabajos deshabilitados y sesiones de eliminación. Las alertas se envían por correo electrónico y como notificación dentro de la aplicación. ZeroMON vigila Veeam: no ve la recolección de credenciales en otros hosts, y lee la configuración de inmutabilidad de Veeam en lugar de comprobar los bloqueos en el propio almacenamiento.
• ZeroTAM ofrece a su equipo un asesor dedicado de seguridad de backup: revisión de arquitectura, planificación de la recuperación ante ransomware, capacidad y soporte prioritario en caso de crisis. Es el lugar para poner a prueba si su separación de identidades, su inmutabilidad y su aislamiento se diseñaron para un atacante a ritmo humano.
• ZeroPEN es una prueba de penetración guiada por amenazas de Veeam Backup & Replication, Veeam ONE y Enterprise Manager. Simula una kill chain de ransomware en ocho fases alineadas con MITRE ATT&CK, desde el acceso inicial y el abuso de credenciales, pasando por el acceso a repositorios y la neutralización de las copias de seguridad, hasta una prueba de capacidad de cifrado. El servicio incluye la verificación de la integridad de la restauración y de la inmutabilidad, y entrega evidencias listas para auditoría con una nueva prueba para los hallazgos críticos. No es destructivo: ZeroPEN "never deletes real backups, performs real encryption, or stops production or backup services" (nunca elimina copias de seguridad reales, no realiza cifrado real ni detiene servicios de producción o de backup).

La pregunta que plantea JADEPUFFER no es si sus defensas son rápidas. Es si su arquitectura de recuperación se construyó de forma que no dependa de que lo sean.

Hable con BackupSec sobre cómo validar su arquitectura de recuperación →

Este análisis se basa en la investigación de Sysdig de julio de 2026 sobre JADEPUFFER, el 2026 X-Force Threat Intelligence Index de IBM, el 2024 Ransomware Trends Report de Veeam y la investigación de Sophos de 2024 sobre copias de seguridad comprometidas, con detalles de las vulnerabilidades procedentes de NVD y CISA. La interpretación y el marco que se presentan aquí son de BackupSec. Para hablar de cómo se aplica este análisis a su entorno concreto, póngase en contacto con nuestro equipo →