Infostealer Logs Expose AI Tokens That Can Bypass MFA

"Session tokens and API keys are sought specifically by threat actors"

“Session tokens and API keys are sought specifically by threat actors because it is often possible to replay those secrets and bypass credential-based authentication,” Jeremy Kirk, director of threat intelligence at Okta, said in a report shared with The Hacker News. That observation sits at the center of a fresh wave of abuse: cybercriminals are turning infostealer dumps into ready-made keys for accessing commercial AI services without ever entering a username and password.

Okta’s analysis: a 7 GB dump and tens of thousands of tokens

Okta analyzed a 7 GB infostealer dump that was released on a Telegram channel on August 2, 2026. The stealer log contained data from 5,871 infected machines across 162 countries. From that single dump researchers extracted 44,791 unique JSON Web Tokens (JWTs); 555 of those JWTs were likely related to authentication for AI services.

Okta further identified 2,937 JSON Web Encryption (JWE) structures — encrypted JWTs — most of which were set by OpenAI implementations that use NextAuth.js. Although JWEs require the holder of a decryption key to read their contents, Okta noted they can still be replayed and thus used to gain access to accounts as long as they remain unexpired. On the day the data was released, 1,843 JWTs and JWEs were identified as unexpired.

Worryingly, 17.7% of the 44,791 JWTs included plaintext personally identifiable information (PII) such as names, phone numbers, or email addresses — data that “does not expire or disappear,” Kirk said, and which could fuel targeted phishing or social-engineering campaigns.

API keys, LLMjacking, and the economics of illicit AI access

Beyond session tokens, the dump contained still-valid API keys: TruffleHog analysis unearthed 24 keys that appeared to work against four AI-related services, including Google Gemini, OpenAI, Groq, and OpenRouter. Possession of such a key can let an attacker run models, exfiltrate data, or “rack up AI token bills,” the report said.

Okta and Google researchers described this pattern as LLMjacking — the abuse of API keys and accounts to run large language model workloads on victims’ accounts or cloud resources. Google’s Threat Intelligence Group (GTIG) said the high cost of premium model access and high-performance compute is a primary driver: “As frontier model access grows more expensive, the incentive to steal rather than pay for it grows too,” Kirk said, and GTIG added that threat actors are increasingly targeting AI accounts and cloud environments to hijack compute resources.

In at least one incident response handled by Google’s Mandiant team, an exposed GitHub Personal Access Token (PAT) was used to gain initial access to a cloud environment, deploy unauthorized AI infrastructure, and scale high-performance compute.

Anti-detect tooling, underground markets, and promoted services

Okta’s report documents how stolen session data is packaged and sold. Underground vendors were observed offering access to Claude, Cursor, ChatGPT, and Gemini with “24x7 support and money-back guarantees.” A service named Poison Claude advertised access to multiple Anthropic models — Opus 4.8, Opus 4.7, Opus 4.6, and Sonnet 4.6.

Accessing accounts with stolen session data typically requires tooling. Okta noted so-called “anti-detect” browsers and automation tools can load stolen authentication data from browser sessionStorage or localStorage and configure proxies to evade detections such as impossible-travel triggers. The report mentions the open-source anti-detect browser Camoufox and automation tool SeleniumBase as examples of software that can be repurposed to replay session data.

Technical mitigations cited: DBSC, IP allowlisting, short-lived OAuth tokens

The report highlights defensive controls that can blunt token replay attacks. IP allowlisting — blocking all network traffic except from approved addresses — can prevent a replayed token from working when access attempts originate from unauthorized networks. Google has also added support in Chrome for Device Bound Session Credentials (DBSC), which cryptographically tie a session token to a specific device, making a token unusable on another system.

Okta and the research community recommended scoping API keys, monitoring for session token reuse, and adopting OAuth 2.0 flows that issue short-lived tokens so that stolen credentials expire quickly. Kirk emphasized that stronger authentication and phishing-resistant methods such as passkeys make password-based takeovers harder, “but it does not stop a stolen session token or API key.”

What this means for technologists, policymakers, and affected enterprises

• Technologists and security teams: Watch for replayed tokens and anomalous reuse of JWTs and JWEs; apply short-lived OAuth flows, enforce IP allowlisting where possible, and consider DBSC support in client deployments.
• Policymakers and regulators: Monitor the commercial availability of stolen AI account access and anti-detect tooling in underground markets, and weigh requirements for better key-management and incident reporting tied to AI services.
• Enterprise procurement and cloud owners: Treat AI model access and high-performance compute as attack surfaces — enforce least privilege on API keys, audit token issuance, and inventory any external plugins or auth flows that surface PII in tokens.

The Okta dump illustrates a practical truth: once harvested from endpoints, tokens and keys become replayable currency for attackers who want to bypass multi-factor controls, deploy their own compute, or sell access to others. The test for defenders is not just stronger login screens, but hardening the entire token lifecycle and the tooling that can replay those tokens — before stolen keys turn into a sustained drain on both money and trust.

Source: The Hacker News — Infostealer Logs Expose Replayable AI Tokens That Can Bypass MFA