What a Stolen AI Login Actually Buys an Attacker - and How Long It Stays Usable
What a Stolen AI Login Actually Buys an Attacker — and How Long It Stays Usable
Updated September 26, 2026. Every number below was read on that date from the pages listed at the end: vendor documentation, NIST publications, the OWASP session-management cheat sheet and the FBI's annual crime report. No security-vendor marketing figures and no prices are used.
Start with what the vendor actually published, because the popular version overshoots it
The story that circulated in late August 2026 was that infostealer malware had begun hijacking Claude browser sessions to burn through people's paid usage. Anthropic's own threat-intelligence report for September 2026, which covers activity from December 2025 through August 2026, supports a narrower claim than that. It states that access to AI — in the form of compromised API keys, session tokens and devices — has increasingly become the objective of criminal groups in its own right. It then documents specific cases.
One of them is close to the popular story. A group Anthropic tracks as GTG-50021 ran a fake discount reseller, advertising cheap Claude access. Customer traffic was quietly proxied to a different model entirely, and the reseller's own tooling installed a credential harvester that took the customer's Anthropic account credentials and resold them. That is malware stealing AI account credentials, and it is first-party documented.
What is not documented anywhere first-party is the specific mechanism the headlines named. The report's token-theft cases concern API keys and enterprise identity tokens taken out of organisational environments, not session cookies lifted from an individual's browser. In the case Anthropic describes for GTG-50014, every API key involved was stolen from customers' own environments, and Anthropic states its own systems were not compromised. One stolen key was used for secondary attacks for roughly three weeks. In a separate burst the same actor collected more than 2,100 Azure AD token sets across more than 40 corporate tenants in about 34 hours.
So the honest version is: credential theft against AI accounts is real and documented; consumer session-cookie hijacking against Claude specifically is not. That distinction matters, because the two problems have different fixes, and only one of them is yours to fix.
Four published numbers decide how much a stolen login is worth
The value of a stolen credential is not a feeling. It is a product of four things a vendor publishes: how long the session lives, how much the plan lets you consume in that time, how quickly revocation takes effect, and how many steps revocation takes. Anthropic publishes three of the four.
Its support documentation states that a Claude account session lasts 28 days of inactivity, and that the session is refreshed on any action taken on claude.ai — the page describes the refresh as running from every hour out to 28 days. The Pro plan is documented at 20 US dollars per month with a session-based usage limit that resets every five hours, plus a weekly limit across all models. Max is documented at 100 dollars per month for five times the Pro per-session allowance and 200 dollars per month for twenty times it.
Twenty-eight days, converted into something countable
Twenty-eight days is 672 hours. Set against the published five-hour reset window, an unnoticed session spans about 134 complete usage windows (672 divided by 5 = 134.4), and crosses four weekly limit cycles. That is the real-use meaning of the session length: not "a long time", but roughly 134 separate refills of whatever the plan allows, on someone else's subscription, before the session would have expired on its own.
Anthropic does not publish an exact message count for Pro. Its own wording is that the number of messages varies with message length, so any per-plan message figure you see quoted is somebody's estimate, not a published spec, and this article does not print one.
| What expires | Published lifetime | Published by |
|---|---|---|
| Claude account session, idle | 28 days (refreshed on activity) | Anthropic support |
| Access and identity tokens, recommended ceiling | no more than 1 hour | NIST IR 8587, final September 15, 2026 |
| Microsoft Entra access token, default | 60 to 90 minutes | Microsoft Learn |
| Same token with Continuous Access Evaluation | up to 28 hours | Microsoft Learn |
| Entra refresh token, maximum inactive time | 90 days, not configurable | Microsoft Learn |
| Reauthentication ceiling at AAL2 | should be 24 hours or less; idle 1 hour or less | NIST SP 800-63B-4, July 31, 2025 |
| Reauthentication ceiling at AAL3 | shall be 12 hours or less; idle 15 minutes or less | NIST SP 800-63B-4 |
| Idle timeout, high-value application | 2 to 5 minutes | OWASP cheat sheet |
| Absolute timeout, full-workday application | 4 to 8 hours | OWASP cheat sheet |
Read down that column and the 28-day figure stops looking like a normal number. It is 28 times the 24-hour absolute ceiling NIST suggests for AAL2, and 672 times the one-hour idle figure. It sits comfortably inside the AAL1 suggestion of no more than 30 days. Which of those two is the right yardstick for a paid AI account holding your work is exactly the question nobody has answered in public.
Three published ceilings, none of them the same number
It would be neater if the standards agreed. They do not, and the gaps are worth seeing rather than smoothing over.
NIST IR 8587, finalised on September 15, 2026 and co-authored with CISA, says access and identity tokens should be valid for no more than an hour. Microsoft's own current documentation says a CAE-enabled access token may run up to 28 hours. Both are 2026 documents from serious institutions and they are 28 times apart. OWASP is stricter than either for high-value applications, at 2 to 5 minutes idle, which is 12 to 30 times tighter than NIST's AAL2 idle figure and still 3 to 7 times tighter than AAL3.
Microsoft even disagrees with itself in a small way: one page gives the access-token default as 60 to 90 minutes averaging 75, another gives it as a flat hour. The gap is half an hour and it does not matter much, but it is a reminder that "the default" is a range, not a constant.
Which way should you err? Cheaply, in the direction of the shorter number. Shortening a session costs you a re-login; lengthening it costs you the difference between an hour of exposure and 672. When two institutions differ by a factor of 28, the expensive mistake is on the permissive side.
What revocation costs, counted in clicks and in latency
The other half of the calculation is how fast you can shut a session down, and how much work that is. Here the published figures are precise about steps and vague about time.
| Action | Published steps | Published effect |
|---|---|---|
| View active sessions on a Claude account | 3 | shows device, browser, IP-based location, last activity |
| Terminate one specific session | 4 | no propagation time stated |
| Log out of every session | 7 | described as immediate across all devices |
| Replace a compromised API key | 3 | described as immediate; no rotation interval published |
| Secure a compromised Google account | 3 main steps | 30-day window to confirm a recovery method |
| Sign a device out of a Google account | 5 | device list covers recent weeks, not a stated number of days |
The only measured revocation latency anyone publishes here belongs to Microsoft: with Continuous Access Evaluation, critical events such as a password reset or an administrator revoking refresh tokens propagate in near real time, with observed latency of up to 15 minutes. Ordinary policy or group-membership changes can take up to a day, sometimes optimised to two hours. Anthropic and Google both use the word immediately and publish no measured figure, which is not the same thing as a guarantee.
Three steps to see your sessions is the number that matters most in this table, because it is small enough to do now. Seven steps to end all of them is the number that matters when something is actually wrong.
A denominator for the risk, from the federal crime data
The FBI's Internet Crime Report for 2025, released April 6, 2026, recorded 1,008,597 complaints and 20.877 billion dollars in reported losses, up from 859,532 complaints the year before. The categories nearest to credential theft were personal data breach at 67,456 complaints and 1.31 billion dollars, phishing and spoofing at 191,561 complaints and 215.8 million dollars, and identity theft at 31,675 complaints and 185.8 million dollars. Malware as its own category was small: 893 complaints, 19.4 million dollars. Account takeover, discussed separately rather than as a table row, came to roughly 4,700 complaints and 359.7 million dollars.
Note what those numbers are and are not. There is no federal category called credential theft, so personal data breach is a proxy, not a measurement. And the FTC's most recent full Consumer Sentinel Data Book is still the 2024 edition, published March 2025, with 2,600,678 fraud reports, 12.54 billion dollars in losses and a median loss of 497 dollars. The 2025 FTC figures that get quoted — three million reports, 15.9 billion dollars — come from congressional testimony in March 2026, not from a Data Book, so they are not directly comparable with the audited 2024 set.
The engineering answer, in the words of the people shipping it
The reason session theft is a live topic in 2026 is that browsers are finally doing something structural about it. Google's Device Bound Session Credentials binds a session to a key pair held on the device, in secure hardware such as a TPM where one is available, so that a cookie copied off that machine is not usable elsewhere. Google announced public availability for Windows users on Chrome 146 in April 2026, with macOS to follow, and says it has seen a significant reduction in session theft for protected sessions — without publishing a percentage, which is worth noting before repeating the claim.
Microsoft's equivalent, token protection, accepts only sign-in session tokens cryptographically bound to a registered device. Its published availability is uneven: generally available for Windows 10 and later native apps, iOS 16 and later, macOS 14 and later, but still in preview for browsers. NIST IR 8587 recommends the same family of ideas — proof-of-possession, mutual TLS binding, device registration — so that a stolen token does not function off the device it was issued to.
The pattern across all three is identical, and it is the useful takeaway: the industry has stopped trying to keep the token secret and started trying to make a copied token worthless. That is a much better bet, and it is the reason to keep a browser current rather than to buy anything.
Tip: Because Anthropic documents only Google sign-in and email as login methods, the account that actually guards your Claude access is usually your Google account — and that one does support phishing-resistant keys. A FIDO2 security key is the category NIST names as phishing-resistant at AAL2. (These are Amazon Associate links — we may earn a small commission on qualifying purchases.)
Reading this as a decision instead of a scare
If the question is what to actually do this week, the published numbers point somewhere fairly boring. The 28-day session is the largest single exposure in the set, and it is the one thing on this list that a user can shorten unilaterally, in three steps, for free. Doing that once a month costs a re-login and removes 27 of those 28 days. Set against the alternative — 134 usage windows on a subscription somebody else is paying for — that is an unusually good trade, and it does not depend on believing any particular threat story.
The second thing is scoping, which is where Anthropic's documented cases actually live. If there is an API key involved, the published procedure is three steps and the guidance is to store the replacement in a secrets manager rather than in version control. Every documented key theft in that report came out of a customer environment, not out of the vendor. That is the part under your control.
The third is the least technical and the most effective: the one case that matches the popular story began with a discounted reseller. Buying model access at a discount from an intermediary is the step that installed the harvester. Nothing about session length or token binding helps with that. The same logic runs through the licensing fights now shaping how AI companies source and resell their inputs, where the cheapest channel is also the one with the least accountability.
What is missing from the public record, stated plainly
Four gaps are worth naming rather than papering over. First, Anthropic publishes no affected-user count, no dates and no remediation detail for the reseller case — the one case that supports the original headline is also the least quantified. Second, no government source publishes a dwell time or mean time to detection for this kind of compromise; the only elapsed-time figures available are the attacker-side durations in Anthropic's report, which are incident observations rather than statistics. Third, Anthropic's login documentation lists only Google sign-in and email, states that a dedicated password cannot be created, and mentions neither two-factor authentication nor passkeys for consumer accounts — that is an absence of documentation, which is not proof the feature is absent. Fourth, nobody publishes how long revocation actually takes to propagate at Anthropic or Google.
Five checks, in the order the numbers justify
- Open the active-sessions list (3 steps). Anything you do not recognise by device, browser or location is the whole point of the page existing.
- Log out of all sessions once a month (7 steps). This is the lever that turns 28 days of standing exposure into about one day of it.
- Check the Google account you sign in with, since that is the real credential. Confirm the recovery method is one you control, and note the published 30-day window for confirming a new one.
- If an API key exists, rotate it (3 steps) and move the replacement into a secrets manager. Keys in version control are the documented failure mode.
- Keep the browser current rather than buying anything. Device-bound sessions are the defence that makes a copied cookie useless, and they arrive by update.
None of this requires believing that malware is currently draining Claude accounts. It requires only the numbers the vendors themselves publish, which is a lower bar and a more durable one. For a comparison of how much of a vendor claim survives contact with its own documentation, the same exercise on a hardware announcement and its conspicuous blanks reached a similar place.
Pages every figure above was read from
- Anthropic, threat-intelligence report, September 2026: anthropic.com
- Session length, and logging out of all sessions: support.claude.com. Managing active sessions: support.claude.com. Login methods: support.claude.com. Compromised API key: support.claude.com. Plan and reset window: support.claude.com
- NIST SP 800-63B-4, authenticator and session requirements, published July 31, 2025: csrc.nist.gov; AAL timeout sections: pages.nist.gov
- NIST IR 8587, token and assertion protection, finalised September 15, 2026, co-authored with CISA: nvlpubs.nist.gov
- OWASP session management cheat sheet: cheatsheetseries.owasp.org
- FBI, Internet Crime Report 2025, released April 6, 2026: ic3.gov
- FTC, Consumer Sentinel Network Data Book 2024: ftc.gov
- Microsoft, configurable token lifetimes and Continuous Access Evaluation: learn.microsoft.com
- Google, Device Bound Session Credentials: developer.chrome.com and blog.google
This article is a summary of publicly available documentation and published crime statistics. It is not security consulting for any specific account or organisation, and it is written by no one holding a security certification. Figures are as published on September 26, 2026 and the standards cited carry their own effective dates.
Start Here: every guide by topic · About · Privacy Policy
Comments
Post a Comment