JadePuffer automatiza un ataque de ransomware con un agente de IA

Sysdig ha documentado una operación de extorsión en la que un agente basado en un modelo de lenguaje habría ejecutado casi todo el ataque sin intervención humana continua. La campaña, bautizada como JadePuffer, comenzó explotando una instancia vulnerable de Langflow y terminó con el cifrado y borrado de bases de datos de producción. El caso resulta relevante porque la IA no desarrolló técnicas nuevas: encadenó fallos conocidos, credenciales válidas y configuraciones inseguras con una velocidad difícil de igualar por un operador manual.

Las claves técnicas de JadePuffer en 20 segundos

  • Vector inicial: explotación de CVE-2025-3248 en una instancia de Langflow expuesta a internet.
  • Gravedad del fallo: ejecución remota de código Python sin autenticación en versiones anteriores a Langflow 1.3.0.
  • Comportamiento agéntico: el sistema analizaba errores, modificaba sus scripts y volvía a intentarlo sin esperar nuevas instrucciones.
  • Búsqueda de secretos: rastreó claves de proveedores de IA, credenciales cloud, accesos a bases de datos y carteras de criptomonedas.
  • Persistencia: añadió una tarea en crontab para comunicarse con la infraestructura del atacante cada 30 minutos.
  • Movimiento hacia producción: accedió a un servidor con MySQL y Nacos mediante credenciales de administrador.
  • Impacto: cifró 1.342 configuraciones de Nacos y eliminó tablas y esquemas completos.
  • Sin descifrado posible: la clave no quedó guardada ni llegó al atacante, por lo que pagar el rescate no habría servido para recuperar los datos.

JadePuffer no fue una inteligencia artificial buscando víctimas por iniciativa propia. Hubo una preparación humana previa: alguien seleccionó la infraestructura, creó el entorno de control y proporcionó parte de los accesos necesarios. A partir de ahí, el agente asumió buena parte de la ejecución, desde el reconocimiento hasta la destrucción de información.

Ese matiz no resta importancia al caso. Hasta ahora, buena parte del uso criminal de la IA se concentraba en redactar phishing, generar variantes de malware o ayudar a operadores poco experimentados. Aquí el modelo actuó como un ejecutor persistente capaz de observar el resultado de cada orden, corregir errores y elegir el siguiente paso.

Langflow fue la puerta de entrada

El acceso inicial se produjo a través de CVE-2025-3248, una vulnerabilidad crítica de Langflow que permite a un atacante remoto ejecutar código Python sin autenticarse.

Langflow es una plataforma visual para construir aplicaciones y flujos con modelos de lenguaje. Por su función suele ejecutarse cerca de credenciales especialmente sensibles: claves de API de OpenAI, Anthropic, Google, DeepSeek u otros proveedores, tokens cloud, conexiones a bases de datos y secretos utilizados por aplicaciones internas.

La vulnerabilidad afectaba a un endpoint relacionado con la validación de código. Un atacante podía enviar una solicitud manipulada y lograr que el servidor ejecutara Python. El fallo fue corregido en Langflow 1.3.0, pero la instancia analizada por Sysdig continuaba expuesta y sin actualizar.

Tras obtener ejecución remota, JadePuffer comenzó a recopilar información del sistema. Enumeró procesos, inspeccionó variables de entorno, revisó archivos de configuración y buscó patrones asociados con credenciales.

La búsqueda incluía proveedores occidentales y asiáticos. Además de AWS, Azure y Google Cloud, el agente rastreó accesos de Alibaba, Aliyun, Tencent y Huawei. También buscó claves para servicios de IA, credenciales de bases de datos y posibles monederos de criptomonedas.

El agente volcó la base PostgreSQL utilizada por Langflow, analizó su contenido y eliminó posteriormente parte de los archivos temporales. Después inició el reconocimiento de la red interna y trató de identificar almacenamiento, servicios de configuración y otros sistemas accesibles.

Para mantener el acceso añadió una entrada en crontab que se ejecutaba cada 30 minutos y conectaba con la infraestructura externa utilizada por el atacante.

Este tipo de persistencia no es sofisticado y puede detectarse con controles básicos sobre cambios en tareas programadas. Su valor para JadePuffer estaba en la rapidez: no necesitaba diseñar un mecanismo nuevo si uno convencional era suficiente.

El agente no seguía un script rígido

La parte más interesante de la investigación no se encuentra en las herramientas empleadas, sino en cómo respondía el sistema cuando algo fallaba.

Sysdig observó más de 600 cargas diferentes durante la operación. Muchas incluían comentarios y explicaciones en lenguaje natural sobre el objetivo del código, el valor de una base de datos o el motivo para seleccionar una ruta concreta.

Un operador humano puede documentar sus scripts, pero no suele añadir razonamientos detallados a cientos de cargas lanzadas durante un ataque. Ese estilo encaja mejor con código generado por un modelo de lenguaje que explica automáticamente lo que está haciendo.

