Entrar na sessão sem efetivamente efetuar o login.

Introdução

O preço dos tokens e assinaturas de IA está aumentando à medida que os provedores de modelos de IA buscam recuperar os custos de investimento. Como resultado, essas contas estão se tornando alvos mais valiosos para roubo da conta. Impedir que isso aconteça é fundamental para as empresas. O roubo de IA aumenta o token.  Em três casos recentes, o prejuízo chegou a quase US$ 1 milhão para uma organização, a uma conta chocante de US$ 25.000 para um arquiteto de software e a US$ 600.000 em créditos de IA para uma organização de testes de IA, tudo devido ao roubo de uma chave de API. Alguns fornecedores de IA estão detectando esse abuso e desconectando automaticamente os usuários afetados, além de remover seus cartões de pagamento do registro para limitar os danos. Desenvolvedores de malware e operadores de phishing têm demonstrado interesse em aplicar IA às suas operações, e já foi documentado o uso de inferência de IA roubada por atacantes.

Nossa pesquisa anterior, “Tokens gratuitos à venda: como cadastros falsos impulsionam a fraude em IA”, analisou serviços de IA com desconto que oferecem tokens de IA suspeitosamente baratos. Esses serviços violam os termos de serviço dos provedores de IA, resultando em perda de receita.

Na segunda parte de nossa pesquisa, examinamos a atividade explicitamente ilegal nesse espaço, que é a disponibilidade e venda de segredos relacionados à autenticação que poderiam ser usados para sequestrar contas de IA. Esse tipo de roubo da conta é possibilitado por infecções generalizadas de malware que rouba informações, ou infostealers. Os dados coletados por infostealers acabam à venda em fóruns cibercriminosos e plataformas de mensagens, comercializados como “registros” ou pacotes abrangentes de dados relacionados à autenticação. 

Para o nosso estudo, focamos especificamente no token de sessão e na chave de API dos fornecedores de IA. Os tokens de sessão e as chaves de API são especificamente procurados por agentes de ameaça porque, muitas vezes, é possível reproduzir esses segredos e contornar a autenticação baseada em credenciais. Uma vez reproduzido com sucesso, um agente de ameaça está efetivamente conectado a um serviço LLM sem realmente fazer login. O uso dessas chaves mestras torna o abuso mais difícil, mas não impossível de detectar.

Busca em vazamentos de credenciais

Os operadores de infostealers coletam um volume tão extraordinário de dados que os vendedores da dark web liberam parte deles gratuitamente. As ofertas gratuitas são aperitivos para atrair mais clientes para os planos de assinatura semanais ou mensais.

Analisamos um lote de registros gratuitos divulgados em um canal do Telegram em 2 de agosto de 2026. Este arquivo continha 5.871 pastas, totalizando 7 GB de dados, sendo que cada pasta representava uma máquina infectada. Como pode ser observado abaixo, cada pasta continha subpastas e arquivos com material relacionado à autenticação, como credenciais de login, tokens de sessão, chaves de API e outros.

Google, Microsoft e Amazon usam um gateway de Single Sign-On para todos os seus serviços, portanto, os valores representam os tokens de autenticação primários definidos por esses serviços. A ordem em que esses serviços aparecem não pretende representar a popularidade deles, mas sim a prevalência de cada um neste conjunto de dados específico.

JSON web tokens

Alguns serviços web emitem tokens web JSON (JWTs) para o navegador do usuário após a autenticação, permitindo que diferentes servidores confirmem diretamente as permissões de um usuário autenticado sem consultar um banco de dados de sessão centralizado a cada requisição. Esses tokens sem estado, assinados criptograficamente, contêm dados codificados que descrevem as permissões de seu detentor. Isso difere de um token de sessão, que geralmente é uma string usada no servidor para consultar permissões e preferências do usuário. 

Assim como um token de sessão, um JWT válido pode conceder acesso direto à conta. Acessar uma conta dessa forma ignora a autenticação regular com nome de usuário e senha, além de contornar os desafios de MFA.

