Stolen AI Tokens Skirt Login Checks

A 7 GB bundle of stolen login data, posted to a Telegram channel on August 2, 2026, turned out to hold more than credentials. Inside it were live authentication tokens for AI services — keys that can be replayed to open an account without ever typing a password or answering an MFA prompt.

Okta reviewed the dump and reported that the log covered 5,871 infected machines across 162 countries. Among the captured material were thousands of unexpired tokens tied to Google, Microsoft, Anthropic, Amazon, Gamma, Notion, Character.ai, Cursor, Poe.com, and Pika AI.

The finding points at a gap that has opened as companies rush AI tools into production: the secrets that keep those tools running are portable, resellable, and often outlive the person who leaked them.

How the theft actually works

Information stealers such as Lumma Stealer and Vidar are built to sweep a compromised machine for anything useful — saved credentials, session tokens, and API keys among them. Threat actors who buy access to those off-the-shelf tools then package the loot as stealer logs and list it on underground forums for follow-on attacks.

Okta's threat intelligence director, Jeremy Kirk, explained why session tokens and API keys draw buyers in particular. "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," he said in a report shared with The Hacker News.

The mechanics are unglamorous. A token is a bearer credential: whoever holds it is treated as the logged-in user until it expires. Nothing in that exchange asks the holder to prove they are the person the account belongs to.

"Once successfully replayed, a threat actor is effectively logged in to an LLM service without actually logging in. Use of these skeleton keys makes abuse more challenging but not impossible to detect."

— Jeremy Kirk, director of threat intelligence at Okta

That last clause matters for defenders. A replayed token does not trigger a failed password attempt or a suspicious MFA push, because no authentication challenge is taking place at all.

Counting what was exposed

Okta's numbers, drawn from the August 2, 2026 dump, sketch the scale of the problem:

• 5,871 infected machines represented in the 7 GB stealer dump
• 162 countries covered by the infected devices
• 44,791 unique JSON web tokens (JWTs) in the dataset, of which 555 were likely related to AI service authentication
• 2,937 authentication-related JSON Web Encryption (JWE) structures representing encrypted JWTs, most set by OpenAI via NextAuth.js
• 1,843 unexpired JWTs and JWEs still valid on the day the data was released
• 17.7% of the 44,791 JWTs containing plaintext personally identifiable information
• 24 still-valid API keys for four AI-related services

The PII figure is its own problem. Names, phone numbers, and email addresses sit inside those tokens in readable form, and unlike a password a token does not simply get changed after a breach. Kirk flagged the durability of that exposure directly.

"This is another problematic aspect since that information does not expire or disappear, and it directly links a user with a specific service, which could be useful for social engineering attempts or phishing."

— Jeremy Kirk, director of threat intelligence at Okta

An attacker who knows which employee uses which AI platform, and has a working email address and phone number for them, has the raw ingredients for a convincing targeted message.

Why JWTs and JWEs both matter

JWT abuse is well understood in identity circles — a valid token can be abused to obtain direct account access, sidestepping both password login and MFA. What Okta found alongside them adds a wrinkle: 2,937 JWE structures, which are encrypted JWTs rather than plain ones.

Encryption normally means an attacker who lacks the key cannot read the contents. But reading and replaying are different operations. Okta noted that while JWE keys can only be decrypted and parsed by whoever holds the decryption key, an attacker can still replay the token itself and reach the account — provided the token has not expired.

Most of those JWE tokens were set by OpenAI, which Okta says uses NextAuth.js. The takeaway is that encryption at rest in a browser or log does not by itself neutralize a stolen token. Expiry does.

Where replay fails

Not every stolen token translates into access. Okta pointed to two controls that interfere with replay attacks.

The first is IP allowlisting, which blocks all network traffic except from specific, approved IP addresses or ranges. An attacker replaying a token from an unapproved address does not get through.

The second is Device Bound Session Credentials (DBSC), which Google added to Chrome. DBSC cryptographically ties a session token to a specific device, so a token lifted from one machine cannot be used on another.

Both are meaningful because they attack the property that makes token theft so profitable — portability. A token that only works from one device, or one network range, is far harder to resell.

The API keys still working

Beyond credentials and tokens, Okta ran the dump through TruffleHog and surfaced 24 API keys that were still valid across four AI-related services: Google Gemini, OpenAI, Groq, and OpenRouter.