El comportamiento también era adaptativo. Cuando una petición a MinIO devolvió XML en lugar del JSON esperado, JadePuffer modificó el analizador y repitió la operación. No se limitó a relanzar el mismo comando ni abandonó la tarea.

En otra secuencia intentó crear una cuenta administrativa en Nacos y falló por un problema relacionado con la generación de la contraseña. El agente probó alternativas, revisó las credenciales predeterminadas, corrigió el hash y logró iniciar sesión 31 segundos después del primer intento fallido.

Este ciclo de ejecución, observación y corrección es el elemento que diferencia a un agente de un conjunto tradicional de scripts. Un script puede incluir condiciones y reintentos, pero normalmente necesita que un desarrollador haya anticipado cada posible error. Un modelo puede interpretar una respuesta imprevista y generar una solución sobre la marcha.

La ventaja para un atacante es evidente. Un único operador podría lanzar varios agentes contra diferentes objetivos y dejar que cada uno resuelva problemas menores de forma autónoma. La persona intervendría solo cuando el sistema encontrara una barrera que no pudiera superar.

Nacos y MySQL estaban expuestos a internet

El servidor Langflow no era el objetivo final. JadePuffer avanzó hacia otra máquina de producción que ejecutaba MySQL y Nacos.

Nacos es una plataforma de código abierto creada por Alibaba para el descubrimiento de servicios y la gestión dinámica de configuraciones. Se utiliza en arquitecturas de microservicios para almacenar parámetros que pueden afectar al funcionamiento de múltiples aplicaciones.

El servidor MySQL aceptaba conexiones externas y el agente disponía de credenciales root. Sysdig no observó que estas credenciales fueran robadas durante la intrusión, por lo que no pudo determinar cómo habían llegado al atacante.

Una vez dentro, JadePuffer probó varias vías contra Nacos. Intentó aprovechar problemas de autenticación asociados a CVE-2021-29441, generó tokens JWT con una clave predeterminada conocida y modificó directamente las tablas internas para añadir un usuario administrador.

El acceso a la base de datos le permitía alterar el sistema por debajo de la aplicación. Aunque una vulnerabilidad web fallara, podía insertar datos directamente en el backend y construir una cuenta válida.

El agente también exploró posibles rutas para salir del contenedor o ejecutar código en el sistema anfitrión mediante funciones de MySQL. Revisó permisos, rutas internas, extensiones y la disponibilidad del socket de Docker.

No encontró una vía inmediata para ampliar ese acceso. En lugar de quedarse bloqueado, eliminó parte de los rastros y pasó a la fase destructiva.

El ransomware terminó funcionando como un wiper

JadePuffer utilizó la función AES_ENCRYPT() de MySQL para cifrar los 1.342 elementos de configuración almacenados en Nacos. Después borró las tablas originales y su historial y creó una nueva tabla con la nota de extorsión.

El mensaje aseguraba que la información había sido cifrada con AES-256 y proporcionaba una dirección de Bitcoin y una cuenta de Proton Mail.

Sysdig señaló que la configuración predeterminada de MySQL utiliza AES-128-ECB para esta función, salvo que el administrador haya modificado el modo de cifrado. La discrepancia puede indicar que el agente generó una nota de rescate genérica sin comprobar el comportamiento exacto del servidor.

El problema más grave para la víctima era otro: la clave se generó aleatoriamente, apareció una vez en la salida del agente y no quedó almacenada ni fue enviada a la infraestructura del atacante.

El operador no podía entregar una herramienta de descifrado porque tampoco disponía de la clave. Aunque la organización hubiera pagado, no habría podido restaurar las configuraciones.

La dirección de Bitcoin incluida en la nota también parece proceder de ejemplos públicos utilizados habitualmente en documentación. Los investigadores no pudieron confirmar que estuviera controlada por el atacante.

Después del cifrado, JadePuffer continuó eliminando información. Pasó de borrar filas y tablas a destruir esquemas completos de bases de datos. El propio código afirmaba que los datos habían sido exfiltrados previamente, pero Sysdig no pudo verificar que esa copia existiera.

En la práctica, el ataque terminó comportándose como un wiper: destruyó los datos y añadió una demanda económica sin disponer de un mecanismo real para recuperarlos.

Esta falta de coherencia muestra una limitación importante de los agentes ofensivos. Pueden ejecutar muchos pasos con rapidez, pero eso no significa que mantengan una estrategia fiable de principio a fin. El modelo cumplió la instrucción de cifrar y extorsionar, pero no protegió la clave necesaria para completar el proceso criminal.

Para la víctima la distinción es irrelevante. Un ransomware mal construido puede causar el mismo daño operativo que uno diseñado para permitir el descifrado.

Qué cambia para los equipos de seguridad

