Los registros de infostealers revelan miles de tokens de IA reutilizables que pueden eludir la MFA

Un volcado de 7 GB expuso datos de autenticación de 5.871 sistemas

Los infostealers están entregando cada vez más a los ciberdelincuentes algo más útil que las contraseñas: tokens de sesión activos y claves de API de servicios de inteligencia artificial.

Los últimos hallazgos se conocieron el 9 de septiembre de 2026 y giran en torno a un archivo de registros de infostealer de 7 GB publicado en Telegram el 2 de agosto de 2026. El conjunto de datos contenía información recolectada de 5.871 equipos infectados en 162 países.

El análisis de Okta del volcado del infostealer identificó 44.791 JSON Web Tokens (JWT) únicos. Los investigadores consideraron que 555 estaban probablemente relacionados con la autenticación de servicios de IA.

El archivo también contenía 2.937 estructuras JSON Web Encryption, conocidas como JWE. La mayoría estaban asociadas a OpenAI, que utiliza el marco de autenticación NextAuth.js. Aunque estas estructuras contienen JWT cifrados, el cifrado no impide necesariamente que un atacante los reproduzca.

El día en que apareció el archivo, 1.843 JWT y JWE aún no habían caducado. Eso brindaba a cualquier persona con acceso al volcado una ventana potencial para apropiarse de cuentas.

Un escaneo con TruffleHog encontró otra categoría de credenciales expuestas: 24 claves de API que seguían siendo válidas para Google Gemini, OpenAI, Groq y OpenRouter. Otros tokens del conjunto de datos correspondían a Google, Microsoft, Anthropic, Amazon, Gamma, Notion, Character.ai, Cursor, Poe.com y Pika AI.

No se trata de una vulnerabilidad que afecte a una versión específica de software. No hay versiones de productos vulnerables ni parches de seguridad implicados. La exposición se debe a que el material de autenticación se extrae de endpoints comprometidos y se reutiliza en otros lugares.

Por qué un token robado puede hacer irrelevante la MFA

Un token de sesión válido representa un evento de autenticación que ya se ha producido. Cuando un servicio acepta ese token, puede tratar a la persona que lo presenta como un usuario autenticado sin volver a pedir una contraseña ni una autenticación multifactor.

Eso cambia el objetivo del atacante. En lugar de vulnerar la MFA durante el inicio de sesión, roba el artefacto creado después de que la MFA ya se haya superado con éxito.

Los JWT suelen contener claims que las aplicaciones usan para identificar usuarios, sesiones, permisos, emisores, audiencias y tiempos de expiración. En el archivo analizado, el 17,7% de los 44.791 JWT también contenía información personal identificable en texto plano, como nombres, números de teléfono o direcciones de correo electrónico.

Esto crea dos riesgos distintos. Un token puede permitir el acceso a la cuenta mientras siga siendo válido, y su contenido legible puede exponer datos de identidad incluso después de que caduque.

Los JWE ocultan sus claims internos mediante cifrado, pero eso no los hace inofensivos. Un atacante puede no necesitar descifrar un JWE robado si el servicio que lo recibe puede hacerlo. Si el token sigue siendo válido y se acepta como credencial bearer, reproducir el objeto cifrado puede restaurar igualmente la sesión de la víctima.

Las claves de API plantean un problema similar. A menudo autorizan acceso programático directo en lugar de un inicio de sesión interactivo en el navegador. Un atacante que posea una clave válida puede consumir recursos del modelo, invocar API o ejecutar cargas de trabajo automatizadas con la cuenta y los límites de facturación de la víctima.

Las passkeys no resuelven esta fase del ataque. La autenticación resistente al phishing puede evitar muchos compromisos de contraseñas y de phishing de inicio de sesión, pero no invalida automáticamente los datos de sesión ni los secretos de API copiados de un dispositivo infectado.

Los navegadores anti-detección facilitan la reutilización de sesiones robadas

Reproducir un token de sesión no siempre es tan sencillo como pegar una cadena en un navegador. Las aplicaciones pueden depender de varias cookies, valores de almacenamiento del navegador y características del entorno que deben reconstruirse conjuntamente.

Los atacantes usan herramientas como el navegador anti-detección de código abierto Camoufox y el framework de automatización de navegadores SeleniumBase para importar desde archivos los datos robados de sessionStorage y localStorage. Esto puede recrear suficiente estado del navegador de la víctima para que un servicio reconozca la sesión existente.

La infraestructura de proxy ayuda a reducir las discrepancias visibles. Si un token robado aparece de repente desde un país lejano o una red desconocida, las reglas de viaje imposible y otros controles de riesgo pueden activarse. Enrutar la reproducción a través de una dirección más cercana a la ubicación esperada de la víctima puede hacer que la actividad pase más desapercibida.

La detección conductual sigue siendo posible. Los dispositivos nuevos, los patrones de uso inusuales, el consumo anómalo del modelo y el uso simultáneo de tokens pueden aportar señales. Sin embargo, el atacante inicia la sesión con un artefacto válido y no con una contraseña evidentemente incorrecta.

Jeremy Kirk, director de inteligencia de amenazas de Okta, calificó los tokens de sesión y las claves de API como muy codiciados porque pueden eludir la autenticación basada en credenciales. Una vez que la reproducción tiene éxito, el atacante está efectivamente dentro de la cuenta del LLM sin completar un inicio de sesión convencional.

