Claude Session Hijacking: What the Anthropic Infostealer Wave Means for MFA and SaaS Security

What Happened

In late August 2026, Anthropic began locking out Claude accounts after detecting that infostealer malware was hijacking active login sessions to drain usage on victims' accounts [3]. The company confirmed the compromise was widespread enough to warrant a public warning, and follow-up coverage detailed how the malware operates: it doesn't guess passwords or phish for credentials, it steals the session cookie sitting on an already-infected device and replays it to impersonate a logged-in user [1][4][6].

The scale here matters less than the mechanism. Multiple outlets reported the same pattern: commodity infostealers, the kind that have quietly harvested browser data for years, are now treating AI platform sessions as a first-class target because a hijacked Claude session is valuable on its own and often opens doors well past the AI tool itself [8][12][13]. VentureBeat's reporting added the detail that should worry every MSSP reading this: stolen Claude session cookies can reach corporate Gmail through OAuth-style grants that no IT admin can revoke on their own, because the grant lives outside the identity provider's normal reset flow [11].

That's the part worth sitting with. This isn't a Claude problem. It's a preview of what happens to every SaaS platform your clients run once infostealers start treating session tokens as the primary payoff instead of a bonus.

Why Session Cookies Beat MFA Outright

Multi-factor authentication protects the login. It does nothing for the session that comes after the login. Once a user authenticates, the browser holds a cookie or token that says "this device is already verified, stop asking." An infostealer that lifts that cookie from disk doesn't need the password, the authenticator app, or the push notification. It needs the file, and it replays it somewhere else entirely [4][6].

That's why this class of attack has become the preferred move for infostealer operators. Credential phishing has to beat MFA in real time, which is increasingly hard now that push-bombing and OTP relay are well understood defensively. Cookie theft skips the fight altogether. The attacker isn't trying to get past the bouncer. They're using a wristband someone already stamped [7][9].

The Claude wave is a clean case study because Anthropic's own telemetry showed the tell: usage draining from accounts in patterns that didn't match the account owner's normal behavior [10][16]. That's the signal. The question is who's watching for it, and how fast they act once they see it.

The Anthropic Response, and Its Limit

Anthropic's answer was to detect anomalous usage and lock the affected accounts [3][10]. That's a reasonable move for a vendor protecting its own platform, and it's the same playbook most SaaS providers run: watch for abuse patterns, then cut access once the pattern is confirmed.

The limit is structural, not a failure of effort. Vendor-side lockouts are, by design, reactive. They fire after usage has already been consumed, after the session has already been ridden somewhere. Anthropic can only lock what it can see, and it can only see activity inside its own platform. It has no visibility into the infected endpoint that stole the cookie in the first place, and it has no way to know whether that same stolen session is also sitting in a browser tab open to a client's email, file storage, or admin console [11].

That gap, between "the vendor noticed after the fact" and "the attacker was already inside adjacent systems," is exactly where a partner's own security operations needs to be doing something the vendor structurally cannot.

What This Means Beyond Claude

Every SaaS platform your clients rely on, CRM, ticketing, cloud storage, collaboration suites, runs on the same session model. A user logs in once, gets a token, and that token rides along until it expires or gets revoked. If an infostealer is already living on that user's endpoint, it doesn't care which SaaS app it's stealing sessions from. Claude just happens to be the one making headlines this month because Anthropic was transparent about the scale of it [1][5][14].

The OAuth-grant detail from VentureBeat is the sharpest warning in the whole story: a stolen session doesn't stay contained to the app it was stolen from [11]. Modern SaaS ecosystems are threaded together with delegated access, single sign-on, and app-to-app grants. A hijacked session in one platform can be a hijacked session in three others, and none of those downstream compromises show up in the original vendor's lockout dashboard.

What a Partner Should Actually Do

For MSSPs and MSPs fielding client questions about this right now, the useful response isn't "we don't use Claude so we're fine." It's a check across the client's actual SaaS footprint:

• Audit standing OAuth grants and delegated access. Find out which third-party apps have persistent access into email, storage, and identity, and confirm someone can actually revoke those grants without a vendor ticket.
• Push infostealer detection to the endpoint, not just the login. Password managers and MFA don't see malware harvesting a browser's session store. EDR does.
• Treat session anomalies as a detection category, not an afterthought. Impossible travel, a new device fingerprint on an established session, and concurrent sessions from geographically distant IPs are all signals that a token has been copied, not just used.
• Shorten session lifetimes where the platform allows it. A shorter-lived token gives a stolen cookie a smaller window to be useful.
• Have a revocation path that doesn't depend on the SaaS vendor noticing first. If your only containment plan is "wait for the platform to lock the account," you're on Anthropic's timeline, not yours.

Where Vijilan Fits: Catching the Ride, Not Just the Alert

Anthropic's lockout model is reactive by necessity. It watches usage inside its own platform and acts once the pattern confirms abuse, which means the token has already been used before anyone steps in. That's not a criticism of Anthropic, it's the ceiling of what any single SaaS vendor can do from inside its own walls.

Vijilan's Global SOC is built to sit underneath that ceiling. Our analysts pair endpoint telemetry, the layer that actually sees an infostealer land and start harvesting browser session data, with session-anomaly detection across the identity and SaaS layer: impossible travel, device mismatch, and concurrent sessions on an account that should only ever have one. That combination is what turns "a token was stolen" into "we caught the infostealer on the endpoint and revoked the session before it reached anything downstream," instead of finding out weeks later that a stolen cookie had been quietly walking through a client's inbox and cloud storage.

Working through ThreatRespond™, our Managed XDR service, that correlation runs continuously across the platforms clients actually use, whether that's Microsoft Entra and Defender, Okta, or CrowdStrike Falcon-monitored endpoints, not just the one SaaS vendor that happened to publish a warning this week. For MSSPs building this into their own service stack, ThreatRespond can run white-label under your brand, and we never compete with our partners for their clients.

Session hijacking isn't a Claude problem. It's the current shape of credential theft, and it's not going away because one vendor tightened its lockout logic. The partners who get ahead of it are the ones treating session anomaly detection as core coverage, not a future roadmap item.

Questions about how this fits your stack? Visit /msp to talk to our team, or check /pricing for program details.

Frequently asked questions

Does MFA protect against this kind of session hijacking?

No. MFA protects the login step. Once a user authenticates, the session token or cookie that follows is what an infostealer targets, and replaying a stolen session bypasses MFA entirely because the session is already marked as verified.

Is this attack specific to Claude or Anthropic?

The malware and technique are not specific to Claude. Anthropic's disclosure made the pattern public, but the same infostealer-to-session-theft path works against any SaaS platform where a stolen cookie can be replayed.

Can a stolen session token reach systems beyond the app it was stolen from?

Yes. Reporting on this wave noted that stolen Claude session cookies could reach connected systems like corporate Gmail through delegated access grants that IT admins couldn't easily revoke, which is why containment needs to cover the broader SaaS estate, not just the originally affected app.

What should an MSSP tell clients asking about this today?

Focus on what's actionable: audit standing OAuth grants, confirm infostealer detection runs at the endpoint, and make sure session anomalies (impossible travel, device mismatch, concurrent sessions) are an active detection category rather than something only the SaaS vendor watches for.