JadePuffer no utilizó un exploit desconocido, una técnica avanzada de evasión ni una cadena inédita de vulnerabilidades. Su éxito dependió de una instancia de Langflow sin parchear, servicios de producción expuestos a internet, claves predeterminadas y credenciales de administrador.

La novedad está en la velocidad con la que el agente combinó esos errores.

Los equipos defensivos suelen trabajar con la idea de que existe cierto intervalo entre el acceso inicial, el reconocimiento y la acción destructiva. En una operación automatizada ese margen puede reducirse de horas a minutos.

Las alertas aisladas también pierden valor cuando nadie las relaciona a tiempo. Una ejecución de Python en Langflow, una nueva tarea en crontab, un escaneo interno y varios intentos contra Nacos pueden parecer incidentes separados. Un agente puede completar toda la cadena antes de que un analista termine de revisar la primera señal.

La detección debe centrarse en comportamiento y secuencias. Algunos indicadores útiles serían:

  • Ejecución anómala de Python desde servicios de orquestación de IA.
  • Acceso masivo a variables de entorno y archivos con secretos.
  • Creación inesperada de tareas programadas.
  • Consultas de reconocimiento hacia múltiples servicios internos.
  • Generación repetida de scripts con pequeñas modificaciones.
  • Cambios directos en tablas de autenticación de Nacos.
  • Uso de funciones de cifrado sobre grandes volúmenes de datos.
  • Eliminación rápida de tablas o esquemas tras una fase de lectura.

La cadencia también puede revelar automatización. Un operador humano suele tardar más en analizar un error, corregir un script y volver a ejecutarlo. Decenas de variantes generadas en pocos segundos pueden indicar la presencia de un agente.

Estas señales no serán permanentes. Los atacantes aprenderán a introducir pausas, eliminar comentarios y reducir la verbosidad del código. Aun así, durante esta primera etapa ofrecen una oportunidad para diseñar reglas específicas.

Medidas inmediatas para Langflow, Nacos y bases de datos

Las organizaciones que utilicen Langflow deben actualizar como mínimo a la versión 1.3.0 o a una edición posterior que incluya la corrección de CVE-2025-3248.

La interfaz y los endpoints capaces de validar o ejecutar código no deberían estar accesibles directamente desde internet. Es preferible colocarlos detrás de una VPN, un proxy con autenticación o una red administrativa restringida.

Las claves de proveedores cloud y de modelos tampoco deberían almacenarse como variables permanentes dentro del proceso de Langflow. Un gestor de secretos puede entregar credenciales temporales y limitar cada identidad a las operaciones imprescindibles.

Nacos debe permanecer en redes privadas. Su clave token.secret.key tiene que sustituirse por un valor propio y aleatorio, y la plataforma debe actualizarse a una versión que rechace configuraciones predeterminadas inseguras.

La cuenta utilizada por Nacos para acceder a MySQL no necesita privilegios de administrador global. Debe limitarse a su base de datos y a las operaciones que utiliza la aplicación.

MySQL tampoco debería aceptar conexiones root desde internet. Las reglas de firewall deben restringir el puerto a orígenes concretos, y cada servicio debe disponer de una cuenta independiente.

Los controles de salida son igualmente necesarios. El servidor Langflow comprometido pudo comunicarse periódicamente con infraestructura externa y explorar otros sistemas. Una política de egreso limitada habría reducido el alcance del ataque y generado alertas más claras.

La llegada de agentes ofensivos no invalida las prácticas clásicas de seguridad. Las vuelve más urgentes. Cuando un modelo puede probar, corregir y continuar en segundos, un servicio olvidado en internet deja menos tiempo para reaccionar.

Preguntas frecuentes

¿Fue JadePuffer un ataque completamente autónomo?
No. Hubo preparación humana, selección de la víctima y aportación de algunos accesos. El agente ejecutó de forma autónoma gran parte de las fases posteriores.

¿Qué vulnerabilidad utilizó para entrar?
Explotó CVE-2025-3248 en Langflow, que permite ejecutar código Python sin autenticación en versiones vulnerables.

¿Podían recuperarse los datos pagando el rescate?
No. La clave de cifrado no quedó almacenada ni fue enviada al atacante, y el agente terminó eliminando bases de datos completas.

¿Qué deben revisar ahora los administradores?
La exposición de Langflow, Nacos y MySQL, las versiones instaladas, las claves predeterminadas, las cuentas con privilegios elevados, las tareas programadas y el tráfico saliente hacia destinos no autorizados.

encuentra artículos

newsletter

Recibe toda la actualidad del sector tech y cloud en tu email de la mano de RevistaCloud.com.

Suscripción boletín

LO ÚLTIMO

Las últimas novedades de tecnología y cloud

Suscríbete gratis al boletín de Revista Cloud. Cada semana la actualidad en tu buzón.

Suscripción boletín
×