En diciembre de 2025 y enero de 2026, una operación bautizada como Bizarre Bazaar registró más de 35.000 sesiones de ataque contra infraestructura de IA expuesta, con una media de unos 972 intentos al día. Cuando el objetivo era una cuenta con acceso a modelos de gama alta, el coste que se le cargaba a la víctima superaba los 100.000 dólares diarios. No hablamos de robo de datos ni de cifrado: hablamos de alguien consumiendo tu cómputo de inteligencia artificial y dejándote la factura.
Este patrón tiene nombre desde 2024, LLMjacking, y en 2026 ha dejado de ser una curiosidad para convertirse en una industria con proveedores, intermediarios y mercados. Investigadores han catalogado alrededor de 175.000 instancias de Ollama accesibles desde Internet en más de 130 países, y firmas como Sysdig documentan un aumento del 376% en el robo de credenciales dirigido específicamente a servicios de IA entre el cuarto trimestre de 2025 y el primero de 2026. Si tu organización ya usa modelos en la nube o servidores de inferencia propios, este es tu problema, no el de otro.
Qué es el LLMjacking y por qué importa ahora
El LLMjacking es el uso no autorizado de la capacidad de inteligencia artificial de una organización: bien a través de credenciales robadas de proveedores en la nube (Amazon Bedrock, Azure OpenAI, Google Vertex AI, Anthropic), bien a través de servidores de inferencia autoalojados que quedan expuestos sin autenticación. El atacante no busca tus datos en primera instancia; busca tu presupuesto de cómputo y la capacidad de razonamiento de los modelos que pagas.
Lo que ha cambiado en 2026 es doble. Primero, la superficie: cada equipo de producto que conecta un modelo, cada clave de API en un repositorio, cada pasarela de IA levantada para "probar cosas" amplía el terreno. Segundo, el propósito: los atacantes más avanzados ya no solo revenden el acceso, sino que consumen ese cómputo para alimentar sus propias herramientas ofensivas. El recurso robado pasa de mercancía a arma.
Anatomía del ataque, a nivel conceptual
Conviene entender la mecánica sin convertirla en un manual. El LLMjacking se apoya en dos condiciones que casi todas las organizaciones cumplen sin darse cuenta.
Vía 1: credenciales de nube robadas
Una clave de API de un proveedor de IA, filtrada en un repositorio, en un registro de contenedores, en un fichero de configuración o mediante una extensión o complemento malicioso, es suficiente. En junio de 2026 se documentaron complementos maliciosos para JetBrains que robaban claves de IA mientras extensiones de navegador capturaban conversaciones con asistentes. Con la clave en la mano, el atacante invoca el modelo desde su propia infraestructura y el consumo se factura a la víctima. Es el mismo patrón de abuso de identidades no humanas que ya vimos en el secuestro de cuentas en Microsoft 365, trasladado al gasto de inferencia.
Vía 2: servidores de inferencia expuestos
Herramientas como Ollama, muy usadas para servir modelos en hardware propio, escuchan por defecto en el puerto 11434 y no incorporan autenticación. Un servidor de este tipo alcanzable desde Internet es, sencillamente, capacidad de modelo gratuita para quien lo encuentre. De ahí que se hayan contabilizado del orden de 175.000 instancias expuestas. Las pasarelas de IA que centralizan credenciales de varios proveedores agravan el problema: comprometer una sola biblioteca puede exponer de golpe toda la cartera de claves de la organización, un riesgo de cadena de suministro que ya tratamos al analizar el fallo de Langflow que convertía los flujos de IA en un almacén de credenciales.
El rastro que deja el ataque es característico: picos de invocaciones a modelos desde direcciones o regiones inusuales, patrones de petición automatizados y a horas atípicas, y un gasto que se dispara sin que ningún proyecto interno lo justifique.
De reventar la factura a construir infraestructura de ataque
La operación Bizarre Bazaar, documentada de forma conjunta por Sysdig y Pillar Security, ofreció la primera fotografía atribuida de extremo a extremo del LLMjacking como industria organizada: bots de escaneo distribuidos que buscan puntos expuestos, scripts que validan las credenciales encontradas y un mercado comercial que revende acceso a más de 30 proveedores. Una cuenta con Claude 2.x podía generar unos 46.080 dólares diarios en costes de inferencia; con Claude 3 Opus la cifra superaba los 100.000 dólares al día.
El salto de 2026 es cualitativo. Como recoge la nota de investigación de la Cloud Security Alliance, los actores más sofisticados ya no se limitan a revender tokens: consumen ese cómputo para mover marcos ofensivos automatizados. Sysdig identificó un framework de explotación, VAPT, que usaba un servidor Ollama secuestrado como motor de razonamiento para hacer reconocimiento de servicios, emparejar vulnerabilidades y encadenar pasos sin intervención humana entre fases. Es la misma tendencia que vimos en el ransomware dirigido por una IA de principio a fin: la automatización deja de ser una herramienta del defensor para volverse también del atacante.
Las cifras, con su fuente
Estos son los datos verificables que sostienen el análisis, cada uno con su origen:
- Unas 175.000 instancias de Ollama expuestas en más de 130 países, según el recuento recogido por The Hacker News.
- Aumento del 376% en robo de credenciales dirigido a servicios de IA entre el 4T de 2025 y el 1T de 2026, según Sysdig.
- Más de 35.000 sesiones de ataque en la operación Bizarre Bazaar, con coste diario superior a 100.000 dólares cuando se atacaban modelos premium, según BleepingComputer.
- Un mercado de reventa que ofrecía acceso a más de 30 proveedores de IA, según Sysdig.
Conviene la honestidad: los casos individuales de facturas disparadas de decenas de miles de dólares en cuestión de horas circulan en múltiples relatos y no siempre son contrastables uno a uno. Los números que usamos arriba sí lo son, porque proceden de investigaciones con telemetría detrás.
Por qué los controles tradicionales no lo ven
El LLMjacking se cuela por los huecos de un modelo de seguridad pensado para otra cosa. La factura de la nube agrega el consumo y un pico de inferencia se diluce entre decenas de servicios; para cuando alguien pregunta, el mes ya se cerró. Las claves de API de IA rara vez se tratan como credenciales críticas: se emiten con permisos amplios, sin caducidad y sin rotación. Y la IA "en la sombra" —modelos y pasarelas que un equipo levanta sin pasar por seguridad— no aparece en ningún inventario.
A esto se suma que la actividad maliciosa se parece mucho a la legítima. Invocar un modelo es, técnicamente, lo mismo lo haga tu aplicación o lo haga un atacante con tu clave. Sin telemetría específica de identidad, volumen y origen, no hay señal que dispare la alarma.
Detección operativa
La detección se apoya en fuentes que la mayoría de organizaciones ya tienen, solo que no las miran con esta amenaza en mente. La clave es correlacionar identidad, volumen, origen y coste.
- Registros de invocación de los proveedores: eventos de tipo InvokeModel en Amazon Bedrock (CloudTrail), registros de diagnóstico de Azure OpenAI y auditoría de Vertex AI. Vigila invocaciones desde identidades, regiones o rangos de red que no correspondan a tus cargas de trabajo.
- Anomalías de coste: alertas de facturación por umbral y por variación relativa, no solo mensuales. Un salto del gasto de inferencia en pocas horas es una de las señales más fiables.
- Monitorización de los puntos de inferencia propios: volumen de peticiones anómalo, patrones automatizados y contenido coherente con herramientas ofensivas, como contratos de salida muy estructurados o marcadores de instrucciones encadenadas.
- Detección de secretos: búsqueda continua de claves de IA en repositorios, imágenes de contenedor, registros y estaciones de desarrollo, incluidos complementos de IDE y extensiones de navegador.
Este trabajo encaja de lleno en la operación de un SOC gestionado y en la inteligencia de amenazas que anticipa qué credenciales de tu organización circulan ya en mercados clandestinos, algo que abordamos desde el servicio de Threat Intelligence.
Defensa práctica
Los controles que de verdad reducen la exposición son concretos y comprobables:
- Autenticación delante de cada punto de modelo. Ollama y pasarelas similares no la traen de serie: hay que añadirla en un proxy inverso o en la capa de red, y nunca exponer estos servicios a Internet.
- Higiene de identidades no humanas: claves de vida corta, con permisos mínimos y ámbito por proyecto, rotación automática y revocación en minutos. Es el mismo principio que aplicamos al gobierno de identidades no humanas: cuentas de servicio, tokens y claves de API.
- Descubrimiento continuo de lo expuesto: saber qué servidores de inferencia, pasarelas y endpoints tuyos son alcanzables desde fuera antes de que lo sepa el atacante, que es la función de la gestión de superficie de ataque.
- Presupuestos y cuotas duras por proyecto y por clave, con corte automático al superar el umbral. Convierte un incidente de 100.000 dólares en uno de unos cientos.
- Filtrado de salida y listas de permitidos: limita a qué destinos y modelos puede llamar cada carga de trabajo, de modo que una clave robada sirva de poco fuera de su contexto.
- Gestión de vulnerabilidades sobre el propio ecosistema de IA: pasarelas, bibliotecas y dependencias entran en el mismo ciclo de parcheo que el resto, tal como planteamos en la gestión de vulnerabilidades.
Para organizaciones sin capacidad interna para sostener esta vigilancia de forma continua, tiene sentido apoyarse en un servicio gestionado (MSSP) que integre detección, respuesta y gestión de exposición en una sola operación.
Implicaciones de cumplimiento
El LLMjacking no es solo un problema de factura. Cuando el cómputo robado se usa para atacar a terceros desde tu identidad, tu organización puede quedar en medio de un incidente que no inició. Bajo NIS2, la gestión del riesgo de proveedores y de la cadena de suministro digital es una obligación explícita, y una pasarela de IA comprometida es exactamente eso: un eslabón. Para entidades financieras, DORA exige controlar la concentración y el riesgo de los proveedores tecnológicos, incluidos los de IA. Y en el sector público, el Esquema Nacional de Seguridad obliga a un control de accesos y trazabilidad que un endpoint de inferencia abierto rompe de raíz.
En esencia
El cómputo de IA se ha convertido en un activo con valor de mercado, y por tanto en objetivo. La defensa no pasa por dejar de usar modelos, sino por tratarlos como lo que son: infraestructura crítica con identidad, telemetría, límites de gasto y una superficie que hay que conocer y reducir. Quien ponga autenticación delante de cada modelo, trate sus claves de IA como credenciales de primera y vigile su factura como vigila sus registros de acceso, habrá cerrado la puerta por la que hoy entra el grueso de estos ataques. El resto es cuestión de tiempo.