Okta Finds Replayable AI Session Tokens in a Free Infostealer Dump

On 9 September 2026 Okta Threat Intelligence published an analysis of a free batch of infostealer logs posted to a Telegram channel on 2 August. The 7GB dump covered 5,871 infected machines in 162 countries. Okta found 44,791 unique JSON Web Tokens, 555 of them likely tied to AI service authentication, and 1,843 JWTs and JWEs that were still unexpired on the day the data was released.

The point of the research is simple. A valid session token lets an attacker skip the password and the MFA prompt. In Okta's words, "Once successfully replayed, a threat actor is effectively logged in to an LLM service without actually logging in."

What's affected

Anyone whose browser on an infected machine held a live session. The dump wasn't specific to one vendor. Okta's per-provider count of unique session tokens, with the number still unexpired:

Okta notes that Google and Microsoft totals span each company's whole account ecosystem, not just AI products. It also found 2,937 authentication-related JWE structures, mostly set by OpenAI, and 24 API keys still valid for Google Gemini, OpenAI, Groq and OpenRouter. And 17.7% of the JWTs carried plaintext personal data.

Okta also flagged Telegram vendors reselling discounted access to AI accounts, and noted that "The price of AI tokens and subscriptions is increasing." Stolen sessions are a cheap way around that.

How to check if you're exposed

You can't see inside someone else's stealer log, but you can look for the signals that a session was replayed.

1. Session reuse from new contexts. In your IdP and in AI tools that offer audit logs, look for one session ID used from two different IPs, ASNs or user agents within a short window.
2. Device posture mismatches. Sign-ins that pass MFA from a managed device, followed by API calls on the same session from an unmanaged one.
3. API key usage anomalies. Spikes in spend or calls from unfamiliar IPs on AI provider keys. Most providers show per-key usage in their consoles.
4. Plaintext keys on endpoints. Infostealers grab files as well as cookies. Search developer machines and repos for keys in .env files and shell profiles:

# Shell profiles
grep -nE "(sk-[A-Za-z0-9_-]{20,}|AIza[0-9A-Za-z_-]{35})" ~/.zshrc ~/.bashrc ~/.profile 2>/dev/null
# .env files under your projects folder
grep -rnE --include="*.env" --include=".env*" \
  "(sk-[A-Za-z0-9_-]{20,}|AIza[0-9A-Za-z_-]{35})" ~/projects 2>/dev/null

5. Endpoint detections. Check your EDR for infostealer families on any machine used to reach corporate AI accounts, including personal devices if you allow them.

What to do now

1. Treat tokens like passwords. Okta's own line: "treat tokens and keys with the same, if not more scrutiny, as user passwords."
2. Shorten session lifetimes for AI tools connected to SSO, and require re-authentication for admin and billing actions.
3. Bind sessions to devices where you can. Okta recommends Device-Bound Session Credentials where supported, and DPoP for OAuth clients, so a stolen token is useless off the original device.
4. Cap and scope API keys. Set usage limits and IP allowlists on AI provider keys, and issue per-project keys instead of one shared key.
5. Move keys out of plaintext. Use a secret manager and short-lived credentials. Run secret scanning on repos and developer machines.
6. Revoke on infection. When EDR flags an infostealer, revoke all sessions and rotate all keys for that user, not just their password. A password reset alone leaves stolen session cookies working on many services.
7. Bring AI tools under SSO. Accounts created with personal sign-up can't be revoked centrally.

Why it matters

MFA protects the login. It doesn't protect what comes after. Infostealers have made that gap industrial: they lift cookies and tokens from the browser, and the buyer replays them. Okta's report adds that "None of this required sophisticated tradecraft to collect." This dump was given away for free.

AI accounts are a new and attractive target. They hold conversation history, uploaded files and connected integrations, and many were created quickly by individuals rather than provisioned by IT. That combination of valuable data and weak governance is exactly what attackers look for.

The fix isn't another MFA prompt. It's shorter sessions, device binding, detection of token reuse, and a fast revoke-everything playbook when an endpoint is compromised.

Try it yourself

Pick one AI provider your company uses and list every API key: owner, scope, usage cap and last rotation. Then run secret scanning across your main repos for keys in that provider's format. The demo below walks through how secret scanning finds credentials committed to code.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Okta Threat Intelligence: Signing in without actually signing in (9 September 2026)
• The Hacker News: Infostealer Logs Expose Replayable AI Tokens That Can Bypass MFA