Iniciar sesión sin iniciar sesión realmente

Introducción

El precio de los tokens y las suscripciones de IA está aumentando a medida que los proveedores de modelos de IA buscan recuperar los costos de inversión. Como resultado, estas cuentas se están convirtiendo en objetivos más valiosos para la apropiación de cuentas. Detener esto es fundamental para las empresas. El robo de IA incrementa las facturas de tokens.  En tres casos recientes, las cifras ascendieron a casi un millón de dólares para una organización, una factura inesperada de 25 000 dólares para un arquitecto de software y 600 000 dólares en créditos de IA para una organización de pruebas de IA debido al robo de una clave de API. Algunos proveedores de IA están detectando este abuso y cerrando automáticamente la sesión de los usuarios afectados, además de eliminar sus tarjetas de pago registradas para limitar los daños. Los desarrolladores de malware y los operadores de phishing han mostrado interés en aplicar la IA a sus operaciones, y se ha documentado que los atacantes utilizan inferencias de IA robadas.

Nuestra investigación anterior, “Tokens gratuitos a la venta: cómo los registros falsos impulsan el fraude de la IA”, analizó los servicios de IA con descuento que ofrecen tokens de IA sospechosamente baratos. Estos servicios infringen las condiciones de servicio de los proveedores de IA, lo que conlleva una pérdida de ingresos.

En la segunda parte de nuestra investigación, examinamos la actividad explícitamente ilegal en este ámbito, que consiste en la disponibilidad y venta de secretos relacionados con la autenticación que podrían utilizarse para secuestrar cuentas de IA. Este tipo de apropiación de cuentas es posible gracias a infecciones generalizadas de malware que roba información, o infostealers. Los datos recopilados por los infostealers acaban a la venta en foros y plataformas de mensajería de ciberdelincuentes y se venden como “registros”, o paquetes completos de datos relacionados con la autenticación. 

Para nuestro estudio, nos centramos específicamente en los tokens de sesión y las claves de API para proveedores de IA. Los actores de amenazas buscan específicamente los tokens de sesión y las claves API porque a menudo es posible reutilizar esos secretos y eludir la autenticación basada en credenciales. Una vez reproducido con éxito, un actor de amenazas accede efectivamente a un servicio de LLM sin haber iniciado sesión realmente. El uso de estas llaves maestras dificulta la detección de abusos, pero no la hace imposible.

Búsqueda en volcados de credenciales

Los operadores de Infostealers recopilan un volumen de datos tan extraordinario que los vendedores de la Dark Web publican parte de ellos de forma gratuita. Los obsequios gratuitos sirven como gancho para atraer a más clientes a las suscripciones semanales o mensuales.

Analizamos un lote de registros gratuitos publicados en un canal de Telegram el 2 de agosto de 2026. Este volcado constaba de 5871 carpetas que comprendían 7 GB de datos, y cada carpeta representaba una máquina infectada. Como se puede observar a continuación, cada carpeta contenía subcarpetas y archivos con material relacionado con la autenticación, como credenciales de inicio de sesión, tokens de sesión, claves de API y más.

Google, Microsoft y Amazon utilizan una puerta de enlace de Single Sign-On para todos sus servicios, por lo que las cifras representan los tokens de autenticación principales establecidos por dichos servicios. El orden en que aparecen estos servicios no pretende ser representativo de su popularidad, sino más bien de la prevalencia de cada uno en este conjunto de datos en particular.

tokens web JSON

Algunos servicios web emiten tokens web JSON (JWT) al navegador del usuario después de la autenticación, de modo que diferentes servidores puedan confirmar directamente los permisos de un usuario autenticado sin tener que consultar una base de datos de sesiones centralizada en cada solicitud. Estos tokens sin estado, firmados criptográficamente, contienen datos codificados que describen los permisos de su titular. Esto contrasta con un token de sesión, que suele ser una cadena de caracteres que se utiliza en el servidor para consultar los permisos y preferencias del usuario. 

