Stolen Claude sessions show why session tokens outlast passwords

At a glance

What this is: This is an Anomali Cyber Watch item showing how stolen Claude session cookies let attackers bypass passwords and MFA after the initial login had already occurred.

Why it matters: It matters because IAM teams, NHI owners, and identity architects need to treat session validity as a separate control plane from authentication, especially when stolen tokens can outlive the credential that created them.

Context

Session tokens are the post-login proof that a user or service is still authenticated. When an attacker steals that token from an infostealer-infected endpoint, they can reuse the existing session without replaying the password or MFA challenge that created it.

For identity programmes, the governance gap is simple: many controls terminate credentials but do not fully terminate sessions. In environments where browser cookies, saved logins, and local credential stores are exposed, session revocation and device hygiene become part of access governance, not just incident response.

Key questions

Q: What breaks when an attacker steals a browser session instead of a password?

A: Password resets and MFA checks may never fire, because the attacker is already inside an authenticated session. That means cloud and SaaS activity can look normal while the attacker exfiltrates data or changes settings. Teams need controls that monitor token reuse, browser anomalies, and session-level privilege.

Q: Why do stolen tokens often survive password resets and MFA changes?

A: Because tokens are issued after authentication and often remain valid independently of later password or MFA updates. Unless the organisation revokes the token itself, the attacker can continue using the bearer credential until it expires or is explicitly invalidated. That is why token lifecycle control matters more than login hardening alone.

Q: What are the signs that stolen-session replay is happening?

A: Look for account activity while the legitimate user is idle, unexpected quota or usage consumption, new activity from familiar sessions, and changes that do not line up with normal login behaviour. Those signals often indicate token replay rather than fresh credential compromise.

Q: How should organisations respond after a session token is confirmed stolen?

A: Immediately invalidate the active session, check whether other sessions for the account are still alive, and clean the endpoint that leaked the token. Then review payment methods, OAuth connections, and any linked identities that could still be trusted through the same account context.

Technical breakdown

How stolen session cookies bypass password and MFA controls

A session cookie is a bearer token that tells the service a login already happened. If malware extracts that cookie from a browser or local profile, the attacker can impersonate the user until the session expires or is explicitly revoked. Password resets do not invalidate every active session in all systems, so the attack path stays open unless the service ties token validity to revocation events. That makes the session layer a distinct trust boundary from the primary authentication event.

Practical implication: treat active session inventory and forced token revocation as separate controls from password resets.

Why infostealers turn endpoint compromise into cloud-session reuse

Infostealers such as Vidar, Lumma, StealC, RedLine, Acreed, and Atomic Stealer are built to harvest browser cookies, saved passwords, and local credentials at scale. They do not need to understand the target service to be effective. Once stolen session material is replayed, the attacker inherits the original access context, including any subscription privileges or payment-linked entitlements. That is why endpoint compromise can become account abuse even when MFA remains enabled.

Practical implication: scope endpoint hygiene and credential theft detection as upstream identity controls, not just malware response.

Why token revocation must outlast credential revocation

Identity systems often assume the login event is the moment to defend, but modern services also need controls for the session life cycle. If a token remains valid after the account password changes, the attacker can persist inside the account even though the primary secret has been replaced. Good design therefore couples revocation, device trust checks, and session re-authentication triggers so that stolen tokens do not survive administrative response. In practice, the failure is not authentication alone, but incomplete session termination.

Practical implication: validate that your identity stack can revoke active sessions, not just reset credentials.

Threat narrative

Attacker objective: The attacker aimed to hijack valid Claude access for account abuse and paid-usage consumption without needing fresh authentication.

1. Entry occurred on infostealer-infected endpoints where malware harvested browser cookies and saved credentials from Windows and some Mac systems.
2. Credential access came from stolen session cookies, which allowed the attacker to reuse an already authenticated Claude session without needing the password or 2FA code.
3. Impact followed when the attacker consumed paid usage until Anthropic invalidated the compromised sessions and removed saved payment methods.

Breaches seen in the wild

• NVIDIA code-signing certificates stolen 2022: Lapsus$ leaked two NVIDIA code-signing certificates; Windows still trusted them for drivers and attackers signed Cobalt Strike and Mimikatz with them.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Session trust has become the real control boundary: this incident shows that authentication success no longer equals secure access once session material is stolen. Passwords and MFA still matter, but they sit upstream of the token boundary that actually governs continued use. Practitioners need to treat the session as the security object that must be governed, because an attacker who already owns a valid token has bypassed the login ceremony entirely.

