La IA al descubierto: 175,000 instancias de Ollama expuestas en Internet y el auge del LLMjacking

La posibilidad de ejecutar grandes modelos de lenguaje (LLM) en tu propio ordenador o en una pequeña máquina en la nube ha sido uno de los grandes avances que ha democratizado la IA. Pero una nueva investigación conjunta de SentinelOne SentinelLABS y Censys ha encendido una alarma: esa democratización también ha creado una enorme “capa no gestionada y públicamente accesible” de infraestructuras de cómputo para IA. El estudio detecta aproximadamente 175.000 instancias únicas de Ollama expuestas en Internet repartidas por unos 130 países, muchas de ellas fuera de cualquier perímetro de seguridad empresarial y sin las protecciones que suelen imponer los proveedores de plataforma.

El mecanismo técnico que explica gran parte del problema es sorprendentemente simple. Ollama, un framework de código abierto que facilita descargar, ejecutar y gestionar modelos de lenguaje en Windows, macOS y Linux, está configurado por defecto para escuchar en la dirección local 127.0.0.1:11434. Sin embargo, con un cambio mínimo —por ejemplo, enlazar el servicio a 0.0.0.0 o a una interfaz pública— esa misma instancia queda accesible desde Internet. Ese gesto trivial es todo lo que necesitan tanto administradores despistados como atacantes para convertir un servicio pensado para uso local en un punto de acceso público.

La exposición no es homogénea: según el informe, la mayor parte de esas instancias se ubican en China (algo más del 30 %), pero también hay una huella significativa en Estados Unidos, Alemania, Francia, Corea del Sur, India, Rusia, Singapur, Brasil y Reino Unido. Además de la mera presencia de endpoints expuestos, el estudio subraya un factor que eleva sustancialmente el riesgo: casi la mitad de los hosts observados informaban en sus APIs de capacidades de “tool-calling” o invocación de funciones. En la práctica, esto permite al modelo interactuar con APIs externas, ejecutar código o acceder a sistemas adicionales, lo que convierte a un generador de texto en un actor capaz de realizar acciones con impacto real.

Ese salto —de producir texto a ejecutar operaciones— transforma por completo el modelo de amenazas. Una API que solo devuelve texto puede producir información nociva, pero no es lo mismo que una API que, si se la engaña o se abusa de ella, puede realizar llamadas a servicios internos, manipular bases de datos o lanzar scripts. Cuando esas capacidades se combinan con autenticación insuficiente y exposición a la red, el resultado según los investigadores es una de las mayores fuentes de riesgo en el ecosistema.

El análisis también detectó instancias que amplían las capacidades más allá del texto, incluyendo razonamiento avanzado y visión, y halló casos concretos —201 hosts, según el informe— con plantillas de prompts sin censura que eliminan salvaguardas de seguridad. Esa combinación de funcionalidades potentes y ausencia de controles incrementa la probabilidad de ataques como el llamado LLMjacking, donde los recursos de una instancia de LLM se secuestran para beneficio de un tercero mientras el propietario paga el coste.

El peligro no es puramente teórico. Un informe complementario de Pillar Security documenta una campaña llamada Operation Bizarre Bazaar, en la que actores maliciosos escanean sistemáticamente Internet en busca de instancias expuestas de Ollama, vLLM y APIs compatibles con OpenAI que no tienen autenticación, validan la calidad de la respuesta y luego comercializan el acceso. La operación descrita por Pillar incluye un proceso completo de reconocimiento, validación y reventa del acceso a través de un gateway unificado, lo que confirma que existe ya una economía delictiva en torno a estas infraestructuras. Esa investigación rastrea la operación hasta un actor conocido como Hecker (a.k.a. Sakuya / LiveGamer101).

El carácter descentralizado de este ecosistema —con puntos de ejecución distribuidos entre proveedores en la nube y redes residenciales— crea además brechas de gobernanza. Muchas de estas instancias se ejecutan fuera del control de equipos de seguridad corporativos, lo que dificulta aplicar políticas convencionales. Los investigadores insisten en que es necesario empezar a diferenciar entre despliegues administrados en la nube y desplegados en el borde (edge) o en dispositivos domésticos, y adoptar controles acordes a cada contexto.

¿Qué pueden hacer administradores y usuarios para reducir el riesgo? Lo más básico, y al mismo tiempo más efectivo, es tratar cualquier endpoint de LLM expuesto como si fuera un servicio público más: imponer autenticación robusta, cifrado, registro de eventos y controles de red. Forzar que el proceso se enlace únicamente a localhost salvo que haya una razón justificada para abrirlo, aplicar reglas de firewall para limitar quién puede conectar, y habilitar mecanismos de autenticación (claves, mTLS, tokens) son medidas inmediatas. Al mismo tiempo, la segmentación de red, la monitorización continua y la aplicación de límites de tasa ayudan a detectar y mitigar abusos. Para organizaciones que integran “tool-calling”, conviene revisar y limitar las capacidades disponibles desde el modelo y auditar exhaustivamente cualquier puente que permita la ejecución de código o el acceso a sistemas críticos.

Si buscas referencias y lecturas para profundizar, el propio análisis técnico de SentinelOne está disponible en su blog y aporta más detalles sobre la metodología y los hallazgos: SentinelOne SentinelLABS. El informe sobre la operación comercial de LLMjacking puede consultarse en la publicación de Pillar Security: Operation Bizarre Bazaar — Pillar Security. Para entender el software implicado, la página oficial de Ollama y su repositorio ofrecen información sobre el proyecto y su configuración: Ollama y GitHub — Ollama. También es útil recordar buenas prácticas generales de seguridad para APIs, recogidas en iniciativas como OWASP: OWASP API Security, y marcos de referencia de riesgo para la IA como los que publica NIST: NIST — AI.

El balance final es claro: las herramientas de IA de código abierto han abierto oportunidades enormes, pero han traído consigo una responsabilidad. Si los modelos pueden traducir instrucciones en acciones, deben someterse a los mismos controles que cualquier otro servicio con privilegios en la red. Ignorar esta realidad deja puertas abiertas a fraudes, abusos y a la construcción de mercados ilícitos que monetizan la exposición. La lección para responsables de TI, equipos de seguridad y usuarios finales es que la flexibilidad técnica debe acompañarse de políticas, monitoreo y diseño seguro desde el inicio.