Infostealers Are Hijacking Claude Sessions to Drain Usage

The account owner was asleep. The usage meter was not. Anthropic found paid limits refilling and then draining on accounts whose owners were doing nothing at all, traced it to malware on those users' own machines, and started killing sessions and stripping saved payment methods. Its notice was blunt about the origin: "We have no reason to believe that this malware is related to Claude, installed through Claude, or related to anything you did with Claude."

The interesting part is not the theft. It is what got stolen: not a password, not a recovery code, but the cookie proving you had already presented both.

Key Takeaways

• Anthropic disclosed on 30 August 2026 that infostealer malware harvested live Claude browser sessions and used them to spend victims' paid usage.
• The named families are Vidar, Lumma (LummaC2), StealC, RedLine and Acreed on Windows, plus Atomic Stealer (AMOS) on a small number of Macs.
• Because the stolen artifact is an authenticated session cookie rather than a password, two factor authentication is never challenged.
• Anthropic signed sessions out, removed saved payment methods and refunded unauthorized charges, but warned that "Signing you out of Claude stops the stolen sessions, but it doesn't remove the malware."
• Chrome 146 made Device Bound Session Credentials generally available on Windows in April 2026, binding sessions to a TPM held key that malware cannot export.

What Actually Happened to Claude Accounts?

Attackers replayed stolen browser sessions to sign in as paying Claude users and burn their metered usage. The families involved are ordinary commodity stealers sold on criminal markets, not anything purpose built: BleepingComputer's report names Vidar, Lumma, StealC, RedLine and Acreed on Windows, and Atomic Stealer on a smaller set of Macs.

The remediation ran on three tracks: invalidate the hijacked sessions, delete saved payment methods so a hijacked account could not buy more credits, and refund confirmed fraudulent charges. Then came the uncomfortable half, as Help Net Security summarised: remove the malware, secure the email account tied to Claude, rotate every password the browser had saved, and invalidate sessions on every other service used from that machine.

That last instruction is the one people skip, and the one that matters. The infection was never Claude specific. Claude is only where the billing signal was loud enough to notice.

Why Does a Stolen Cookie Defeat MFA?

Because multi factor authentication guards the moment a session is issued, not every moment it is used. You prove who you are once, the server hands your browser a bearer token in a cookie, and from then on the token is the identity. NIST's digital identity guidelines treat that session secret as a credential in its own right. Copy it to another machine and that machine is you.

Nothing re examines the request afterwards. There is no second challenge on the thousandth API call, no device attestation, no re proof. A hardware key changes who can start a session; it does nothing about who can carry one that already exists. We took the same mechanism apart when Storm's operators moved decryption off the victim's machine entirely.

What Does the Malware Actually Grab?

It grabs the browser's local state: the cookie database, the saved password store, autofill data, and the token files desktop applications leave on disk. On a Chromium profile that means the SQLite files holding cookies and login data, plus the key material used to unwrap them. Google is candid about the limit in its case for Device Bound Session Credentials: once malware runs as you, it can read the files and memory where the browser keeps authentication cookies.

Two properties keep the haul valuable long after the machine is cleaned. Cookies outlive passwords, because rotating a password does not invalidate an existing session unless the service explicitly revokes it, and plenty do not. And the log itself is a product, packaged and resold, so theft and abuse can be months and several owners apart. This is the same collection routine that filled the 24 billion credential infostealer dump. What changed is what buyers now do with the cookie half of it.

Why Are AI Subscriptions Suddenly Worth Stealing?

Because metered compute is the rare stolen good that needs no fence. A stolen card has to be cashed out through a mule or a reshipper, and every hop loses value and adds risk. A hijacked Claude session is already the product: the attacker consumes the compute, the plan owner pays the bill, and nothing has to be converted into money to be worth having.

It fits a trend rather than starting one. Six months earlier the same commodity stealers were being retooled to hunt private keys and API tokens belonging to AI agents running on developer machines. February went after the builders. August went after the subscribers.

