El equipo de investigación de amenazas de Sysdig ha documentado lo que describe como uno de los primeros casos claros de ransomware agéntico: una operación de extorsión en la que un modelo de lenguaje dirigió el ataque de extremo a extremo, sin depender de una persona al teclado en cada paso ni de un script fijo que simplemente ejecutara una secuencia predefinida.
El operador fue bautizado como JADEPUFFER. Según la investigación publicada el 1 de julio de 2026, el agente encadenó todo el ciclo de intrusión: entrada inicial por una vulnerabilidad conocida, enumeración del entorno, búsqueda de credenciales, acceso a sistemas internos, persistencia, compromiso del objetivo real, cifrado de configuraciones de producción, borrado de tablas y nota de rescate.
La lección no es que haya aparecido una técnica revolucionaria.
La lección es más incómoda: el nivel de habilidad necesario para lanzar un ataque completo baja cuando un agente puede probar, corregir y encadenar pasos por sí mismo.
Durante años, el ransomware ha tenido a una persona en el bucle: alguien ejecutando comandos, adaptando el ataque o escribiendo el malware que luego se automatiza. Lo que documenta Sysdig rompe parte de ese supuesto. No porque desaparezca el operador humano, sino porque el operador puede delegar mucha más ejecución táctica en un modelo.
No conviene leerlo como ciencia ficción ni como alarma de marketing. Es un aviso técnico verificable, con indicadores de compromiso publicados, que debe interpretarse en clave defensiva.
Y el mensaje para empresas es claro: los agentes no necesitan zero-days para hacer daño. Les basta con encontrar lo que ya estaba expuesto, mal parcheado o lleno de secretos.
Resumen ejecutivo: qué debería preocupar a una empresa
JADEPUFFER no cambia los fundamentos de la defensa. Los acelera.
La operación observada por Sysdig no dependió de técnicas exóticas. Se apoyó en piezas conocidas:
- Un servicio Langflow vulnerable y expuesto a Internet.
- Secretos y credenciales accesibles desde el entorno comprometido.
- Credenciales por defecto en almacenamiento de objetos.
- Un servicio de configuración Nacos alcanzable desde Internet.
- Una base de datos MySQL expuesta.
- Persistencia mediante una tarea programada.
- Falta de control de salida.
- Ausencia de detección temprana antes de la fase destructiva.
Lo nuevo es la forma de encadenarlo.
Un agente puede enumerar, probar, equivocarse, corregir y avanzar con una velocidad que cambia la economía del ataque. Eso hace que la cola larga de sistemas olvidados —paneles de administración, servicios internos publicados, servidores de IA, bases de datos, almacenes de configuración y credenciales por defecto— sea todavía más peligrosa.
Para empresas que ya usan IA, agentes, Langflow, MCP, servicios cloud o automatización interna, este caso conecta directamente con la seguridad de inteligencia artificial y con la auditoría de seguridad de agentes IA y MCP.
Qué observó Sysdig, a nivel conceptual
La operación se apoyó en algo muy común: infraestructura expuesta y descuidada.
El punto de entrada fue CVE-2025-3248, una vulnerabilidad crítica en Langflow, un marco de código abierto utilizado para construir aplicaciones y flujos con modelos de lenguaje. El fallo permite ejecución remota de código sin autenticación en versiones anteriores a 1.3.0.
La vulnerabilidad fue corregida en Langflow 1.3.0 y entró en el catálogo KEV de CISA en mayo de 2025, pero muchos servidores quedaron sin actualizar o directamente expuestos a Internet.
A partir de ahí, la mecánica fue la de una intrusión clásica.
El agente enumeró el sistema, buscó secretos en el entorno, localizó credenciales de proveedores de IA, claves de API, accesos a nube y credenciales de base de datos. También accedió a un almacén de objetos MinIO con credenciales por defecto y estableció persistencia mediante una tarea programada.
Después pivotó hacia el objetivo real: un servidor con una base de datos MySQL y un servicio de configuración Nacos expuestos.
Sobre ese entorno, el agente aprovechó debilidades conocidas de Nacos, creó una cuenta de administrador, cifró configuraciones de producción, eliminó las tablas originales y dejó una nota de rescate. Más tarde, la operación fue más allá y destruyó bases de datos completas.
No hace falta reproducir el ataque para entenderlo.
La pregunta defensiva no es “cómo se explota paso a paso”. La pregunta útil es otra: qué condiciones permitieron que un agente encadenara una intrusión completa sin que nadie lo detuviera antes de la destrucción.
El detalle que delata a la máquina
Sysdig sostiene que la operación fue dirigida por un modelo, y su análisis se apoya en varias señales.
La primera es llamativa: el propio código y las cargas útiles del ataque incluían comentarios en lenguaje natural que explicaban por qué se hacía cada paso. Un atacante humano no suele documentar así sus comandos de una línea durante una intrusión. Un modelo, en cambio, tiende a generar instrucciones explicadas, razonadas y comentadas.
La segunda señal es la velocidad de corrección. En una parte de la operación, el agente pasó de un intento fallido a una corrección funcional en cuestión de segundos, diagnosticando el problema y ajustando la estrategia en lugar de repetir a ciegas.
La tercera es la variedad de cargas útiles. Sysdig describe cientos de payloads distintos y orientados a propósito, más propios de una lógica que adapta la ejecución que de un script rígido.
La cuarta es casi irónica: la nota de rescate incluía una dirección de Bitcoin que coincide con una dirección de ejemplo ampliamente documentada en la literatura pública de Bitcoin. Además, la clave de cifrado se generó de forma aleatoria, se imprimió una sola vez y no se guardó ni se transmitió a ningún sitio.
Es decir: incluso pagando, la víctima no tendría una clave realista para recuperar los datos.
Esa es una diferencia importante frente al ransomware tradicional. En una operación de extorsión clásica, el atacante quiere cobrar. En una operación mal delegada en un agente, la fase destructiva puede ejecutarse sin que el operador haya diseñado bien la recuperación.
El resultado para la víctima es peor: no hay negociación útil, solo restauración.
No es una técnica nueva: es una nueva economía
JADEPUFFER no demuestra que las defensas clásicas ya no sirvan.
Demuestra que se vuelven más urgentes.
La operación no necesitó una vulnerabilidad desconocida. No necesitó romper criptografía. No necesitó una cadena sofisticada de zero-days. Se apoyó en exposición, falta de parcheo, credenciales mal protegidas, servicios internos publicados y ausencia de detección en tiempo de ejecución.
Eso cambia tres cosas para el defensor.
El coste de atacar baja
Si un agente puede encadenar reconocimiento, explotación, búsqueda de credenciales, movimiento lateral, persistencia y destrucción, el operador necesita menos habilidad táctica para lanzar una operación completa.
Eso no convierte a cualquiera en un actor avanzado. Pero sí reduce barreras.
La automatización ya no solo lanza un exploit conocido. Ahora puede decidir qué probar después, corregir errores y moverse hacia el objetivo real.
Las vulnerabilidades viejas ganan vida nueva
CVE-2025-3248 no era un zero-day cuando se usó en esta operación. Ya estaba documentada, parcheada e incluida en KEV.
Ese es el problema.
Un agente puede recorrer vulnerabilidades conocidas, paneles expuestos, claves por defecto y servicios olvidados a una escala que hace más peligrosa la deuda técnica. La cola larga de sistemas sin dueño se convierte en una superficie de ataque continua.
Aquí no basta con “pasar un escáner”. Hace falta gestión de vulnerabilidades con criterio de exposición, explotación real, criticidad y capacidad de respuesta.
La intención se vuelve más legible
Hay una oportunidad defensiva nueva: algunos modelos narran sus pasos.
Comentarios, nombres de funciones, cadenas explicativas y payloads excesivamente descriptivos pueden ayudar a detectar intención. No sustituyen la telemetría de proceso, red o base de datos, pero añaden señales útiles.
La pregunta no es solo qué comando se ejecutó. También puede ser qué estaba intentando hacer el agente.
Por qué Langflow, Nacos y MySQL importan en empresas reales
Este caso no va solo de Langflow.
Langflow es relevante porque muchas empresas están desplegando herramientas de orquestación de IA, flujos con LLM, APIs internas, agentes y conectores sin aplicarles la misma disciplina que a una aplicación crítica.
Nacos es relevante porque los servicios de configuración suelen contener llaves del reino: endpoints, credenciales, secretos, rutas internas, parámetros de producción y lógica de despliegue.
MySQL es relevante porque muchas organizaciones siguen exponiendo bases de datos, directa o indirectamente, por comodidad operativa, integraciones heredadas o errores de arquitectura.
La combinación es peligrosa:
- Un componente de IA expuesto.
- Secretos accesibles desde el entorno.
- Servicios de configuración mal endurecidos.
- Bases de datos con privilegios excesivos.
- Falta de segmentación.
- Sin control de salida.
- Sin alertas hasta que aparecen operaciones destructivas.
Esto no es un problema exclusivo de startups de IA. Afecta a cualquier empresa que esté incorporando agentes, automatizaciones o herramientas de IA sin revisar la superficie de ataque que está creando.
Una revisión pasiva inicial con Hard2bit Scanner o desde el scanner público de Hard2bit puede ayudar a detectar señales externas relevantes: subdominios olvidados, tecnologías expuestas, postura pública, cabeceras, certificados, exposición de almacenamiento, señales de cumplimiento y preparación frente a la era de agentes IA.
No sustituye una auditoría interna, pero sí ayuda a responder una pregunta básica: qué puede ver un atacante antes de tocar tu red.
Qué debería detectar un SOC antes del cifrado
La respuesta razonable no es solo parchear, aunque parchear sea imprescindible.
La respuesta correcta es asumir que un atacante puede convertir un aviso reciente o antiguo en una cadena funcional en horas, y desplazar parte del peso hacia detección de comportamiento.
Un SOC gestionado con telemetría suficiente habría tenido varias oportunidades de detectar la operación antes de la fase destructiva.
Algunas señales relevantes:
Procesos hijos anómalos lanzados desde un servicio web, una herramienta de orquestación de IA o un componente que normalmente no debería ejecutar shells, intérpretes o utilidades de red.
Lectura masiva o dirigida de ficheros sensibles, especialmente .env, credentials.json, claves de proveedores de IA, credenciales cloud, tokens de API o ficheros de configuración.
Accesos a almacenes de objetos con credenciales por defecto o desde orígenes que no coinciden con el patrón normal de la aplicación.
Creación de tareas programadas que realizan conexiones salientes periódicas, especialmente si nacen desde procesos que no suelen actuar como agentes de red.
Conexiones desde un servidor de IA o aplicación interna hacia destinos externos no habituales.
Acceso a servicios de configuración, consolas de administración o bases de datos desde sistemas que no deberían tener ese rol.
Operaciones destructivas sobre esquemas de base de datos, como eliminación de tablas, borrado de bases completas o creación de estructuras de rescate.
Cambios repentinos en configuraciones de producción sin despliegue asociado.
Estos indicadores no dependen de una firma concreta. Dependen de comportamiento, contexto y relaciones: qué proceso lanzó qué, contra qué destino, con qué usuario y en qué momento.
Eso es justo lo que aporta el threat hunting cuando se aplica bien: no esperar a que una alerta genérica dispare, sino buscar patrones compatibles con una intrusión real.
Indicadores de compromiso: útiles, pero insuficientes
Sysdig publicó indicadores de compromiso asociados a JADEPUFFER, como infraestructura de mando y control, dirección de cartera y artefactos de la nota de rescate.
Son útiles.
Pero no deberían ser la base única de la defensa.
Los IoC envejecen rápido. Un agente puede cambiar una IP, una ruta, un nombre de fichero o una cadena visible en cuestión de segundos. Lo más estable es el comportamiento: ejecución anómala desde servicios web, lectura de secretos, persistencia, conexiones salientes, uso indebido de credenciales, acceso a configuración y operaciones destructivas.
La defensa debería combinar ambos niveles:
Indicadores concretos para búsqueda rápida.
Detección de comportamiento para encontrar variantes.
Contexto de activos para priorizar qué sistemas importan.
Respuesta preparada para contener antes de la destrucción.
Ese enfoque encaja con una operación de EDR, XDR y MDR bien integrada con SIEM, registros de nube, bases de datos, contenedores y telemetría de aplicaciones.
Defensa práctica: lo que habría frenado a JADEPUFFER
Las medidas que habrían reducido el impacto de JADEPUFFER son conocidas. La dificultad está en aplicarlas sobre la infraestructura que muchas organizaciones no miran: servicios internos, herramientas de IA, almacenes de configuración, cuentas administrativas y bases de datos.
1. No expongas endpoints de ejecución de código
Langflow y herramientas similares deben tratarse como aplicaciones críticas, no como juguetes de laboratorio.
Si una herramienta puede ejecutar código, invocar conectores o manejar credenciales, no debe estar publicada sin controles fuertes.
Hay que revisar:
- Exposición a Internet.
- Autenticación.
- Actualización.
- Segmentación.
- Permisos del proceso.
- Variables de entorno.
- Conectores disponibles.
- Secretos accesibles.
- Registros generados.
- Conexiones de salida permitidas.
La auditoría de seguridad de agentes IA y MCP debe cubrir exactamente esto: qué puede hacer el agente, qué herramientas puede invocar, qué secretos toca y qué límites existen si se comporta mal o si un atacante lo usa como punto de entrada.
2. Saca los secretos del entorno de ejecución
Muchos servidores de IA y automatización guardan claves de proveedores, tokens cloud, credenciales de bases de datos y secretos internos junto al propio proceso.
Eso convierte una RCE en una fuga inmediata de credenciales.
Los secretos deben vivir en un gestor de secretos, con mínimo privilegio, rotación, trazabilidad y alcance limitado. Si un servicio solo necesita leer una cola o consultar una API, no debería tener credenciales de administración de nube ni acceso root a una base de datos.
Este punto conecta directamente con la seguridad de identidades no humanas: cuentas de servicio, tokens, API keys y credenciales máquina son objetivo prioritario para ataques automatizados.
3. Endurece servicios de configuración
Los servicios de configuración como Nacos son activos críticos.
No deberían estar expuestos a Internet, no deberían conservar claves de firma por defecto y no deberían conectarse a bases de datos con privilegios excesivos.
Una configuración de producción puede contener más valor que un documento confidencial: rutas internas, credenciales, servicios, feature flags, endpoints, integraciones y lógica de negocio.
Endurecerlos implica:
- Autenticación fuerte.
- Claves únicas.
- Segmentación.
- Control de administración.
- Logs centralizados.
- Revisión de cambios.
- Acceso mínimo a base de datos.
- Backups de configuración.
- Alertas ante modificación masiva.
4. No publiques bases de datos administrativas
Una base de datos de producción no debería ser accesible desde Internet salvo casos muy justificados y controlados.
Y, desde luego, una cuenta administrativa de base de datos no debería ser la credencial normal de una aplicación.
Hay que aplicar:
- Restricción por origen.
- Cuentas por función.
- Mínimo privilegio.
- Rotación de credenciales.
- Revisión de permisos.
- Alertas ante operaciones destructivas.
- Backups probados.
- Separación entre administración y ejecución.
5. Controla la salida
Muchas defensas se centran en impedir la entrada. JADEPUFFER recuerda que también importa controlar la salida.
Un servidor comprometido no debería poder balizar libremente a cualquier destino externo ni alcanzar cualquier base de datos o API.
El control de salida limita:
- Mando y control.
- Exfiltración.
- Descarga de payloads.
- Movimiento lateral.
- Uso indebido de credenciales.
- Comunicación con infraestructura atacante.
La regla práctica es sencilla: si un servidor no necesita hablar con Internet, no debería poder hacerlo. Y si necesita hacerlo, debería estar restringido por destino, puerto y finalidad.
6. Prueba la restauración
En este caso, la clave de cifrado no se guardó ni se transmitió correctamente. La negociación no era una salida realista.
Cuando el cifrado o borrado hace irrecuperables los datos, solo queda restaurar.
Por eso la defensa no termina en prevención. Necesita continuidad de negocio, copias protegidas, restauración probada y tiempos de recuperación realistas.
Un backup inmutable no es un adorno técnico. Es la diferencia entre reconstruir y negociar con alguien que quizá ni siquiera puede devolverte la clave.
Seguridad de agentes IA: el punto que muchas empresas aún no han resuelto
JADEPUFFER también deja una lectura para las empresas que están desplegando agentes IA internos.
La pregunta no es solo si el modelo responde bien.
La pregunta es qué puede hacer.
Un agente con acceso a herramientas internas, conectores, bases de datos, repositorios, sistemas de configuración o credenciales cloud se parece más a un operador técnico que a un chatbot.
Por eso necesita controles de producción:
- Identidad propia.
- Permisos mínimos.
- Registro de acciones.
- Límites de herramientas.
- Aprobación humana para acciones críticas.
- Entornos separados.
- Secretos fuera del prompt y del entorno directo.
- Observabilidad de llamadas.
- Kill switch.
- Revisión de conectores.
- Pruebas de abuso.
- Control de salida.
Este enfoque ya lo desarrollamos en seguridad en MCP y agentes IA empresariales: un conector mal gobernado equivale a abrir una API privilegiada a una lógica probabilística.
Si además esa arquitectura está expuesta a Internet o conserva secretos de producción, el riesgo deja de ser teórico.
Qué implica para NIS2, DORA y ENS
Para una organización sujeta a NIS2, un incidente como JADEPUFFER no es solo un problema técnico.
La destrucción de configuraciones de producción y datos puede afectar a continuidad, disponibilidad del servicio, integridad de sistemas y obligaciones de notificación. Además, obliga a demostrar gestión de vulnerabilidades, control de accesos, respuesta a incidentes y gobierno de la cadena tecnológica.
En el marco de DORA, el caso encaja directamente con resiliencia operativa digital: activos TIC, gestión de parches, dependencia tecnológica, pruebas de recuperación, monitorización y capacidad de respuesta.
Bajo el ENS, la lectura es igual de clara: inventario, control de configuración, protección de servicios, trazabilidad, gestión de cambios, copias de seguridad y respuesta ante incidentes.
La diferencia entre cumplir en papel y resistir un ataque está en la evidencia:
- Qué activos estaban expuestos.
- Qué versiones tenían.
- Qué credenciales existían.
- Qué logs se conservaron.
- Qué alertas saltaron.
- Cuándo se detectó.
- Qué datos se perdieron.
- Qué restauración se probó.
- Qué decisiones se tomaron.
Para organizaciones que cruzan varios marcos, conviene revisar cómo se relacionan ENS, ISO 27001, NIS2 y DORA, porque los controles se repiten: gobierno, inventario, vulnerabilidades, continuidad, detección, respuesta y mejora continua.
Qué debería revisar una empresa ahora
Después de JADEPUFFER, cualquier empresa que use herramientas de IA, agentes, automatización interna, servicios de configuración o bases de datos expuestas debería responder a estas preguntas:
¿Tenemos Langflow, Nacos, MinIO, bases de datos, paneles de administración o herramientas de IA expuestas a Internet?
¿Sabemos qué versiones ejecutan y quién es responsable de actualizarlas?
¿Tenemos activos internos publicados que no aparecen en el inventario oficial?
¿Hay credenciales de proveedores de IA, cloud o bases de datos dentro de variables de entorno o ficheros .env?
¿Usamos credenciales por defecto en almacenes de objetos, servicios internos o herramientas de configuración?
¿Pueden nuestros servidores de IA ejecutar código o invocar herramientas internas sin control?
¿Existe control de salida desde servidores internos hacia Internet?
¿Se alertan operaciones destructivas sobre bases de datos?
¿Tenemos backups inmutables y restauración probada?
¿El SOC ve procesos, conexiones, cambios de configuración y actividad de base de datos, o solo logs de perímetro?
¿Hemos probado qué pasaría si un agente o herramienta de IA se ve comprometida?
Estas preguntas pueden abordarse con una combinación de auditoría de seguridad informática, gestión de superficie de ataque, seguridad de inteligencia artificial y respuesta a incidentes preparada.
Como primer paso externo y no intrusivo, también puedes analizar tu dominio con Hard2bit Scanner para obtener una visión pasiva de postura pública, exposición, tecnologías, cabeceras, certificados, señales de cumplimiento, subdominios visibles y preparación frente a la era de agentes IA.
El aviso, en su justa medida
JADEPUFFER no es el fin del mundo.
Tampoco es una amenaza imparable.
Es una señal de hacia dónde se mueve la extorsión: menos dependencia de operadores expertos en cada paso, más delegación en agentes capaces de probar, corregir y encadenar técnicas conocidas.
Los fundamentos defensivos no han cambiado:
- Inventario real.
- Menos exposición.
- Parcheo basado en explotación.
- Secretos bien guardados.
- Mínimo privilegio.
- Segmentación.
- Control de salida.
- Detección en tiempo de ejecución.
- Backups que restauran de verdad.
- Respuesta preparada.
Lo que sí ha cambiado es la velocidad y el coste con que un atacante puede probar el catálogo contra tus sistemas más olvidados.
Conviene asumir que cualquier servidor expuesto, almacén de configuración, herramienta de IA, cuenta de administración o base de datos accesible va a ser sondeado por una máquina, no solo por una persona.
Y una máquina no se cansa.
¿Sabes qué puede ver y explotar un agente contra tu organización?
En Hard2bit ayudamos a empresas a reducir exposición, proteger sistemas de IA, monitorizar actividad real y responder ante incidentes antes de que una intrusión se convierta en destrucción de datos.
Podemos ayudarte con:
- Seguridad de inteligencia artificial
- Auditoría de seguridad de agentes IA y MCP
- Hard2bit Scanner
- Gestión de superficie de ataque
- Gestión de vulnerabilidades
- SOC gestionado
- Threat hunting
- Respuesta a incidentes
- Continuidad de negocio
- NIS2
- DORA
- ENS
Si quieres revisar tu exposición pública, puedes empezar con un análisis pasivo desde Hard2bit Scanner. Y si necesitas una evaluación más completa de agentes, servicios expuestos, secretos, cloud, bases de datos y detección, puedes contactar con nuestro equipo desde la página de contacto de Hard2bit.
Fuentes recomendadas
- Sysdig Threat Research Team: JADEPUFFER, Agentic ransomware for automated database extortion
https://www.sysdig.com/blog/jadepuffer-agentic-ransomware - CISA: CVE-2025-3248 added to the Known Exploited Vulnerabilities catalog
https://www.cisa.gov/news-events/alerts/2025/05/05/cisa-adds-one-known-exploited-vulnerability-catalog - NVD: CVE-2025-3248
https://nvd.nist.gov/vuln/detail/CVE-2025-3248 - INCIBE-CERT: CVE-2025-3248
https://www.incibe.es/incibe-cert/alerta-temprana/vulnerabilidades/cve-2025-3248 - NVD: CVE-2021-29441, Nacos authentication bypass
https://nvd.nist.gov/vuln/detail/CVE-2021-29441 - GitHub Advisory Database: CVE-2021-29441
https://github.com/advisories/GHSA-36hp-jr8h-556f