An API key is a different kind of asset than a session token. It generally does not expire on a short schedule, it is often shared across a team or embedded in application code, and it bills to the owner's account. An attacker holding one can use it for espionage, extortion, or straight resource theft — and stick the victim with the AI token bill.

That pattern has a name. The abuse of API keys to gain unauthorized access to someone else's large language model, either to pursue the attacker's own goals or to resell the access to other criminals, is referred to as LLMjacking. It mirrors cryptojacking: the intruder quietly consumes someone else's compute while the bill lands elsewhere.

A market with support hours

Stolen AI access has become a product category with its own storefronts. Okta found new black market sites selling stolen token bundles and anti-detect browsers, and observed vendors packaging AI access as a subscription-like offering.

In one Telegram post flagged by the company, an unspecified vendor advertised access to Claude, Cursor, ChatGPT, and Gemini at a discounted price, along with 24x7 support and money-back guarantees. Another service, calling itself Poison Claude, claims to provide access to Anthropic's Opus 4.8, Opus 4.7, Opus 4.6, and Sonnet 4.6 models.

The tooling that makes this work is not exotic. Okta described anti-detect browsers as browsers with features designed to use stolen authentication data while evading security controls. It named two examples that are openly available: the open-source anti-detect browser Camoufox and the automation tool SeleniumBase, both of which can load data taken from a browser's sessionStorage and localStorage from a file.

Many of these tools also let users configure proxies. Okta noted that this helps attackers get around "impossible travel" detections or behavioral triggers that would otherwise mark the access as unauthorized — the standard signals defenders rely on when a session appears from an unexpected location.

What Google is seeing on the same forums

Okta's findings line up with observations Google has published separately. Google said it has seen more personas seeking to purchase AI-related accounts and more sellers advertising them across the cybercrime underground, as threat actor use of AI grows.

Forum posts indicate buyer demand for Claude and Gemini credentials alongside autonomous coding IDEs such as Cursor Pro and Devin — the same categories present in the stealer dump Okta analyzed.

Google's Mandiant incident response team handled at least one engagement in which a threat actor gained initial access to a victim's cloud environment through an exposed GitHub Personal Access Token (PAT). From there, the actor deployed unauthorized AI infrastructure and scaled high-performance compute resources.

Google Threat Intelligence Group framed the economics behind that behavior. "The cost of premium model access and high-performance compute is one of the primary barriers for threat actors seeking to operationalize AI," GTIG said. "This has resulted in increased targeting, exfiltration, and sale of AI accounts across cybercrime communities coupled with a growing number of intrusions involving the compromise of enterprise cloud environments to hijack compute resources."

Read together with Okta's dump analysis, the two accounts describe the same market from opposite ends: buyers paying for access, and stolen tokens supplying it.

What defenders can do about it

The recommendations that follow from Okta's findings are concrete, and most of them concern token lifetimes and key hygiene rather than exotic new tooling.

Okta advised organizations to secure access to AI systems, monitor for session token reuse, scope API keys narrowly, and adopt OAuth 2.0 flows built on short-lived tokens that expire quickly if they are stolen. The shorter the window between issuance and expiry, the less value a stolen token carries on the resale market.

Kirk put the tradeoff plainly. "As frontier model access grows more expensive, the incentive to steal rather than pay for it grows too," he said. "Stronger authentication and the use of phishing-resistant technologies such as passkeys has made username-and-password takeovers harder, but it does not stop a stolen session token or API key."

That is the uncomfortable part for anyone who assumed passkeys or MFA closed the door. Those controls raise the cost of taking over an account through its front entrance. They do nothing to a token that is already valid, already signed, and being presented by someone else's browser.

Why it matters

The practical consequence for businesses running AI tools is that identity sprawl now extends to services that may never have gone through a formal procurement or security review. Every AI product an employee signs into with a work account produces tokens and possibly API keys, and every one of those secrets is a candidate for an infostealer log.

This could mean that asset inventories built around sanctioned SaaS applications are missing a meaningful share of the accounts attackers actually want. It also suggests that token lifetimes — a setting often left at vendor defaults — deserve the same scrutiny as password policy, because expiry is the one control that reliably limits the damage of a stolen bearer credential.

The demand side is unlikely to cool while frontier model access stays expensive, and the supply side depends on secrets sitting in places stealers can reach. Closing the gap between how long tokens live and how quickly they can be resold is the part defenders can control.