Os JWTs são alvo de ladrões de informações. No entanto, nem todos os JWTs estão relacionados à autenticação, e nem todos os presentes no conjunto de dados estavam relacionados a serviços de IA. Dos 44.791 JWTs únicos do conjunto de dados, 555 foram identificados como provavelmente relacionados à autenticação para serviços de IA. 

Os JWTs podem conter um campo “iat”, que significa “emitido em”, e “exp.”. que é uma data de validade. Os JWTs podem ser válidos por períodos que variam de algumas semanas a meses, ou até mesmo anos. A maioria dos JWTs eram tokens de curta duração, válidos por alguns minutos a uma hora antes de expirarem. Esses tokens de curto prazo são gerados a partir de tokens de atualização de longa duração, marcados com a tag HTTPonly para evitar roubo por JavaScript malicioso. No entanto, o malware ainda pode roubar esses tokens. No caso de aplicativos de página única (SPAs), os JWTs são armazenados no LocalStorage ou SessionStorage do navegador, que podem ser roubados.

Uma pesquisa separada encontrou 2.937 JWEs (JSON Web Encryption) relacionados à autenticação, que são JWTs criptografados. A maioria deles foi definida pela OpenAI, que usa o NextAuth.js. Esses JWEs só podem ser descriptografados e lidos pela parte que detém a chave. No entanto, os tokens podem ser reutilizados por um invasor para acessar uma conta, caso não tenham expirado. Quando o conjunto de dados do infostealer foi divulgado em 2 de agosto de 2026, 1.843 JWTs e JWEs ainda não haviam expirado.

Os JWTs têm um lado negativo. Os JWTs podem conter informações pessoais, como nomes, endereços de e-mail e números de telefone. Dos 44.791 JWTs, incluindo os de autenticação e os sem autenticação, encontrados no conjunto de dados, 17,7% contêm informações de identificação pessoal (PII) em texto sem formatação, como nome, número de telefone ou e-mail. Este é outro aspecto problemático, visto que essa informação não expira nem desaparece, e vincula diretamente o usuário a um serviço específico, o que pode ser útil para tentativas de engenharia social ou phishing.

Chaves de API

As chaves de API podem ser geradas a partir dos painéis de controle dos provedores de IA e inseridas em um arquivo de configuração para que uma ferramenta como o OpenClaw as utilize. Inserir uma chave de API em texto simples em um arquivo de configuração ou defini-la como uma variável de ambiente é uma maneira de começar a usar o serviço. Mas um fluxo OAuth 2.0 é uma maneira mais segura de fazer isso, com um aplicativo cliente recebendo apenas credenciais de acesso de curta duração e um token de atualização armazenado com segurança no chaveiro do sistema ou no gerenciador de senhas. Além disso, o OAuth permite permissões de acesso com escopo definido.

Os ladrões de informações visam segredos e credenciais em texto simples justamente porque uma chave de API do LLM roubada é fácil de monetizar, permitindo que um comprador execute inferências na aba de outra pessoa. Algumas variantes procuram arquivos de configuração ocultos. As variantes mais recentes do programa de roubo de dados adicionaram regras explícitas de expressões regulares ou padrões glob para chaves de API no estilo Anthropic ou OpenAI e caminhos de configuração conhecidos de ferramentas de IA.

O TruffleHog encontrou 24 chaves de API ainda válidas em nosso conjunto de dados, abrangendo quatro serviços relacionados à IA: Google Gemini, OpenAI, Groq e OpenRouter. Existem maneiras de limitar as possíveis consequências de uma chave roubada. A OpenAI, a Anthropic e outros fornecedores permitem que os usuários definam limites de uso para as chaves. Em alguns casos, as chaves de API podem ser restringidas por políticas ou listas de permissão de IP. Mas, na ausência desses controles, as chaves poderiam ser usadas e aumentar as contas de tokens de IA.

Ferramentas do ofício duvidoso