The abuse runs in the other direction too. Anthropic later documented threat groups using Claude to sift hardcoded secrets out of 1.8 million Android apps, turning a slow triage job into an industrial pipeline.

What This Means for Your Inbox

Your webmail session sits in the same cookie jar, and it is worth more than a month of AI credits. Gmail sessions are deliberately long lived so you are not signing in every morning, which means one sweep of a Chrome profile can yield a token that opens the inbox for weeks. Reading mail, unlike burning compute, leaves no bill to notice.

The inbox is also the recovery root for everything else. Whoever holds a live mail session can trigger password resets on your other accounts, read the links, and delete the notifications before you see them. That is why stealer logs keep surfacing with mail credentials attached, as in the 48 million Gmail logins found in an infostealer database. If a stolen cookie works against Claude, it works against Gmail, Outlook and Yahoo Mail. Nothing in the technique is product specific.

Theft is not the only way an assistant session ends up working for someone else, either. Check Point later showed that a planted prompt could make ChatGPT read a victim's Gmail and ship it to another account with no cookie stolen at all, using a shared internal package server as the covert channel.

How Would You Detect a Hijacked Session?

You look for your account doing things while you are not there. Anthropic's own tell was consumption without a human, and the equivalent signals exist on services you already use:

• Usage that does not match you. Quota drained overnight, rate limits hit on a day you did not work, credits you never bought.
• Sessions from unfamiliar places. Gmail's Details panel, bottom right of the inbox, opens the recent activity view listing concurrent sessions, access type and the IP addresses that reached your mailbox.
• Mailbox changes you did not make: new forwarding addresses, filters that archive or delete, unfamiliar app passwords or OAuth grants.

One caveat, plainly. A hijacked session generates no failed login, no MFA prompt and no new device alert, because from the server's point of view nobody logged in. Detection here is behavioural, not authentication based.

What Should You Actually Do?

Order matters more than usual, because anything you rotate before the malware is gone gets stolen again. Anthropic put it in one line: signing you out stops the stolen sessions, but it does not remove the malware.

1. Clean the machine first. Full scan with a reputable tool, and wipe and reinstall if the infection route is unclear.
2. Secure the email account before anything else. New password, second factor on, sessions revoked. It is the recovery root.
3. Sign out everywhere. Look for revoke active sessions or the device list, since a password change alone often leaves live sessions running.
4. Rotate every password the browser had saved, not only the ones you think mattered, as the REMUS campaign against password manager extensions showed.
5. Check payment methods and statements on any account storing a card, and remove the cards you do not need on file.
6. Stop installing unsigned software, and turn on full disk encryption. These families arrive through cracked applications, fake installer pages and paste this command lures, not exploits.

The Real Fix Is Structural

None of that changes the design flaw, which is that a session cookie is a bearer token any machine can present. Device Bound Session Credentials stop it being one: Chrome generates a key pair at login, keeps the private key in secure hardware such as a TPM where it cannot be exported, issues a short lived cookie, and signs a server challenge to renew it. The Chrome documentation works through an example where that cookie expires after ten minutes. Steal it and you have ten minutes and no way to renew.

Google shipped it broadly on Windows with Chrome 146 in April 2026, with macOS support flagged for a later release. It only works when a site implements the registration and refresh endpoints on its own backend. Until the services you care about do, the session model stays as portable as it was on the day Anthropic started signing people out.

Sources: BleepingComputer: Anthropic warns infostealer malware is hijacking Claude sessions to drain usage; Help Net Security: Anthropic locks out Claude users after infostealers hijack login sessions; Google Security Blog: Protecting Cookies with Device Bound Session Credentials; Chrome for Developers: Device Bound Session Credentials; NIST SP 800-63B: Digital Identity Guidelines; Google: Gmail last account activity. Anthropic's notice was sent directly to affected users; quotes are as reported on 30 and 31 August 2026.