Stolen Claude cookies bypass SSO and 2FA — what to do

By Lazar Milicevic · Published September 3, 2026 · 10 min read

Your developer logs into Claude on their laptop, closes it, and walks to lunch. Two hours later, an infostealer that hitched a ride in a fake VS Code extension quietly exfiltrates their session cookies to a Telegram channel. By the time anyone notices, an attacker in another country is prompting Claude against your internal docs — through the same paid seat, from a fresh browser, without ever seeing your 2FA prompt or your SSO login page. There is no admin console you can open to kill that session, because there is no admin console.

This is the shape of the Claude session-cookie theft pattern Anthropic and downstream security researchers have been flagging in threat reports: infostealers scraping browser session storage, replaying the cookies into paid but self-serve accounts, and using the account's connectors — including Gmail, Drive, and GitHub grants — as a foothold. If you run AI automations for a small team, this is the threat model you actually have. Not "prompt injection in the abstract." Cookie replay against a seat no IT admin governs.

What actually happens in a Claude cookie replay

Short answer: an infostealer copies your browser's Claude session cookies to an attacker, who pastes them into their own browser and is instantly logged in as you — no password, no 2FA, no SSO challenge — because the server only sees a valid session token. Session cookies are bearer tokens. Whoever holds them is the user, until the token expires or is explicitly revoked server-side.

The chain is boring and well-documented:

1. User installs something dodgy — a cracked tool, a lookalike browser extension, a "free" Electron app, a poisoned npm postinstall script.
2. Infostealer malware (RedLine, Lumma, StealC, Vidar and their many clones) walks the profile directories of Chrome, Edge, Brave, and Firefox.
3. It decrypts cookie stores using the local DPAPI key (or the equivalent on macOS/Linux), grabs saved passwords, autofill data, crypto wallets, and browser session cookies.
4. The archive lands in a Telegram bot or a stealer marketplace within minutes.
5. A buyer imports the cookies into an anti-detect browser that also spoofs the user-agent, timezone, and canvas fingerprint. Claude sees a returning session.
6. The buyer opens Claude, opens the connected Gmail or Drive tool, and starts prompting.

The critical detail: none of the classic account-security controls fire. 2FA runs at login. SSO runs at login. A replayed session bypasses login entirely. The only defense left is server-side session invalidation — and on self-serve, card-billed Claude seats, the only person who can trigger that is the compromised user themselves, assuming they even notice.

Why SSO and 2FA don't help here

SSO's real value is centralized login — plus centralized offboarding. When a company routes Claude through Okta, Entra, or Google Workspace, an admin can disable the identity and, on the next auth challenge, the user is out. What SSO does not do is reach into an already-issued session cookie sitting on the user's laptop or on an attacker's machine. That cookie was minted by Claude's own session service. It will keep working until:

• It hits its natural expiry (session cookies can live weeks or months).
• The user manually clicks "log out of all sessions" in Claude's account settings.
• Anthropic invalidates it server-side (which they will do for confirmed compromise, but only reactively).

2FA is the same story, one layer down. A TOTP or hardware key proves who is logging in right now. It doesn't sign every subsequent request. Once the session is created, the cookie is the proof.

This is not unique to Claude. Every SaaS with long-lived session cookies has the same exposure. What makes the Claude case sharper for SMBs is the population of accounts under attack: self-serve, card-billed seats. There is no tenant admin. Nobody can force a global sign-out. Nobody sees the audit log because there isn't one exposed to a customer admin. The user is the tenant.

The Gmail connector is the real prize

Claude's connectors — Gmail, Google Drive, GitHub, and the growing MCP ecosystem — are what make cookie theft go from "annoying" to "material breach." A replayed session inherits every grant the real user already approved. That means an attacker with the cookies can:

• Ask Claude to summarize the last 30 days of your inbox, including the password-reset emails you thought were "just Gmail."
• Search Drive for anything matching "api key" OR "aws_secret" OR "stripe".
• Pull down the contents of private GitHub repos the user has granted read access to.
• Draft and — depending on the connector's write scope — send email as the user.

The OAuth grants those connectors rely on are stored on the Claude side, tied to the account, refreshed silently. Revoking them requires either the user opening their Google account, going to Security → Third-party access, and killing the grant, or Anthropic-side revocation. Your corporate IT admin cannot see or revoke a grant that a user personally issued from a personal-looking claude.ai account.

If that account has been paying with a corporate card but was never provisioned through SSO, it is functionally shadow IT with your production data one prompt away.

The seat population Anthropic keeps flagging

Enterprise Claude tenants provisioned through Anthropic's org plans have admin-side session controls, seat management, SCIM, and audit exports. That's not the population getting hit.

The compromised accounts in the public reports have a consistent profile:

If you are a 4-person startup that swiped a corporate card for three Claude Pro seats and connected Gmail to each, you have the second column. You have shadow IT with production credentials, and no lever to pull when one laptop gets popped.

A concrete hardening checklist for SMBs

Do these in order. The first three cost nothing and take an afternoon.

1. Inventory every AI seat billed to a company card. Pull the last three months of statements. For every AI vendor (Claude, ChatGPT, Cursor, Perplexity, v0, whatever), list the human, the plan, the email used, and whether it's SSO-backed. Anything self-serve on a personal-looking email goes on a migration list.

2. Kill long-lived sessions on a schedule. Have every user open their Claude account settings and click "log out of all other sessions" weekly. It is crude but it works. Put it in the same recurring calendar reminder as password-manager check-ins.