Com sites de aparência profissional projetados por IA, fornecedores de IA do mercado cinza, cujos serviços podem estar apenas infringindo os termos de serviço, podem parecer legítimos. Alguns usuários podem não perceber isso imediatamente. No entanto, muitos fornecedores envolvidos no roubo e revenda de segredos de autenticação de IA não tentam disfarçar o que estão fazendo, como pode ser visto na captura de tela abaixo.

No entanto, diversos fatores podem influenciar se um agente de ameaça conseguirá acessar uma conta reproduzindo informações da sessão após estas terem sido roubadas por um infostealer. Por exemplo, uma organização pode estar monitorando vazamentos de infostealers e, ao detectar as credenciais ou segredos de um usuário, acionar bloqueios ou redefinições de senha para contas comprometidas. Se uma organização utiliza listas de permissão de IP, que restringem atividades que não se originam de um intervalo conhecido, um agente de ameaça não conseguiria reproduzir uma sessão válida.

Não observamos evidências de sessões Okta roubadas neste conjunto de dados. Mas seria possível detectar o sequestro de uma sessão SSO do Okta com o Identity Threat Protection (ITP) da Okta. O recurso de Proteção de Sessão do ITP monitora continuamente as sessões ativas pós-autenticação para detectar e prevenir o sequestro de sessão. O sistema reavalia as políticas sempre que ocorre uma mudança crítica de contexto — como uma alteração de endereço IP ou de dispositivo — ou quando recebe telemetria de risco de ferramentas de segurança de terceiros por meio do Shared Signals estrutura (SSF). Se uma sessão parecer arriscada e provavelmente tiver sido sequestrada, os administradores podem usar o Universal Logout para encerrar as sessões ativas em aplicativos SaaS. 

Foram feitos esforços para impedir que ladrões de informações roubem dados de autenticação em escala industrial. A criptografia vinculada a aplicativos (ABE, na sigla em inglês) do Google, introduzida em 2024, criptografa dados confidenciais do navegador, mas os desenvolvedores de programas de roubo de informações rapidamente criaram soluções alternativas. As credenciais de sessão vinculadas ao dispositivo (DBSC) vinculam criptograficamente um token de sessão a um dispositivo, de forma que o token não possa ser usado em outros dispositivos. No entanto, o DBSC ainda está em seus estágios iniciais, pois os serviços e sites da web precisam implementar a compatibilidade com DBSC no lado do servidor. Alguns navegadores, como o Chrome 145 para Windows, lançado em março de 2026, são compatíveis com DBSC.

Conclusão

À medida que o acesso a modelos de vanguarda se torna mais caro, o incentivo para roubar em vez de pagar por eles também aumenta. Nossa análise de um único e relativamente pequeno conjunto de dados de roubo de informações encontrou tokens de sessão relacionados à IA na maioria das máquinas infectadas, muitos ainda válidos meses após a coleta, e chaves de API ativas em texto sem formatação. Nada disso exigiu técnicas sofisticadas para ser coletado, e está disponível gratuitamente ou para compra.

Autenticação mais robusta e o uso de tecnologias resistentes a phishing, como chaves de acesso, dificultaram a apropriação indevida de nomes de usuário e senhas, mas não impedem o roubo de tokens de sessão ou chaves de API. Os responsáveis pela segurança precisam monitorar a reutilização de tokens de sessão, limitar e restringir o escopo das chaves de API e, sempre que possível, usar fluxos OAuth 2.0 com tokens de curta duração que expiram rapidamente se forem roubados. Nenhum desses controles é exótico, mas exigem que tanto organizações quanto usuários individuais tratem tokens e chaves com o mesmo, ou até maior, rigor que as senhas de usuário.

Com o tempo, a adoção mais ampla do DBSC terá um impacto mensurável nesse ecossistema de acesso próspero. Por ora, as organizações precisam fazer o possível para impedir a reutilização dessas chaves-mestras por um mercado criminoso que está cada vez melhor em roubá-las e vendê-las.

Recomendações