Puntos clave
- JadePuffer es el nombre que los investigadores de seguridad de Sysdig han dado a lo que, según su evaluación, es la primera operación de ransomware documentada dirigida de principio a fin por un agente de IA autónomo, y no por una persona que utilice un conjunto de herramientas.
- Las técnicas en sí no eran nuevas. Lo que cambió fue la velocidad de ejecución: el agente encadenó operaciones de reconocimiento, robo de credenciales, movimiento lateral y cifrado destructivo, corrigiendo un intento fallido de inicio de sesión en 31 segundos.
- El agente generó su propia clave de cifrado y nunca la guardó ni la transmitió. Pagar el rescate no habría permitido recuperar los datos.
- El daño real afectó al estado de la configuración y a los sistemas del plano de control, no solo a los archivos, que es precisamente la capa que la mayoría de los planes de recuperación no cubren.
- Recuperarse de un ataque como este significa demostrar que la empresa puede reanudar sus operaciones de forma segura, no solo restaurar una copia de seguridad.
¿Qué ocurrió?
A mediados de 2026, los investigadores de seguridad de Sysdig documentaron una campaña de extorsión que, según ellos, es la primera de este tipo: una operación de ransomware llevada a cabo de principio a fin por un agente basado en un modelo de lenguaje grande, con una intervención humana mínima. La llamaron JadePuffer.
El punto de entrada te sonaba. El atacante aprovechó el CVE-2025-3248, una vulnerabilidad de ejecución remota de código sin autenticación en Langflow —un marco de código abierto para crear flujos de trabajo de agentes de IA— que ejecutaba una versión anterior a la 1.3.0. A partir de ahí, el agente enumeró el host, buscó credenciales en proveedores de «cloud», proveedores de modelos de IA y bases de datos, y descargó discretamente la propia base de datos de copia de seguridad de la plataforma.
Lo que ocurrió a continuación es lo que merece especial atención. El agente escaneó la red interna, encontró un almacén de objetos expuesto y extrajo los archivos de estado y configuración de Terraform. Configuró una tarea programada para comunicarse con su base cada 30 minutos. A continuación, se trasladó a un sistema de producción independiente que ejecutaba MySQL y Alibaba Nacos, una plataforma de configuración y descubrimiento de servicios habitual en arquitecturas de microservicios.
Una vez dentro, el agente intentó crear una cuenta de administrador en Nacos. Falló. Treinta y un segundos después, ya había detectado el fallo y lo había solucionado con un método diferente. A continuación, utilizó las funciones de gestión de archivos de MySQL para comprobar si podía seguir avanzando, antes de cifrar más de 1.300 registros de configuración, eliminar las tablas originales y dejar una nota de rescate.
La clave de cifrado se generó sobre la marcha, se mostró una sola vez y nunca se guardó en ningún lugar donde el atacante pudiera recuperarla. Tanto si fue a propósito como si no, el resultado para la víctima es el mismo: no había forma de dar marcha atrás ni a través del atacante ni con una clave de descifrado, se pagara el rescate o no. La recuperación dependería de copias de seguridad limpias, de reconstruir el sistema o de puntos de recuperación validados.
¿Por qué los investigadores lo denominan «agéntico»?
Ninguna de las técnicas que se mencionan aquí es nueva. Aprovechar una vulnerabilidad CVE sin parchear, robar credenciales, buscar oportunidades de movimiento lateral, cifrar datos para extorsionar: los equipos de seguridad ya han visto todo esto antes. Lo que llevó a Sysdig a clasificar al operador como «agente» en lugar de como un atacante convencional es cómo encajan todos los pasos entre sí.
El agente no seguía un guion fijo. Analizaba los resultados y se adaptaba. Cuando esperaba una respuesta JSON y recibía XML, cambiaba de estrategia y seguía adelante. Cuando falló su primer intento de crear una cuenta de administrador, identificó el error concreto y probó otra cosa, todo ello en menos de un minuto.
Los investigadores también encontraron comentarios integrados en las cargas útiles, en los que se explicaban los objetivos y los siguientes pasos en un lenguaje sencillo, un patrón que se ajusta más al razonamiento de un modelo de lenguaje grande (LLM) al realizar una tarea que al de un humano que copia y pega un kit de exploits conocido. La información pública no ha confirmado qué modelo o «plataforma» estuvo detrás del ataque. Lo que sí está claro es el comportamiento: algo que razonó, actuó, se topó con un obstáculo y corrigió el rumbo más rápido de lo que tardan la mayoría de las respuestas a incidentes llevadas a cabo por personas.
El problema de la recuperación que muchos marcos de trabajo siguen sin abordar
La mayoría de las estrategias de los programas de ransomware se basan en una suposición concreta: algo ha cifrado tus archivos, y la cuestión es si puedes recuperar una copia de seguridad limpia o si tienes que negociar una clave de descifrado.
JadePuffer rompe esa suposición de dos maneras. En primer lugar, no había ninguna clave de descifrado por la que negociar. En segundo lugar, el daño no se limitaba a los datos. Afectaba a la capa de configuración y al plano de control subyacentes a los datos: la plataforma de descubrimiento de servicios, los secretos que contenía, el estado de Terraform que describía cómo encajaba la infraestructura y las credenciales dispersas por todos los sistemas con los que el agente entró en contacto por el camino.
Ese es un problema de recuperación más complicado que «restaurar la base de datos». Una restauración limpia de archivos en un entorno con credenciales renovadas pero sin verificar, desviaciones de configuración sin revisar y una capa de identidad que nadie ha vuelto a auditar no es realmente una recuperación limpia. Es una nueva copia de los datos dentro de un sistema en el que todavía no se puede confiar.
¿Qué significa esto para tu estrategia de resiliencia?
JadePuffer es un anticipo de la pregunta que, tarde o temprano, todo plan de recuperación tendrá que responder: ¿Se pueden reanudar las operaciones cuando un atacante ha afectado no solo a tus datos, sino también a la identidad, la configuración y los sistemas del plano de control de los que dependen esos datos?
Algunos puntos por donde empezar:
Trata los sistemas de configuración y del plano de control como elementos críticos para la Recovery, no solo las aplicaciones. Las plataformas de descubrimiento de servicios, los almacenes de secretos y el estado de la infraestructura como código son tan críticos para el negocio como las bases de datos que configuran. Si aún no figuran en tu plan de Recovery, esa es la primera laguna que debes subsanar.
Incorpora la gestión de credenciales en el proceso de recuperación, no después de este. Restaurar una carga de trabajo que vuelve a introducir claves comprometidas no pone fin al incidente; lo que hace es reiniciar el contador. Esta es la misma disciplina que Commvault aplica hoy en día a la infraestructura de identidades: evaluación de vulnerabilidades para detectar la exposición antes de que lo haga un atacante, auditoría en tiempo real para detectar los cambios en cuanto se producen y reversión para deshacer los cambios no autorizados sin tener que reconstruirlo todo desde cero.
Comprueba que todo esté en orden antes de restaurar, no después. Un punto de restauración solo sirve si sabes que está limpio. Esa es la lógica que hay detrás de Commvault Cleanroom™: comprobar y validar los datos en un entorno aislado antes de que vuelvan a entrar en producción, en lugar de darte cuenta después de que se hayan vuelto a infectar.
Prepárate para un ataque al plano de control, no solo para un caso de cifrado de archivos. Un plan de recuperación diseñado únicamente para «archivos cifrados, restauración desde copia de seguridad» no resistirá ante un incidente como este. La pregunta más útil, y la que constituye el núcleo de ResOps (operaciones de resiliencia) como disciplina operativa, es qué se necesita para alcanzar un nivel mínimo de operatividad cuando son los sistemas que sustentan tus aplicaciones los que han sido atacados.
Nada de esto significa que haya que considerar la IA agentiva como una amenaza sin precedentes que exija empezar de cero. Lo que hay que hacer es aplicar la misma disciplina de resiliencia que ya se utiliza para la identidad y los datos, pero llevándola hasta la capa de configuración y el plano de control, que es donde ahora los ataques agentivos apuntan directamente. Descubre más sobre cómo Commvault aborda la resiliencia de la identidad y la validación de una recuperación limpia.
Preguntas frecuentes
P: ¿Qué es JadePuffer? R: JadePuffer es el nombre que Sysdig dio a lo que consideró la primera campaña de ransomware documentada dirigida de principio a fin por un agente de IA autónomo, en lugar de por un atacante humano que utilizara manualmente un conjunto de herramientas.
P: ¿Utilizaron los atacantes algún modelo de IA concreto, como ChatGPT o Claude? R: La información publicada no ha confirmado qué modelo o «plataforma» se utilizó. El agente buscó claves API de varios proveedores de IA, lo que demuestra que había interés en ese tipo de acceso, pero no permite identificar qué fue lo que impulsó el ataque en sí. P: ¿Cómo comenzó el ataque?
R: A través de CVE-2025-3248, una vulnerabilidad de ejecución remota de código sin autenticación en Langflow, un marco de trabajo de código abierto para agentes de IA, que afecta a las versiones anteriores a la 1.3.0. P: ¿Podría haber pagado la víctima el rescate para recuperar sus datos? R: No. La clave de cifrado se generó sobre la marcha y nunca se guardó ni se transmitió, por lo que no había ninguna clave que se pudiera recuperar, independientemente del pago.
P: ¿En qué se diferencia esto del ransomware típico? R: Las técnicas en sí no eran nuevas. Lo que llamó la atención fue la velocidad y la capacidad de adaptación: el agente detectó un intento fallido de inicio de sesión y lo corrigió en 31 segundos, un ritmo más propio de una máquina que del comportamiento típico de un atacante humano. P: ¿Qué deberían aprender de esto los equipos de seguridad y recuperación?
R: Esa planificación de la recuperación tiene que ir más allá de los datos de las aplicaciones y abarcar los almacenes de configuración, las plataformas de detección de servicios, los secretos y los sistemas de identidad, que es precisamente la capa a la que JadePuffer se dirigió para causar el máximo daño. Chris Bevil es director de marketing de cartera en Commvault.