Infostealer Logs Reveal Thousands of Replayable AI Tokens That Can Bypass MFA

A 7 GB dump exposed authentication data from 5,871 systems

Information stealers are increasingly giving cybercriminals something more useful than passwords: active session tokens and API keys for artificial intelligence services.

The latest findings came to attention on September 9, 2026, and center on a 7 GB stealer-log archive posted to Telegram on August 2, 2026. The dataset contained information harvested from 5,871 infected machines across 162 countries.

Okta’s analysis of the infostealer dump identified 44,791 unique JSON Web Tokens, or JWTs. Investigators assessed that 555 were probably connected to authentication for AI services.

The archive also contained 2,937 JSON Web Encryption structures, known as JWEs. Most were associated with OpenAI, which uses the NextAuth.js authentication framework. Although these structures contain encrypted JWTs, encryption does not necessarily stop an attacker from replaying them.

On the day the archive appeared, 1,843 JWTs and JWEs had not yet expired. That gave anyone with access to the dump a potential window for account takeover.

TruffleHog scanning found another category of exposed credential: 24 API keys that remained valid for Google Gemini, OpenAI, Groq, and OpenRouter. Other tokens in the dataset corresponded to Google, Microsoft, Anthropic, Amazon, Gamma, Notion, Character.ai, Cursor, Poe.com, and Pika AI.

This is not a vulnerability affecting a specific software version. No vulnerable product versions or security patches are involved. The exposure results from authentication material being extracted from compromised endpoints and reused elsewhere.

Why a stolen token can make MFA irrelevant

A valid session token represents an authentication event that has already occurred. When a service accepts that token, it may treat the person presenting it as an authenticated user without asking again for a password or multifactor authentication.

That changes the attacker’s objective. Instead of defeating MFA during login, the attacker steals the artifact created after MFA has already succeeded.

JWTs commonly carry claims used by applications to identify users, sessions, permissions, issuers, audiences, and expiration times. In the analyzed archive, 17.7% of the 44,791 JWTs also contained personally identifiable information in plaintext, including names, phone numbers, or email addresses.

This creates two separate risks. A token may permit account access while it remains valid, and its readable contents may expose identity data even after the token expires.

JWEs hide their internal claims through encryption, but that does not make them harmless. An attacker may not need to decrypt a stolen JWE if the service receiving it can do so. If the token remains valid and is accepted as a bearer credential, replaying the encrypted object can still restore the victim’s session.

API keys present a similar problem. They often authorize direct programmatic access rather than an interactive browser login. An attacker holding a valid key can potentially consume model resources, invoke APIs or run automated workloads under the victim’s account and billing limits.

Passkeys do not solve this stage of the attack. Phishing-resistant authentication can prevent many password and login-phishing compromises, but it does not automatically invalidate session data or API secrets copied from an infected device.

Anti-detect browsers make stolen sessions easier to reuse

Replaying a session token is not always as simple as pasting a string into a browser. Applications may depend on several cookies, browser-storage values and environmental characteristics that must be reconstructed together.

Attackers use tools such as the open-source anti-detect browser Camoufox and the SeleniumBase browser-automation framework to import stolen sessionStorage and localStorage data from files. This can recreate enough of the victim’s browser state for a service to recognize the existing session.

Proxy infrastructure helps reduce visible discrepancies. If a stolen token suddenly appears from a distant country or an unfamiliar network, impossible-travel rules and other risk controls may trigger. Routing the replay through an address closer to the victim’s expected location can make the activity less conspicuous.

Behavioral detection remains possible. New devices, unusual usage patterns, abnormal model consumption and simultaneous token use can all provide signals. However, the attacker begins the session with a valid artifact rather than an obviously incorrect password.

Jeremy Kirk, Okta’s director of threat intelligence, characterized session tokens and API keys as highly sought-after because they can circumvent credential-based authentication. Once a replay succeeds, the attacker is effectively inside the LLM account without completing a conventional login.

The malware families named in connection with this activity include Lumma Stealer and Vidar. The available information does not identify which family infected each of the 5,871 machines, nor does it disclose individual victims or provide public indicators for the affected endpoints.

Stolen AI access has become a commercial product

Stealer logs are sold through underground forums and messaging platforms, but the market is becoming more specialized. Some criminal services now package stolen tokens with browser profiles or anti-detect configurations intended to simplify account access.

Okta identified a Telegram vendor advertising discounted access to Claude, Cursor, ChatGPT, and Gemini. The seller promoted continuous support and money-back guarantees, language designed to make illicit access resemble a conventional subscription business.

Another operation calling itself “Poison Claude” claims to sell access to Anthropic models identified as Opus 4.8, Opus 4.7, Opus 4.6, and Sonnet 4.6. These are vendor claims, and no independent validation of the advertised access was disclosed.

Google Threat Intelligence Group has observed increasing numbers of buyers and sellers trading AI-related accounts in cybercrime communities. Demand includes Claude and Gemini credentials, alongside autonomous coding environments such as Cursor Pro and Devin.

The potential use extends beyond inexpensive chatbot access. Stolen accounts can expose private conversations, uploaded documents, generated code, proprietary prompts and other information retained within AI platforms.

API abuse also enables resource theft, sometimes described as LLMjacking. The model resembles illicit cryptocurrency mining: attackers run compute-intensive activity while shifting infrastructure or usage charges to the victim.

Mandiant encountered a broader version of this problem during an incident-response engagement. A threat actor entered a victim’s cloud environment using an exposed GitHub Personal Access Token, then deployed unauthorized AI infrastructure and scaled high-performance computing resources.

Consequences range from billing fraud to corporate espionage

For individuals, account takeover may expose personal conversations and identity information. The plaintext PII found inside some JWTs can also support targeted phishing, impersonation and social-engineering campaigns.

Enterprise consequences are wider. An attacker could access sensitive prompts, internal documents, source code, customer material or research submitted to an AI service. Compromised accounts could also be resold or used as a foothold for extortion and espionage.

Financial impact can accumulate quickly when stolen API keys permit automated requests. Even where the attacker cannot reach stored data, consuming the victim’s token budget or cloud compute allocation creates a direct cost.

The presence of authentication data from 162 countries shows that this is not limited to one region or service. However, the number of successfully replayed tokens is not known. It is also unknown how many exposed accounts were personal subscriptions, developer accounts or enterprise-managed identities.

Defenses must protect sessions as well as logins

Organizations should monitor for the same session token appearing from unexpected IP addresses, devices or locations. Concurrent use from different environments, abrupt changes in browser characteristics and unusual AI consumption can also indicate replay.

IP allowlisting can restrict access to approved networks, particularly for administrative or API functions. It is not a complete defense because attackers may use proxies or compromise infrastructure inside an allowed range.

API keys should have narrowly defined permissions, usage quotas and continuous consumption monitoring. Suspected keys should be revoked and replaced, while affected browser sessions should be terminated to invalidate stolen state.

OAuth 2.0 deployments should favor short-lived access tokens, reducing the period during which a copied token remains useful. Long-lived credentials create a larger replay window after endpoint compromise.

Chrome’s Device Bound Session Credentials offer a more direct countermeasure. DBSC cryptographically links session credentials to a device, preventing an exported token from being accepted on a different system.

Endpoint security remains central because the theft begins on the user’s machine. Passkeys can harden login, but enterprises adopting AI services must also inventory API secrets, control browser sessions and treat infostealer infections as potential compromise of every active cloud and AI account on the device.