Stolen AI Logins: What Happens When an Employee's ChatGPT Session Ends Up in a Stealer Log
By ScruteXPublished Updated
On 30 August 2026, Anthropic began signing Claude users out of their own accounts. Commodity infostealer malware had copied their live browser sessions, and someone else was spending their paid usage. No password leaked. No MFA prompt fired.
The same mechanism works against ChatGPT, at far larger volume, and the account on the other end of the stolen cookie often belongs to one of your employees.
What is a stolen AI login? A stolen AI login is a saved password or, more usefully to an attacker, a live session cookie for an AI service such as ChatGPT, taken from an infected computer by infostealer malware and sold inside a stealer log. With the cookie, a buyer opens the account as the employee. They can read every saved conversation, uploaded file and stored memory, use any connected apps, and spend the paid plan, without entering a password or answering an MFA challenge. Changing the password does not end the session. Revoking the session and cleaning the infected device does.
Key findings
- In a 2026 threat intelligence industry study of stealer logs, a captured ChatGPT or OpenAI session appeared at 358 of 482 large enterprises examined, and those companies carried roughly 90% of all records in the study.
- A 2026 threat intelligence report counted more than 300,000 ChatGPT credential sets advertised on the dark web in 2025, driven largely by infostealer operators adding AI services to their target lists.
- Anthropic's August 2026 notice named six stealer families behind the Claude session thefts: Vidar, LummaC2, StealC, RedLine and Acreed on Windows, and Atomic Stealer (AMOS) on a small number of Macs. Two of those families had already survived law enforcement disruption.
- OpenAI's own help centre says that after you click "Log out all", other active ChatGPT sessions can take up to 30 minutes to end.
- Device Bound Session Credentials, which make stolen cookies useless on another machine, reached general availability in Chrome 146 on Windows in April 2026. They protect only the sites that implement them.
What is a stolen AI login?
A stolen AI login comes in two forms, and they behave very differently.
The first is a saved password. The employee let the browser remember their ChatGPT, Claude or Gemini password, and the infostealer copied it from the browser's password store. A password reset kills this one, provided the account has a password at all. Many people sign in to ChatGPT with Google, Microsoft or Apple, in which case the stealer usually takes the password for that identity provider instead, which is worse.
The second is a session cookie. After a successful login, the AI service hands the browser a token that says "this person already proved who they are". The browser presents it on every request so the user does not have to log in again. Whoever holds that token is logged in. It carries no link to the password and it has already passed MFA. When an infostealer copies it, the buyer imports it into their own browser and lands inside the account.
It also helps to separate two datasets that often get lumped together as "leaked credentials":
| Breach corpus | Stealer log | |
|---|---|---|
| Where it comes from | A service's database gets breached and dumped | Malware runs on one person's device and copies what the browser holds |
| What it contains | Usernames and passwords, often hashed, for one service | Every saved login on the device, plus cookies, autofill, and system details |
| How fresh it is | Often months or years old by the time it circulates | Captured days or weeks before sale |
| Session cookies | No | Usually yes |
| What it means for you | Password reuse risk | An infected device and live sessions, possibly including work systems |
A row in a breach corpus is a password hygiene problem. A row in a stealer log is an incident on a specific machine. Stolen AI logins almost always come from the second kind.
How does a ChatGPT session end up in a stealer log?
The chain has five steps, and none of them involves the AI vendor.
1. Infection. The employee runs something they should not have: a cracked tool, a fake installer from a search ad, a game mod, a pirated plugin. A 2026 threat intelligence study of 10,198 infostealer victims found that gaming lures account for 43% of infections, and that the other 57% arrive through productivity tools, file-sharing platforms and developer utilities. The same study found that one in four infected users held active corporate credentials. The gamer and the employee are frequently the same person on the same laptop.
2. Collection. The stealer runs for seconds. It copies saved passwords, cookies, autofill data, tokens and a system profile, then sends the bundle to its operator. Infostealers do not need administrator rights to do this.
3. Packaging. The operator stores each infected device as one log: a folder holding the site, username and password for every saved login, the cookie files for each browser, and details such as IP address, country and hardware ID. An entry for chatgpt.com sits in the same folder as the employee's VPN portal, webmail, CRM and personal banking.
4. Sale. Logs trade individually, in bulk bundles through Telegram channels, and through automated log markets where buyers search by domain. A buyer looking for corporate access searches for your email domain. A buyer looking for AI access searches for chatgpt.com or claude.ai.
5. Replay. The buyer imports the cookie. The AI service sees a valid session and serves the account. Because sessions eventually expire, fresh logs are worth more than old ones, which is why detection speed matters more for cookies than for passwords.
The families doing the collecting are not new. Anthropic named Vidar, LummaC2, StealC, RedLine and Acreed on Windows, plus AMOS on macOS, in its August 2026 notice. RedLine was the target of the international Operation Magnus takedown in October 2024, and Microsoft and the US Department of Justice seized infrastructure behind Lumma in May 2025. Both still appear in 2026 incident notices, and credentials stolen in earlier campaigns keep resurfacing for sale long after the takedowns.
| Stage | MITRE ATT&CK technique | ID |
|---|---|---|
| Stealer copies saved browser passwords | Credentials from Password Stores: Credentials from Web Browsers | T1555.003 |
| Stealer copies session cookies | Steal Web Session Cookie | T1539 |
| Buyer imports the cookie | Use Alternate Authentication Material: Web Session Cookie | T1550.004 |
| Buyer operates the account | Valid Accounts: Cloud Accounts | T1078.004 |
| Buyer reads stored conversations and files | Data from Information Repositories | T1213 |
What does an attacker get from a stolen ChatGPT session?
One 2026 industry study describes an AI account as four things at once: a searchable archive, an execution engine, a billable resource and an identity. That framing holds up when you walk through what a buyer can do in the first ten minutes.
The conversation archive. Employees paste source code, contracts, customer records, board papers and unreleased plans into prompts, then keep the chat. In 2023 Samsung found engineers had pasted confidential source code and internal meeting notes into ChatGPT on three separate occasions. A stolen session hands the buyer the equivalent of those three incidents, searchable, with the employee's full history behind them. Researchers made this point when the problem was first measured in 2023: ChatGPT stores the history of queries and responses by default, so account access is data access.
Memory, projects and uploaded files. Modern assistants keep saved facts about the user, files uploaded to projects, and custom assistants configured with internal documents. None of this appears in a DLP report, because the employee uploaded it through a browser.
Connected apps and agents. Where a workspace has enabled connectors, the session may reach cloud drives, mail or code repositories. Automation platforms are sharper still. Researchers note that a stolen Zapier session lets an attacker build a workflow that exfiltrates data on a schedule, from the vendor's trusted IP space.
Billing and API keys. The Claude incident shows the simplest monetisation: burn the victim's paid usage or resell access. Anthropic told affected users the tell was usage limits that refilled and then drained while they were not using the product. Keys pasted into chats or settings pages go out with everything else and feed LLMjacking, where stolen AI capacity gets resold at a discount.
There is also a quieter risk: the attacker can change what the account does next. Someone with the session can edit saved instructions or memory so that future answers carry the attacker's content: a changed bank detail in a drafted invoice email, a subtly altered script. The employee keeps using an account that now works against them.
The conversation history is also reconnaissance. It names projects, suppliers, reporting lines and the systems people struggle with. That is the raw material for a phishing email or a help desk call that sounds exactly like an insider.
How many stolen ChatGPT credentials are in circulation?
Three public studies measure this, and each counts something different.
| Year | Source | What was counted | Figure | Caveat |
|---|---|---|---|---|
| 2023 | Threat intelligence industry study | Stealer-infected devices with saved ChatGPT credentials, June 2022 to May 2023 | 101,134 | Asia-Pacific had 40.5%. India led all countries with 12,632 |
| 2025 | Threat intelligence industry report | ChatGPT credential sets advertised on the dark web | 300,000+ | Advertised volume. The posted credentials reviewed did not remain valid |
| 2026 | Threat intelligence industry study | Infostealer records tied to AI services | 1,000,000+ across 80,000+ corporate domains | In a 482-company enterprise subset, 295 surfaced in the last 90 days |
Read these numbers carefully before you put one in a board paper.
The units differ. Devices, credential sets and records are not the same thing, and adding them together produces nonsense.
Advertised does not mean live. The 2025 report makes this point itself: the posted credentials it reviewed did not remain valid, because much of what sellers post is recycled or already expired. The 2026 recency figure matters more for defenders, because a record from the last 90 days is far more likely to carry a working session than one from 2023.
Vendor research has a commercial purpose. The 2026 findings reached most readers through a sponsored article promoting the researchers' own free checker. That does not make the data wrong, and ScruteX has the same incentive. It does mean you should treat the direction of travel as the finding, and the direction has been consistent for three years: more AI accounts in more stealer logs, with ChatGPT dominant because it has the most users.
Indian organisations should pay attention to the 2023 figures. India had more compromised ChatGPT accounts than any other country in the 2023 study. That figure is three years old, so treat it as a baseline rather than a current count.
Why don't password resets, MFA and SSO stop it?
Most incident runbooks were written for stolen passwords. A stolen session defeats each of the usual controls in a different way.
Password reset. The session was issued before the reset. Unless the service revokes sessions on password change, the buyer stays signed in. Do not assume it does. Use the explicit session control instead.
MFA. MFA protects the moment of login. A session cookie is proof that login already happened, so the challenge never appears. That is why attackers want session tokens more than passwords: a token replays straight past credential-based authentication.
SSO. Enforcing SSO for ChatGPT removes the saved ChatGPT password and routes new logins through your identity provider. It does not kill a live session that already exists, and it only covers accounts on your verified domain. Employees using a personal Gmail address for work prompts sit entirely outside it. OpenAI's Business SSO documentation also states that admins cannot require someone to merge or delete a personal workspace.
Workspace MFA. OpenAI's admin documentation says ChatGPT does not provide workspace-wide MFA enforcement. Organisations that need it must enforce SSO and MFA through their identity provider.
Log out all. This is the control that works. OpenAI's help centre documents a "Log out all" option under Settings, then Security, and notes that other active sessions can take up to 30 minutes to end. It still only helps if the device is clean. Anthropic warned its users that signing out stops the stolen sessions but does not remove the malware, which will simply collect the next session.
Is this a shadow AI problem or an endpoint problem?
It is both, and the order in which you treat them matters.
The researchers behind the 2026 study read ChatGPT's dominance in their data as a shadow AI signal rather than a verdict on OpenAI's security. More employees have quietly signed up with a work email on a personal device, and that is the population infostealers scrape. Their conclusion for CISOs is that the exposure follows the users, and the users are everywhere your policy is not.
That is right, but it points to the policy fix before the incident fix. The stealer log that contains the ChatGPT session also contains every other login on that machine. If the 2026 finding of one in four victims holding corporate credentials holds for your staff, the AI entry is often the first visible sign of a device that also held VPN, email and CRM access.
So the AI login is the alert, and the device is the incident. Treat any employee appearing in a stealer log as an endpoint compromise, then deal with the shadow AI question as a governance project.
Blanket bans tend to backfire here. Blocking ChatGPT on managed laptops pushes the same work onto personal machines with no EDR, which is exactly where the stealers live. Giving staff a sanctioned, SSO-enforced workspace that is easier than the personal alternative usually does more.
Will device-bound sessions fix it?
Eventually, and partly.
Google made Device Bound Session Credentials (DBSC) generally available to Windows users in Chrome 146 in April 2026, and began rolling it out by default to Google Workspace and personal Google accounts from 25 May 2026. DBSC ties a session to a private key held in the device's TPM. A cookie copied to another machine cannot be refreshed, so it stops working within minutes.
Three limits apply. DBSC protects only the sites that implement it on their servers. macOS support has been announced but not shipped, and other browsers had not shipped it as of mid-2026. And it does nothing for saved passwords, API keys pasted into chats, or the other logins in the same stealer log.
Ask each AI vendor you use whether it supports device-bound sessions and on which platforms. Until the answer is yes across your fleet, plan as if every session cookie can be replayed.
What should security teams do when an AI login appears in a stealer log?
Work in this order. The first block contains the incident, the second assesses it, and the third removes the conditions that caused it.
Hours 0 to 4: contain
- Identify the device from the log's system details (hostname, hardware ID, IP, infection date) and establish whether it is corporate, personal, or a family machine. If it is managed, isolate and reimage it. If it is personal, the employee needs help cleaning it before they sign in to anything again.
- Revoke AI sessions explicitly. In ChatGPT, use Settings, Security, "Log out all", and allow for the 30-minute lag. Do the same in every AI service listed in the log, and on the OpenAI API platform if the user has developer access.
- Revoke sessions and refresh tokens in your identity provider for the user, as well as resetting the password. If they sign in to AI tools through Google or Microsoft, that session is in scope too.
Hours 4 to 24: assess
- Rotate every credential in the log, not only the AI one. The log is a list of everything the buyer holds.
- Review what the AI account contained and did. Check conversation history for sensitive material, memory and saved instructions for tampering, connected apps and OAuth grants, custom assistants, and any API keys. Revoke and reissue keys, and set spend caps and usage alerts on the replacements.
- Decide whether a notification clock has started. That depends on what the session reached. If conversations held personal data or the device held work system access, bring in counsel early. In India, CERT-In's 2022 directions require reportable incidents to be reported within six hours of noticing them. GDPR Article 33 sets 72 hours for personal data breaches. APRA CPS 234 requires notification within 72 hours of becoming aware of a material information security incident. Each clock starts at awareness, not confirmation.
Week 1: fix the class
- Enforce SSO for your verified domains in ChatGPT Business or Enterprise, and enforce MFA through the identity provider.
- Count the work-email accounts that sit outside the workspace and give those users a sanctioned route in.
- Block personal AI account logins on managed devices, and separate work and personal browsing profiles where you cannot separate hardware.
- Monitor stealer logs for your domains continuously, because the next infected laptop will not announce itself.
One more step matters more than it looks: tell the employee what happened in plain terms and without blame. Their personal banking and email are in the same log.
Where other security tools fit
No single tool covers this problem, and it is worth being clear about what each category does well.
EDR prevents and detects stealer infections on managed devices. It sees nothing on the personal laptop where the employee signed in to ChatGPT at the weekend.
Identity providers and identity threat detection tools catch session anomalies inside the tenant: a session that changes country or device fingerprint mid-life, or tokens used after a reset. They only see AI services routed through SSO.
AI vendors hold the session controls. SSO, domain verification, "Log out all" and, in time, device-bound sessions all sit on their side, and Anthropic's August response (invalidate sessions, strip abused payment methods, notify affected users) is a reasonable template for the vendor's part.
Specialist stealer log intelligence providers hold deep collections, and several now offer free AI exposure lookups by domain. For a large team with analysts to run each tool, that combination works well.
What the in-tenant tools cannot answer is whether an employee's session is already for sale outside your environment. That question sits outside the tenant, and it is the one this article's checklist starts with. For a smaller team, the argument for a single external view is correlation: the stealer log entry, the exposed VPN portal it points at, and the vendor who holds the same data all show up in one place instead of five.
Who else pays for a stolen AI session
The employee pays first. The log that exposed their work AI account also holds their personal email, banking and shopping logins. Treat them as a victim of the incident, not its cause.
Customers pay next. If an employee pasted customer records into a prompt to draft a reply or summarise a complaint, those customers' details now sit in an account someone else can read. They never chose to have their data processed by an AI assistant, and most will never find out.
Colleagues and suppliers pay last. A conversation archive that names people, deals and systems becomes a script for impersonating them. Closing stolen AI sessions quickly is how you keep those people from receiving a convincing message that appears to come from inside your company.
Key takeaways
- A stolen AI login is usually a session cookie, not a password. It bypasses MFA and survives a password reset.
- The AI entry in a stealer log is the alert. The infected device, and every other login it held, is the incident.
- Use each AI vendor's explicit session revocation, such as ChatGPT's "Log out all", which can take up to 30 minutes, and clean the device before the user signs in again.
- SSO and domain verification close the saved-password gap for workspace accounts only. Personal accounts on work tasks stay outside them.
- Device-bound sessions will shrink the problem, but only on supporting sites and platforms. Plan as if every cookie can be replayed today.
Are your employees' AI logins already in a stealer log?
Check these five things. Each one is answerable from your own records this week.
- ☐ Do you know which AI services your staff sign in to with a work email, including free personal accounts on ChatGPT, Claude, Gemini, Zapier or Hugging Face?
- ☐ Is SSO enforced for your verified domains in ChatGPT, and have you counted the work-email accounts that sit outside the workspace?
- ☐ When an employee appears in a stealer log, does your runbook include revoking sessions in each AI service, or only a password reset?
- ☐ Can you name the devices where work AI sessions live that are not in your EDR fleet?
- ☐ Have API keys been pasted into chats, custom assistant settings or notes, and do the live keys have spend caps and usage alerts?
What ScruteX finds here
ScruteX matches stealer log records against your domains and employee email addresses, and keeps them separate from breach corpus hits, because a two-year-old database dump and a log captured last week need different responses. Each stealer log record carries the site the login was saved for, so an entry for chatgpt.com, claude.ai or an automation platform shows the service by name, along with whether a session cookie came in the same capture. ScruteX watches the Telegram channels and paste sites where logs are shared as well as the forums, and it groups the other saved logins from the same device, so the AI entry gets triaged as the endpoint incident it is. At an ASX-listed financial services client, median credential exposure detection fell to 1.8 days, down from 26, measured across a 12-month deployment.
Check whether your domain's AI logins are in stealer logs
Enter your work domain. ScruteX starts matching it against stealer logs, paste sites and Telegram sources straight away. Agentless: a domain and a set of keywords. No credit card.
ScruteX sees a stolen AI login only once the log reaches a source we monitor. Logs sold privately, one buyer to one seller, never surface for anyone to see. We also do not replay stolen cookies to test whether a session is still live. That check belongs to you, through each AI vendor's own session controls.
If credentials are your problem: Data Exposure Insights, which covers stealer logs, paste sites and exposed sessions tied to your domains and employees.
If an AI vendor or supplier is your problem: Vendor Insights, for tracking the external posture of the third parties that now hold your employees' conversations.
FAQ
Q: Can someone access my ChatGPT account with a stolen session cookie?
A: Yes. A session cookie proves you already logged in, so whoever imports it into their browser is treated as you until the session ends or is revoked. They do not need your password and never see an MFA prompt. Revoke sessions with "Log out all" in ChatGPT's security settings, then clean the device the cookie came from.
Q: Does changing my ChatGPT password log out other sessions?
A: Do not rely on it. Use the explicit "Log out all" control under Settings, then Security. OpenAI notes that other active sessions can take up to 30 minutes to end. Many ChatGPT users sign in with Google, Microsoft or Apple and have no ChatGPT password at all, so revoke sessions with that identity provider too.
Q: How do I know if my company's ChatGPT logins are in stealer logs?
A: Monitor stealer log sources for your corporate email domains, not only breach databases. Stealer logs record the site each login was saved for, so an entry for chatgpt.com or claude.ai against a work email is the signal. Check the Telegram channels where logs are shared as well as forums and markets, and check recency: an entry from the last 90 days is the one most likely to hold a working session.
Q: Does SSO or MFA protect ChatGPT accounts from infostealers?
A: Partly. SSO removes the saved ChatGPT password for accounts on your verified domain, and MFA through your identity provider protects new logins. Neither stops a session cookie that was stolen after login, and neither covers employees using personal accounts for work. Combine SSO with session revocation, device hygiene, and continuous stealer log monitoring.
Q: What should an employee do if their AI account was in a stealer log?
A: Stop using the infected device for any login until it is cleaned or reimaged. From a clean device, log out all sessions in every AI service and change passwords for every account that was saved in that browser, including personal ones. Then review the AI account's history, memory, connected apps and API keys for anything sensitive or altered, and report it to the security team.
Q: Is a stolen AI login a reportable security incident?
A: It can be. It depends on what the session and the infected device could reach. If conversations held personal data, or the same log held access to work systems, notification duties may apply: six hours for reportable incidents under CERT-In's directions in India, 72 hours under GDPR, and 72 hours for material incidents under APRA CPS 234. Take legal advice early, because these clocks start at awareness.