Las familias de malware mencionadas en relación con esta actividad incluyen Lumma Stealer y Vidar. La información disponible no identifica qué familia infectó cada uno de los 5.871 equipos, ni revela víctimas individuales ni proporciona indicadores públicos de los endpoints afectados.

El acceso robado a la IA se ha convertido en un producto comercial

Los registros de infostealers se venden en foros clandestinos y plataformas de mensajería, pero el mercado se está volviendo más especializado. Algunos servicios criminales ahora empaquetan tokens robados con perfiles de navegador o configuraciones anti-detección destinadas a simplificar el acceso a las cuentas.

Okta identificó a un vendedor de Telegram que anunciaba acceso con descuento a Claude, Cursor, ChatGPT y Gemini. El vendedor promocionaba soporte continuo y garantías de devolución del dinero, un lenguaje diseñado para que el acceso ilícito se parezca a un negocio de suscripción convencional.

Otra operación que se hace llamar «Poison Claude» afirma vender acceso a modelos de Anthropic identificados como Opus 4.8, Opus 4.7, Opus 4.6 y Sonnet 4.6. Se trata de afirmaciones del vendedor, y no se reveló ninguna validación independiente del acceso anunciado.

El grupo Google Threat Intelligence ha observado un número creciente de compradores y vendedores que comercian con cuentas relacionadas con la IA en comunidades de ciberdelincuencia. La demanda incluye credenciales de Claude y Gemini, junto con entornos de programación autónomos como Cursor Pro y Devin.

El uso potencial va más allá del acceso barato a chatbots. Las cuentas robadas pueden exponer conversaciones privadas, documentos subidos, código generado, prompts propietarios y otra información retenida en las plataformas de IA.

El abuso de las API también permite el robo de recursos, a veces descrito como LLMjacking. El modelo se parece a la minería ilícita de criptomonedas: los atacantes ejecutan actividades intensivas en cómputo y trasladan los costes de infraestructura o uso a la víctima.

Mandiant se topó con una versión más amplia de este problema durante un trabajo de respuesta a incidentes. Un actor de amenazas entró en el entorno cloud de una víctima usando un token de acceso personal de GitHub expuesto y después desplegó infraestructura de IA no autorizada y escaló recursos de computación de alto rendimiento.

Las consecuencias van del fraude de facturación al espionaje corporativo

Para los particulares, la apropiación de cuentas puede exponer conversaciones personales e información de identidad. La información personal identificable en texto plano hallada dentro de algunos JWT también puede servir para campañas de phishing dirigido, suplantación de identidad e ingeniería social.

Las consecuencias para las empresas son más amplias. Un atacante podría acceder a prompts sensibles, documentos internos, código fuente, material de clientes o investigaciones enviadas a un servicio de IA. Las cuentas comprometidas también podrían revenderse o usarse como punto de apoyo para la extorsión y el espionaje.

El impacto financiero puede acumularse rápidamente cuando las claves de API robadas permiten solicitudes automatizadas. Incluso cuando el atacante no puede acceder a los datos almacenados, consumir el presupuesto de tokens o la asignación de cómputo en la nube de la víctima genera un coste directo.

La presencia de datos de autenticación de 162 países muestra que esto no se limita a una región o un servicio. Sin embargo, se desconoce el número de tokens reproducidos con éxito. Tampoco se sabe cuántas cuentas expuestas eran suscripciones personales, cuentas de desarrollador o identidades gestionadas por empresas.

Las defensas deben proteger las sesiones además de los inicios de sesión

Las organizaciones deben vigilar la aparición del mismo token de sesión desde direcciones IP, dispositivos o ubicaciones inesperadas. El uso simultáneo desde entornos diferentes, los cambios bruscos en las características del navegador y un consumo inusual de IA también pueden indicar una reproducción.

Las listas blancas de IP pueden restringir el acceso a redes aprobadas, sobre todo para funciones administrativas o de API. No constituyen una defensa completa, porque los atacantes pueden usar proxies o comprometer infraestructura dentro de un rango permitido.

Las claves de API deben tener permisos definidos de forma estricta, cuotas de uso y una supervisión continua del consumo. Las claves sospechosas deben revocarse y sustituirse, y las sesiones de navegador afectadas deben finalizarse para invalidar el estado robado.

Las implementaciones de OAuth 2.0 deberían dar prioridad a los tokens de acceso de corta duración, reduciendo así el periodo durante el cual un token copiado sigue siendo útil. Las credenciales de larga duración crean una ventana de reproducción mayor tras el compromiso del endpoint.

Las Device Bound Session Credentials de Chrome ofrecen una contramedida más directa. DBSC vincula criptográficamente las credenciales de sesión a un dispositivo, lo que impide que un token exportado se acepte en un sistema diferente.

La seguridad de los endpoints sigue siendo fundamental, porque el robo comienza en el equipo del usuario. Las passkeys pueden reforzar el inicio de sesión, pero las empresas que adoptan servicios de IA también deben inventariar los secretos de API, controlar las sesiones del navegador y tratar las infecciones por infostealer como un posible compromiso de todas las cuentas cloud y de IA activas en el dispositivo.