El LLMjacking evoluciona: cómputo Ollama robado para agentes de ataque autónomos
Un informe de Sysdig del 17 de junio de 2026 documenta un incidente capturado: un servidor Ollama expuesto y sin autenticación usado como motor de razonamiento de una cadena ofensiva multietapa. La solución es operativa, no del modelo.
¿Qué es esto?
El 17 de junio de 2026, el equipo de Sysdig Threat Research (TRT) publicó el análisis de un incidente observado el 12 de junio de 2026: un actor malicioso conectó un servidor de modelos Ollama mal configurado y expuesto en Internet a una cadena automatizada de seguridad ofensiva. El actor no conversaba con el modelo ni revendía el acceso: utilizaba la capacidad de inferencia robada como el «cerebro» que toma decisiones en una herramienta multietapa que mapea un objetivo, lo asocia a vulnerabilidades conocidas, redacta código de prueba de concepto e intenta la intrusión.
Es la convergencia de dos tendencias que Sysdig sigue desde que acuñó el término LLMjacking en mayo de 2024. La primera es el robo de cómputo: abusar de la capacidad de IA pagada o autoalojada de un tercero, que termina pagando la factura. La segunda es el utillaje ofensivo autónomo, durante mucho tiempo confinado a la investigación. Aquí ambas se unen en una sola campaña capturada.
Cómo funciona
La condición habilitante es trivial. Ollama escucha en el puerto 11434 sin autenticación por defecto: un servidor enlazado a una interfaz pública responde a cualquiera que lo encuentre. Un estudio de SentinelLABS/Censys del 29 de enero de 2026 contabilizó unos 175 000 hosts Ollama expuestos en 130 países, casi la mitad de ellos anunciando capacidades de llamada a herramientas, lo que convierte un endpoint de generación de texto en uno capaz de ejecutar código.
Como la herramienta del atacante envía todas sus instrucciones al modelo en cada solicitud, Sysdig capturó el framework completo. Conduce al modelo a través de etapas discretas y de formato estricto: normalización de un banner de servicio para la búsqueda de CVE, emparejamiento de vulnerabilidades, reconocimiento web, síntesis de prueba de concepto, elaboración de inyección SQL ciega, extracción de credenciales y secretos, y un orquestador autónomo que itera hasta lograr la ejecución de comandos. Cabe destacar que cada etapa ordena al modelo tratar el contenido capturado del objetivo como datos no confiables, nunca como instrucciones: una defensa deliberada contra la inyección de prompts desde las propias páginas que la herramienta lee.
La firma más duradera del framework es su oráculo de compromiso: inyecta un comando enmarcado por dos cadenas centinela únicas (VAPTb3gin … VAPTfin) y confirma la ejecución remota de código al encontrar esos marcadores alrededor de la salida de id. Enmarcar la salida de un comando con marcadores de inicio/fin para que un parser la extraiga del ruido es un indicio recurrente de utillaje de ataque generado por IA: una persona que lee una terminal no enmarca su salida para una máquina.
Dos detalles confirman que se trata de software real y no de una demostración. La herramienta solicitó al menos siete modelos por su nombre, incluidos comerciales (gpt-4o-mini, claude-3-5-sonnet, gemini-2.0-flash-exp) que simplemente redirigió al backend gratuito de Ollama, y fue capturada en pleno desarrollo: se añadieron y reescribieron etapas a lo largo de una sesión de ocho horas, todas dirigidas a rangos de práctica privados (direcciones RFC 1918 y el espacio de laboratorios de HackTheBox), no a víctimas reales.
Por qué importa
Hace dos años, varios investigadores advirtieron de que un modelo competente, con la descripción de una vulnerabilidad, podía explotar de forma autónoma el 87 % de un conjunto de vulnerabilidades one-day (Fang et al., abril de 2024). Esa advertencia ya es operativa, y la economía se ha desplomado: cuando la inferencia es robada, el coste marginal de un atacante autónomo tiende a cero para cualquiera dispuesto a abusar del cómputo ajeno.
También existe un punto ciego defensivo. Una detección que vigila los registros del propio servidor de modelos supone que el operador lo posee y lo monitoriza. Un servidor expuesto descubierto por un tercero es, por definición, uno que nadie vigila: su propietario ve un cómputo elevado y un puerto abierto, no una cadena de ataque multietapa ejecutándose en su hardware.
Defensas
Trate un endpoint de inferencia autoalojado exactamente como una base de datos expuesta:
- No exponga el puerto 11434. Enlace Ollama (y servidores similares como vLLM) a localhost o a una interfaz interna. Todo acceso remoto debe pasar por un cortafuegos y un proxy inverso con autenticación.
- Añada autenticación en la capa de proxy o de red. Ollama no incluye ninguna; debe imponerse delante de cada endpoint.
- Audite sus propios rangos. Escanee el puerto 11434 como lo haría un atacante e inventaríe los servidores de modelos en la sombra montados fuera del perímetro de seguridad.
- Monitorice el tráfico de inferencia en busca de volúmenes anómalos y firmas de utillaje ofensivo: contratos de salida estructurada rígidos y patrones de comandos enmarcados por marcadores. Sysdig publicó las cadenas centinela (
VAPTb3gin,VAPTfin,__VAPTCMD__) y la sonda de confirmación como anclas de detección. - Desconfíe de los modelos con barreras eliminadas. Las primeras sondas de la campaña solicitaban una versión Llama «abliterated»; la presencia de plantillas de modelos sin censura en un endpoint es en sí misma una señal de riesgo.
Estado
| Elemento | Detalle |
|---|---|
| Autor del informe | Sysdig TRT |
| Observado | 12 de junio de 2026 (regresó el 14 de junio) |
| Publicado | 17 de junio de 2026 |
| Causa raíz | Ollama expuesto y sin autenticación (puerto 11434) |
| CVE | Ninguno — exposición de configuración, no un fallo de software |
| Magnitud de la exposición | ~175 000 hosts Ollama expuestos (SentinelLABS/Censys, ene. 2026) |
Este artículo es educativo y defensivo. Resume investigaciones divulgadas públicamente y no reproduce las cargas útiles operativas ni los prompts de etapa del framework capturado.