Al igual que un token de sesión, un JWT válido puede otorgar acceso directo a la cuenta. Acceder a una cuenta de esta manera elude la autenticación habitual mediante nombre de usuario y contraseña, así como también los desafíos de autenticación multifactor (MFA).

Los JWT son objetivo de los ladrones de información. Sin embargo, no todos los JWT están relacionados con la autenticación, y no todos los que aparecen en el conjunto de datos estaban relacionados con servicios de IA. De los 44 791 JWT únicos del conjunto de datos, se identificaron 555 JWT como probablemente relacionados con la autenticación para servicios de IA. 

Los JWT pueden contener un campo “iat”, que significa “emitido en”, y “exp.”, que es una fecha de vencimiento. Los JWT pueden tener una validez que oscila entre unas pocas semanas, meses o incluso años. La mayoría de los JWT eran tokens de corta duración que eran válidos durante unos minutos o una hora antes de caducar. Estos tokens de corta duración se generan mediante tokens de actualización de mayor duración etiquetados con la etiqueta HTTPonly para evitar su robo mediante código JavaScript malicioso. Sin embargo, el malware aún puede robar estos tokens. En el caso de las aplicaciones de una sola página (SPA), los JWT se almacenan en el LocalStorage o SessionStorage del navegador, los cuales pueden ser robados.

Una búsqueda independiente arrojó 2937 JWE (JSON Web Encryption) relacionados con la autenticación, que son JWT cifrados. La mayoría de estos fueron establecidos por OpenAI, que utiliza NextAuth.js. Estos JWE solo pueden ser descifrados y leídos por la parte que posee la clave. Sin embargo, si los tokens no han caducado, un atacante podría reutilizarlos para acceder a una cuenta. Cuando se publicó el conjunto de datos de infostealer el 2 de agosto de 2026, 1843 JWT y JWE aún no habían caducado.

Los JWT tienen una desventaja. Los JWT pueden contener información personal, como nombres, direcciones de correo electrónico y números de teléfono. De los 44 791 JWT, incluidos los autenticados y los no autenticados, encontrados en el conjunto de datos, el 17.7 % contiene información de identificación personal (PII) en texto plano, como nombre, número de teléfono o correo electrónico. Este es otro aspecto problemático, ya que esa información no caduca ni desaparece, y vincula directamente a un usuario con un servicio específico, lo que podría ser útil para intentos de ingeniería social o phishing.

clave de API

La clave de API se puede generar desde los paneles de los proveedores de IA e insertarse en un archivo de configuración para que las utilice una herramienta como OpenClaw. Una forma de empezar a usarlo es incluir una clave de API en texto plano en un archivo de configuración o establecerla como variable de entorno. Sin embargo, un flujo OAuth 2.0 es una forma más segura de hacerlo, ya que la aplicación cliente recibe únicamente credenciales de acceso de corta duración y el token de actualización permanece almacenado de forma segura en el llavero del sistema o en el gestor de contraseñas. Además, OAuth permite permisos de acceso con ámbito definido.

Los ladrones de información se centran en secretos y credenciales en texto plano precisamente porque una clave API de LLM robada es fácil de monetizar, lo que permite al comprador realizar inferencias a costa de otra persona. Algunas variantes buscan los archivos de configuración ocultos. Las variantes más recientes de este tipo de malware han añadido reglas explícitas de expresiones regulares o patrones de búsqueda para las claves API de estilo Anthropic u OpenAI y las rutas de configuración conocidas de las herramientas de IA.

TruffleHog encontró 24 claves API aún válidas en nuestro conjunto de datos en cuatro servicios relacionados con la IA: Google Gemini, OpenAI, Groq y OpenRouter. Existen maneras de limitar las posibles consecuencias del robo de una clave. OpenAI, Anthropic y otros proveedores permiten a los usuarios establecer límites de uso para las claves. En algunos casos, las claves API pueden estar restringidas por políticas o listas de direcciones IP permitidas. Pero, a falta de estos controles, las claves podrían utilizarse y generar facturas elevadas por el uso de tokens de IA.

Herramientas del turbio oficio