Stolen session cookies are an NHI problem as much as a human IAM problem: the same replay logic that affects consumer accounts also affects service portals, developer platforms, and AI subscriptions that depend on browser-based sessions. The governance lesson is not limited to one product. Any programme that does not inventory where bearer sessions are issued, stored, and revoked will overestimate the protection provided by MFA alone.

Session lifecycle control must be explicit, not assumed: password reset workflows, MFA prompts, and account recovery processes do not automatically terminate every active session. That is a governance assumption designed for short-lived or tightly bound sessions, and it fails when tokens remain reusable after compromise. The implication is that identity architecture has to model token revocation, device trust, and session expiry as first-class controls rather than administrative afterthoughts.

Bearer-token persistence: the most important lesson here is that a stolen session can outlive the credential that created it by hours or days. That persistence window is what turns infostealer infection into durable account misuse, and it is why revocation depth matters more than login hardening alone. For practitioners, the question becomes whether their identity stack can actually invalidate the thing the attacker is using.

Claude access illustrates the emerging value of session reuse in AI services: when paid AI accounts can be consumed through stolen live sessions, the identity risk expands beyond data access into usage theft and trust abuse. This is not a novelty case. It is a practical signal that AI service accounts need the same token governance discipline long applied to high-value workforce and machine identities.

From our research library:

• Patching addresses only about 10% of privilege escalation techniques, while privilege management covers about 65%, according to Verizon's 2026 Data Breach Investigations Report.

What this signals

Bearer-token governance is now a mainstream identity problem: when sessions can be replayed independently of passwords, identity teams need visibility into where tokens are issued, stored, and revoked. The practical shift is from login-centric thinking to session-centric control design, especially for web-based AI services and other high-value portals.

This case also reinforces a broader NHI pattern: the access object an attacker wants is often not the password at all, but the live session that already carries trust. That is why token termination, device hygiene, and usage monitoring belong in the same governance conversation.

For practitioners

• Map session revocation coverage Verify which identity systems can invalidate all active sessions after compromise, and which only change passwords or reissue credentials. Focus on browser-based sessions, long-lived cookies, and admin consoles where token reuse can survive a login reset.
• Inventory token-bearing access paths Identify every place where browser cookies, refresh tokens, and saved credentials can be replayed after endpoint theft. Prioritise high-value accounts and AI service portals where valid sessions can be monetised or abused.
• Harden endpoint exposure to infostealers Treat unmanaged downloads, malicious installers, and browser-profile theft as identity threats, not just endpoint malware. Enforce device hygiene controls on the endpoints that store the session material your users rely on.
• Separate password resets from token termination Make sure incident playbooks explicitly call for session invalidation, not only password rotation and MFA re-enrolment. A compromised token can keep working after those steps unless the service actually kills the live session.
• Monitor for abnormal usage patterns Watch for consumption spikes, idle-account activity, and payment or quota drain that signal session replay rather than interactive use. Those patterns often surface before a user reports direct account loss.

Key takeaways

• The incident shows that stolen session tokens can outlast passwords and MFA, so authentication controls alone do not stop account reuse.
• Anthropic said attackers reused active Claude sessions from infostealer-infected devices and drained paid usage before the sessions were invalidated.
• The control gap is session termination, not just credential reset, which means identity teams need explicit token revocation and endpoint cleanup procedures.

Key terms

• Session Token Exposure: Session token exposure occurs when authentication tokens or session artifacts are stored, transmitted, or logged in places they should not be. Once exposed, they can function like reusable credentials. This makes them part of identity and access risk, not only application behaviour.
• Bearer token replay: Reuse of a captured token by an attacker to make authorised-looking API calls. The token may still be structurally valid, which is why replay prevention depends on path integrity, short lifetimes, and context-aware enforcement rather than token format alone.
• Infostealer: An infostealer is malware built to collect credentials, session material, tokens, and other authentication data from infected systems. In NHI programmes, the risk is not only theft but reuse, because harvested workload secrets can unlock cloud access long after the initial infection.
• Session revocation: The ability to invalidate active sessions so access ends immediately instead of waiting for tokens or browser state to expire. For identity governance, this is the control that determines whether authentication still matters after a compromise is detected.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.