# Rough script to remind humans; the actual click is manual.
# Run from a shared ops repo.
gh issue create \
  --title "Weekly: log out all Claude sessions (everyone)" \
  --body "Open claude.ai → Settings → Sessions → Log out of all other sessions. Reply here when done." \
  --assignee @team

3. Audit every connector grant. For each user, open Google Account → Security → Third-party apps with access, and confirm which grants Claude actually needs. If a user connected Gmail six months ago for one experiment, revoke it. Same for Drive, same for GitHub OAuth apps.

4. Move to organization plans as soon as spend justifies it. The moment you have three or more paid Claude seats on company money, you should be on a plan that supports SSO and admin session control. The line is not "when we're big enough." The line is "when a compromised cookie could reach production data." For most SMBs, that's day one.

5. Lock down the endpoint, not just the account. Infostealers land through installed software. The controls that matter are the ones your team probably already has and hasn't turned on:

• Chrome/Edge managed profiles with extension allow-lists.
• OS-level EDR (Defender for Business is fine for most SMBs; the built-in Windows one is not).
• Block execution from %APPDATA% and %LOCALAPPDATA% where possible.
• Full-disk encryption enforced by MDM.
• Auto-lock at five minutes.

6. Treat every OAuth scope as production credentials. When a user clicks "Allow" on a Gmail connector, they are issuing a credential that lives outside your identity provider. Write that down in your risk register. Review it quarterly.

Detecting a replayed session before it hurts

You cannot see Claude's server-side session logs on a self-serve account. What you can see is downstream evidence in the connected services. That's where detection lives.

For Google Workspace:

# Alert conditions to configure in Google Workspace Alert Center
- name: Suspicious third-party OAuth activity
  trigger: OAuth token used from a new country within 24h of last use from home country
- name: Anthropic/Claude connector volume spike
  trigger: More than N Gmail API reads by "Claude" client in a 1-hour window
- name: Drive search bursts via API
  trigger: Drive search API called >50x in 10 min by third-party OAuth client

For GitHub:

# Weekly: list every OAuth app authorized against the org
gh api /orgs/YOUR_ORG/credential-authorizations \
  | jq '.[] | {login, credential_type, credential_authorized_at, scopes}'

If you see a Claude-connected OAuth token being used from an IP or ASN that doesn't match the user's laptop, you have a replay. Kill the grant from the provider side (Google/GitHub), then have the user reset their Claude password and force-logout all sessions. The provider-side revoke is the fast path — it invalidates the grant without needing Anthropic in the loop.

When you're building agents on top of Claude, not just chatting with it

If your team is going beyond the Claude web UI and building agents — MCP servers, Claude Code workflows, background automations — the blast radius question changes shape. Now the credential that could leak is not just a session cookie but an API key, and the connectors are not OAuth grants a user clicked but MCP servers you wrote and deployed.

The same principles apply, harder:

• Scope every MCP server to the minimum useful surface. If the agent only needs to read one Gmail label, don't grant it gmail.readonly on the whole mailbox — build a narrow server that exposes only that label.
• Never let an agent hold a long-lived credential you can't rotate in one command. Every secret goes through a vault with a documented rotate path. Test the rotate path.
• Log every tool call from every agent, immutably. If a key leaks, the log is how you know what the attacker touched.
• Isolate agent runtimes. An agent that can read production email should not run on the same box as a developer's daily-driver browser. Put it in a container, on a machine, in an account, with no other purpose.
• Kill the account, not just the session. For programmatic access, prefer service accounts you can nuke without disrupting a human.

The .mcp.json for a scoped Gmail reader looks less like "give Claude Gmail" and more like:

{
  "mcpServers": {
    "gmail-support-inbox": {
      "command": "node",
      "args": ["./servers/gmail-support-inbox.js"],
      "env": {
        "GMAIL_SCOPE": "labelId:Label_SupportTickets",
        "GMAIL_MODE": "read-only",
        "TOKEN_SOURCE": "vault://mcp/gmail-support"
      }
    }
  }
}

That server exposes exactly two tools — list_tickets and get_ticket_body — and nothing else. If its token leaks, the attacker reads your support tickets, not your CEO's inbox.

How BizFlowAI approaches this

Most of what we ship for SMB clients running Claude-based automations is not the agent itself — it's the boring plumbing around it. Scoped MCP servers that expose one verb, not a whole API. Grant registers that document which OAuth scopes exist, who approved them, and when they get rotated. Audit pipelines that stream every tool call into a log the client actually owns. And a session-hygiene playbook their team can follow without an IT department.

If you have Claude seats on a company card, connectors wired into Gmail or Drive, and no clean answer to "what happens when a laptop gets stolen," that's the conversation we have on a discovery call. We'll walk your current setup, flag the grants that are actually load-bearing, and give you a written remediation plan — whether you end up hiring us to build it or not.

The uncomfortable summary

Session-cookie replay is not a Claude bug. It's how the web has worked for twenty years, and it applies equally to every SaaS your team uses. What makes the Claude case worth pulling into a full post is the combination: (1) self-serve paid seats bought on corporate cards, (2) powerful OAuth connectors granted by users, and (3) no admin lever to force a global sign-out when things go wrong.

The fix is not clever. Move real work onto organization plans with SSO and admin session control. Treat every connector grant as a production credential in your risk register. Audit the endpoint that holds the cookies, not just the account they authenticate. And if you're building agents on top of Claude, scope every MCP server and rotate every secret like you already know it will leak — because eventually one of them will.

Work with BizFlowAI

If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.

Book a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.

More guides like this on the BizFlowAI blog.