El acceso a un modelo de IA también se puede secuestrar, y la cuenta se queda del lado de la empresa. Este 2 de noviembre de 2026, Google publicó un informe de Mandiant y Google Threat Intelligence Group sobre incidentes de LLMJacking atendidos durante el año: intrusos que aprovechan recursos empresariales de modelos de lenguaje sin autorización.
📊 El golpe puede llegar en horas: Mandiant observó incidentes con más de 100 mil dólares estadounidenses de consumo fraudulento en un solo día. En algunas organizaciones, los cargos acumulados alcanzaron un millón de dólares antes de revocar el acceso, a diferencia del consumo más gradual asociado con la minería clandestina de criptomonedas.
🌐 Las intrusiones involucraron distintos proveedores de nube y de modelos, y afectaron a organizaciones de Norteamérica, Sudamérica y Asia-Pacífico en servicios financieros, comercio minorista, tecnología y transporte. GTIG identificó grupos con motivación económica que operan desde distintas regiones, además de una separación de tareas: unos consiguen entrar y otros administran la reventa.
⚙️ Esa reventa pasa por los llamados LLM Mixers, intermediarios clandestinos que concentran y canalizan accesos no autorizados para venderlos a suscriptores. En una investigación, GTIG observó a dos grupos operativos distintos coordinándose para comprometer infraestructura empresarial de IA y obtener dinero de ella.
🔑 Aquí no se trata solamente de convencer a un chatbot de soporte de que haga tareas ajenas a su función: los atacantes van directamente por los recursos detrás de la aplicación. Buscan servicios de modelos expuestos o claves de API válidas, aunque la vía de entrada predominante en las investigaciones fueron las credenciales de identidad de nube expuestas o robadas: credenciales IAM, claves de cuentas de servicio, tokens personales de GitHub y tokens de sesiones activas.
¿Qué cambia para quienes desarrollan y operan servicios de IA?
El problema conecta la seguridad de repositorios, identidades y servicios de IA con el gasto de infraestructura. Los casos muestran que una credencial comprometida puede servir tanto para consumir modelos como para buscar más secretos y ampliar el acceso:
- Servicios expuestos: se observaron pruebas automatizadas contra instalaciones públicas de Ollama mediante el endpoint /api/create, con intentos de registrar modelos propios. Dejar estos recursos sin protección también puede elevar los costos de alojamiento.
- Sesiones robadas: a mediados de 2026, el grupo UNC6993 comprometió una instancia mediante una clave de cuenta de servicio mal configurada y obtuvo acceso adicional a una API de modelos. También alojó un portal falso para un supuesto grupo de usuarios de IA, donde pedía pegar un JSON con un token de sesión activo; ese token permitía sortear la contraseña y la autenticación multifactor.
- Entradas combinadas: otro atacante utilizó un token personal robado para entrar a repositorios privados junto con la explotación de una presunta vulnerabilidad en un paquete de una aplicación web dentro de un entorno con contenedores. En otro incidente, credenciales IAM comprometidas y tokens de federación permitieron generar claves nuevas y eludir requisitos de autenticación multifactor; también se documentó el uso de una clave de cuenta de servicio con permisos amplios sobre un proyecto.
- Pruebas discretas de claves: un grupo recolectó claves empresariales de API de modelos publicadas en repositorios de GitHub. Las comprobaba con solicitudes limitadas a un token, usando max_tokens=1, y así evitó ser detectado por las herramientas EDR y las alertas de volumen del SIEM de la víctima.
- Búsqueda de más accesos: tras entrar, los atacantes revisaron servicios y políticas de identidad en varias regiones, clonaron repositorios y buscaron secretos en código, variables de configuración y registros. También consultaron metadatos de almacenes de datos para localizar credenciales y contraseñas, y realizaron operaciones en almacenamiento de objetos asociadas con robo dirigido de información.
- Escalamiento y permanencia: los intrusos abusaron de permisos de identidad y configuraciones de máquinas virtuales. En un caso, los permisos para crear tokens permitieron generar credenciales temporales de cuentas de servicio privilegiadas y extraer de gestores de secretos credenciales de infraestructura, contraseñas de bases de datos internas y claves de API de terceros.
💬 Si operas una API de IA, ¿cómo distinguirías un aumento legítimo de uso de un consumo hecho con credenciales robadas?
¿Pero deveras? 🌵💚




