Signing in without actually signing in

Introduction

The price of AI tokens and subscriptions is increasing as AI model providers seek to recoup investment costs. As a result, these accounts are becoming more valuable targets for account takeover. Stopping this is paramount for enterprises. AI theft increases token bills.  In three recent cases, it was to the tune of nearly $1 million for one organization, a shock $25,000 bill for a software architect and $600,000 in AI credits for an AI testing organization due to a stolen API key. Some AI providers are detecting this abuse and automatically logging affected users out and removing their payment cards on record to limit the damage. Malware developers and phishing operators have shown interest in applying AI to their operations, and attackers have been documented using stolen AI inference.

Our previous research, “Free tokens for sale: How fake signups drive AI fraud” analyzed discount AI services that offer suspiciously cheap AI tokens. These services violate the terms of service for AI providers, resulting in lost revenue.

In the second part of our research, we examine the explicitly illegal activity in this space, which is the availability and sale of authentication-related secrets that could be used to hijack AI accounts. This type of account takeover is enabled by pervasive infections of information-stealing malware, or infostealers. The data collected by infostealers ends up for sale in cybercriminal forums and messaging platforms and sold as “logs,” or comprehensive bundles of authentication-related data. 

For our study, we focused specifically on the session tokens and API keys for AI providers. 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. 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.

Credential dump diving

Infostealers operators collect such an extraordinary volume of data that Dark Web vendors release some of it for free. The freebies are teasers to attract more customers to weekly or monthly subscription offerings.

We analyzed a batch of free logs released on a Telegram channel on Aug. 2, 2026. This dump comprised 5,871 folders comprising 7GB of data, with each folder representing an infected machine. As seen below, each folder contained sub-folders and files containing authentication-related material such as login credentials, session tokens, API keys and more.

Google, Microsoft and Amazon use a single sign-on gateway for all of their services, so the figures represent the primary authentication tokens set by those services. The order in which these services appear is not intended to be representative of these service’s popularity, but rather the prevalence of each in this particular dataset.

JSON web tokens

Some web services issue JSON web tokens (JWTs) to a user’s browser after authentication so different servers can directly confirm an authenticated user's permissions without querying a centralized session database on every request. These cryptographically signed, stateless tokens contain encoded data that describe the permissions of its holder. This is in contrast to a session token, which is usually a string that is used server-side to lookup user permissions and preferences. 

Like a session token, a valid JWT may grant direct account access. Accessing an account this way bypasses regular authentication using a username and password and also bypasses MFA challenges.

JWTs are targeted by infostealers. Not all JWTs are authentication related, however, and not all of these in the dataset were related to AI services. Of the 44,791 unique JWTs from the dataset, 555 JWTs were identified as likely related to authentication for AI services. 

JWTs may contain a “iat” field, which means “issued at,” and “exp.”, which is an expiry date. JWTs can be valid from a few weeks to months to even years. Most of the JWTs were short-lived tokens that were valid for a few minutes to an hour before expiring. Those short-term tokens are minted by longer-lived refresh tokens tagged with an HTTPonly tag to prevent theft by malicious JavaScript. However, malware can still steal these tokens. In the case of single page applications (SPAs), JWTs are stored in a browser’s LocalStorage or SessionStorage, which can be stolen.

A separate search turned up 2,937 authentication-related JWEs, (JSON Web Encryption), which are encrypted JWTs. Most of these were set by OpenAI, which uses NextAuth.js. These JWEs can only be decrypted and read by the party holding the key. However, the tokens could potentially be replayed by an attacker to access an account if they have not expired. When the infostealer data set was released on Aug. 2, 2026, 1,843 JWTs and JWEs had not yet expired.

There is a downside to JWTs. JWTs may contain personal information, such as names, email addresses and phone numbers. Of the 44,791 JWTs, including auth and non-auth, found in the dataset, 17.7% contain plaintext personally identifiable information (PII), such as name, phone number or email. 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.

API Keys

API keys can be generated from AI providers’ dashboards and dropped into a configuration file for a harness like OpenClaw to use. Dropping in a plain-text API key in a configuration file or setting it as an environment variable is a way to get up and running. But an OAuth 2.0 flow is a more secure way to do this, with a client application receiving only short-lived access credentials and a refresh token remaining safely stored in a system keychain or password manager. Additionally, OAuth allows for scoped access permissions.

Infostealers target plain-text secrets and credentials precisely because a stolen LLM API key is easy to monetize, allowing a buyer to run inference on someone else’s tab. Some variants hunt for the hidden configuration files. Newer stealer variants have added explicit regex or glob rules for Anthropic or OpenAI style API keys and known AI-tool config paths.

TruffleHog found 24 still-valid API keys in our dataset across four AI-related services: Google Gemini, OpenAI, Groq and OpenRouter. There are ways to limit the potential ramifications of a stolen key. OpenAI, Anthropic and other providers let users set usage caps on keys. In some instances, API keys may be constrained by policies or IP allowlisting. But absent these controls, keys could be used and run up AI token bills.

Tools of the sketchy trade

With professional-looking AI-designed websites, gray market AI providers whose services may only be breaking the terms of service may feel legitimate. Some users may not immediately recognize that. However, many vendors involved in the theft and resale of AI authentication secrets don’t try to obfuscate what they’re doing, as seen in the screenshot below.

However, there are a variety of factors that could play into whether a threat actor could actually access an account by replaying session information after it is stolen by an infostealer. For example, an organization may be monitoring infostealer dumps and, upon detection of a user’s credentials or secrets, trigger lockouts or password resets for breached accounts. If an organization uses IP allowlisting, which restricts activity that doesn’t come from a known range, a threat actor would not be able to replay a valid session.

We did not observe evidence of stolen Okta sessions in this data dump. But it would be possible to detect hijacking of an Okta SSO session with Okta’s Identity Threat Protection (ITP). ITP’s Session Protection feature continuously monitors active sessions post authentication to detect and prevent session hijacking. It re-evaluates policies whenever there is a critical context change— such as an IP or a device change —or when it receives risk telemetry from third-party security tools via the Shared Signals Framework (SSF). If a session looks risky and has probably been hijacked, admins can use Universal Logout to terminate active sessions across SaaS apps. 

Efforts have been made to stop infostealers from stealing authentication data at an industrial scale. Google’s App-Bound Encryption (ABE), introduced in 2024, encrypts sensitive browser data, but infostealer developers quickly engineered workarounds. Device-Bound Session Credentials (DBSC) cryptographically link a session token to a device so the token cannot be used on other devices. It’s early days for DBSC, however, as web services and sites need to implement DBSC compatibility on the server side. Some browsers, such as Chrome 145 for Windows, released in March 2026, can support DBSC.

Conclusion

As frontier model access grows more expensive, the incentive to steal rather than pay for it grows too. Our analysis of a single and relatively small dump of infostealer data found AI-related session tokens across the majority of infected machines, many still valid months after collection, and live API keys sitting in plaintext. None of this required sophisticated tradecraft to collect, and it is available for free or purchase.

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. Defenders need to monitor for session token reuse, cap and scope API keys, and where possible use OAuth 2.0 flows with short-lived tokens that expire quickly if stolen. None of these controls are exotic, but they require organizations and individual users alike to treat tokens and keys with the same, if not more scrutiny, as user passwords.

In time, wider adoption of DBSC will make a measurable impact on this thriving access ecosystem. For now, organizations need to do their best to prevent the reuse of these skeleton keys by a criminal market that keeps getting better at stealing and selling them.

Recommendations