Con sitios web de aspecto profesional diseñados con IA, los proveedores de IA del mercado gris, cuyos servicios tal vez solo estén infringiendo los términos de servicio, pueden parecer legítimos. Es posible que algunos usuarios no lo reconozcan de inmediato. Sin embargo, muchos proveedores involucrados en el robo y la reventa de secretos de autenticación de IA no intentan ocultar lo que están haciendo, como se puede ver en la captura de pantalla a continuación.

Sin embargo, existen diversos factores que podrían influir en si un actor de amenazas podría acceder a una cuenta reproduciendo la información de la sesión después de que esta haya sido robada por un infostealer. Por ejemplo, una organización puede estar monitoreando las filtraciones de infostealers y, al detectar las credenciales o secretos de un usuario, activar el bloqueo o el restablecimiento de contraseñas para las cuentas comprometidas. Si una organización utiliza listas de IP permitidas, que restringen la actividad que no proviene de un rango conocido, un actor de amenazas no podría reproducir una sesión válida.

No observamos indicios de sesiones de Okta robadas en este volcado de datos. Sin embargo, sería posible detectar el secuestro de una sesión SSO de Okta con Identity Threat Protection (ITP) de Okta. La función de protección de sesión de ITP supervisa continuamente las sesiones activas después de la autenticación para detectar y prevenir el secuestro de sesión. Reevalúa las políticas siempre que se produce un cambio de contexto crítico, como un cambio de IP o de dispositivo, o cuando recibe telemetría de riesgo de herramientas de seguridad de terceros a través del marco de señales compartidas (SSF). Si una sesión parece arriesgada y probablemente ha sido secuestrada, los administradores pueden usar Universal Logout para finalizar las sesiones activas en las aplicaciones SaaS. 

Se han realizado esfuerzos para impedir que los programas de robo de información roben datos de autenticación a escala industrial. El cifrado vinculado a las aplicaciones (ABE) de Google, introducido en 2024, cifra los datos confidenciales del navegador, pero los desarrolladores de programas de robo de información rápidamente idearon formas de eludirlo. Las credenciales de sesión vinculadas al dispositivo (DBSC, por sus siglas en inglés) enlazan criptográficamente un token de sesión a un dispositivo, de modo que el token no se puede utilizar en otros dispositivos. Sin embargo, DBSC aún está en sus primeras etapas, ya que los servicios web y los sitios necesitan implementar la compatibilidad con DBSC en el lado del servidor. Algunos navegadores, como Chrome 145 para Windows, lanzado en marzo de 2026, pueden ser compatibles con DBSC.

Conclusión

A medida que el acceso a los modelos de vanguardia se vuelve más costoso, también aumenta el incentivo para robarlos en lugar de pagar por ellos. Nuestro análisis de un único y relativamente pequeño volcado de datos de robo de información reveló tokens de sesión relacionados con la IA en la mayoría de las máquinas infectadas, muchos de ellos aún válidos meses después de su recopilación, y claves API activas en texto plano. Para recopilar todo esto no se requirió ninguna técnica sofisticada, y está disponible de forma gratuita o para su compra.

Una autenticación más sólida y el uso de tecnologías resistentes al phishing, como las claves de acceso, han dificultado el robo de nombres de usuario y contraseñas, pero no impiden el robo de un token de sesión o una clave de API. Los responsables de la seguridad deben supervisar la reutilización de tokens de sesión, limitar y definir el alcance de las claves de API y, siempre que sea posible, utilizar flujos de OAuth 2.0 con tokens de corta duración que caduquen rápidamente si son robados. Ninguno de estos controles es exótico, pero exigen que tanto las organizaciones como los usuarios individuales traten los tokens y las claves con el mismo rigor, si no mayor, que las contraseñas de los usuarios.

Con el tiempo, una mayor adopción de DBSC tendrá un impacto cuantificable en este próspero ecosistema de acceso. Por ahora, las organizaciones deben hacer todo lo posible para evitar que estas llaves maestras sean reutilizadas por un mercado criminal que cada vez es más hábil para robarlas y venderlas.

Recomendaciones