Session theft has been productized. The control most organizations still treat as the finish line does not touch it.

Somewhere in your environment this quarter, an employee is going to authenticate correctly. Right password, right second factor, right device, no failed attempts, no alert. And an attacker is going to be inside that account seconds later, holding a session your identity provider considers entirely legitimate.

That is the documented operating model of at least two commercial phishing services running right now, one of them a $320-a-month kit called NovaCookies, and it is what happened to a set of customers at one of the most security-literate software companies in the industry within the last month. What makes these attacks uncomfortable is not just their sophistication, but also that they are cheap, rented, and specifically engineered to produce a sign-in event that looks ordinary.

The $320 Phishing Kit Selling Session Theft as a Service

Researchers at Island disclosed an adversary-in-the-middle phishing service called NovaCookies, which rents for 320 dollars a month or 200 dollars for a fourteen-day trial. For that price the operator supplies lures, domains, hosting, redirects, and support, and relays Microsoft 365 logins in real time in order to capture the authenticated session. The service is reported to be targeting hundreds of organizations across multiple regions, with at least 755 domains of dedicated infrastructure, more than half of the affected organizations based in or connected to the United States, and infrastructure that expanded sharply from mid-May and continued through August.

The delivery explains why the usual controls miss. Campaigns have arrived inside genuine DocuSign envelopes carrying counterfeit document-share lures, and some victim clicks were routed through legitimate Microsoft or Google sign-in endpoints as redirection hops before reaching the kit. The infrastructure also uses short-lived context binding and runtime inspection to resist email scanners. Nothing in that chain requires malware or an exploit.

Island's Shachar Gritzman describes the consequence plainly: the initial authentication succeeds normally, without malware, an exploit, or a burst of failed logins, so the sign-in event may look ordinary. That single sentence should reset how you think about your detection coverage. You are not looking for a break-in because there isn't one.

The economic shift matters as much as the technical one. Building and maintaining an adversary-in-the-middle relay is specialist work. Renting one is not. What the buyer gets is a maintained sign-in flow, rotating infrastructure, and an operator interface. Gritzman is careful to note that this lowers the barrier substantially without making every buyer sophisticated or every campaign successful, and that caveat is fair. But the population of people who can now run this attack is no longer bounded by skill. It is bounded by 320 dollars.

The Scale, Stated Honestly

A second toolkit, Mirage2FA, gives some sense of the volume. The figures come from vendor research published by ANY.RUN, and they should be read with the caveat the researchers themselves attach: every victim and campaign-scale number is an approximate estimate drawn from an available dataset, representing potential impact rather than independently confirmed compromise.

With that stated, the dataset covers activity observed from September 2024 to July 2026 and links the campaign to 3,518 unique organization email domains. Of 9,426 unique targeted email addresses, 4,532 were potentially compromised, roughly 48 percent. The compromise events break down in a way that makes the intent obvious: of 9,332 recorded events, 4,561 were session cookie theft, 3,044 were password or second-factor compromise, and 1,339 were single sign-on logins. Session theft was the single most common outcome, accounting for more than half of everything recorded.

Two details deserve more attention than they have received. The attack runs almost entirely inside the browser, using .htm, .xhtml, and .svg stagers, QR code lures, and WebSocket-based relay activity rather than binary malware. And 33.3 percent of successful login events came from mobile devices, where truncated address bars make a counterfeit sign-in page substantially harder for a user to inspect. If your phishing-resistance programme assumes a desktop browser and a visible URL, a third of the successful events fall outside your assumptions.

Framed against MITRE ATT&CK, both campaigns follow the same chain: initial access via phishing (T1566), followed by use of alternate authentication material in the form of a stolen web session cookie (T1550.004). No credential guessing. No exploitation.

When the Victim Knows Better

The third case removes any comfort that this is a problem confined to organizations with weak hygiene. In the last week, in a notice sent directly to affected users, Anthropic began notifying users whose active Claude login sessions had been lifted off their own machines by commodity infostealer malware, and then replayed by an attacker to access those accounts and consume their paid usage.

The malware involved was not novel or targeted. Anthropic identified Vidar, LummaC2, StealC, RedLine, and Acreed on Windows, along with Atomic Stealer on a smaller number of Macs. These families steal whatever is stored locally, including browser cookies, and an infostealer that copies an already authenticated browser session removes the need to defeat the password and second factor at all. One affected user traced the infection to a pirated game.

Anthropic's response is the instructive part. The company signed affected users out, removed saved payment methods, and refunded charges it identified as unauthorized. It also told those users something that every incident response function should internalise: signing you out stops the stolen sessions, but it does not remove the malware, and the next session can be taken the same way. Revocation is necessary and it is not sufficient.

Authentication Is an Event. A Session Is a State.

The common thread across all three cases is a category error that has quietly become load-bearing in enterprise security architecture.

Multi-factor authentication is an event. It happens once, at a moment in time, and it produces an artifact. That artifact, the session, is a state that persists long after the event, carries the full authority of the identity that created it, and is generally accepted without further challenge for as long as it remains valid. That makes the security question bigger than whether the identity authenticated successfully. It is also what access and authority that identity can exercise once it has. We invested a decade hardening the event. We left the state largely unguarded, and attackers moved to it, which is the rational thing to do.

There is a plausible argument that we caused this. As passkeys and WebAuthn have made credential theft materially harder, session theft became the available path, and phishing-as-a-service operators productised it to meet demand. That is not a reason to slow phishing-resistant authentication rollouts. It is a reason to stop treating them as the finish line.

The architectural implication is uncomfortable for anyone whose email security strategy is built on interception. If the attacker arrives holding a valid session, perimeter detection has already been bypassed rather than defeated, and controls positioned at the front door are simply not in the path.

What Actually Changes the Outcome

Four things change the outcome, in order of how cheap they are to fix:

1. Fix the remediation reflex. Session theft is not a password incident. Resetting the password leaves the stolen session and its refresh token working. Revoking active sessions and refresh tokens is the actual remediation, and it needs to be a documented, rehearsed procedure rather than something improvised at two in the morning. CISA's recent red team advisory lists exactly this as a key action, directing organizations to establish and regularly review comprehensive procedures for detecting, remediating, and revoking access and refresh tokens in the event of a cloud compromise.
2. Sequence phishing-resistant authentication by privilege, not by headcount. Privileged and high-impact accounts first, backed by managed device requirements where that is practical. A program that tries to reach every user simultaneously usually reaches the highest-value accounts last, which is precisely backwards.
3. Move detection past the sign-in. If the authentication event looks ordinary by design, then the signal is not in the login. It is in what follows: correlating device trust with token anomalies and post-authentication behavior rather than treating a successful sign-in as the end of the question. Google's Device Bound Session Credentials (DBSC), currently rolling out in Chrome, points at the same gap from the browser side, cryptographically binding a session to the device it was issued on so a copied cookie stops being useful off that device. A session presenting from a device or context the human is not plausibly using is the detection opportunity that remains after the front door has been conceded.
4. Reduce what a stolen session is worth. Every control above assumes some sessions will be taken. What determines whether that becomes a contained incident or a breach is the blast radius of the identity behind the session: how much standing privilege it carries, how many connected applications it reaches through single sign-on, and how long its access persists without re-evaluation. A stolen session belonging to an identity with narrowly scoped, time-bound, just-in-time access is an inconvenience. The same session belonging to an identity with broad standing entitlements is an incident with a disclosure obligation attached. That difference is decided in advance, by architecture, not during response.

The Front Door Is Not Where the Fight Is

The point is not to diminish the importance of multi-factor authentication, but to stop treating it as the terminal control, which is the position it currently occupies in a great many security programs and in almost all security awareness training.

Attackers have stopped trying to fail your authentication. They have started trying to pass it, and then to inherit everything that passing it grants. The rental market for that capability now starts in the low hundreds of dollars a month, runs on infrastructure that rotates faster than your blocklists, and produces telemetry that looks like your users doing their jobs.

So the question worth taking into your next architecture review is not whether your MFA coverage is complete. Assume for a moment that it is, and that it held perfectly, and that an attacker is inside a valid session anyway. How long does that session live, what privilege does it carry, what can it reach, who would notice, and how quickly could you revoke it along with every refresh token behind it? If those four answers are not immediately available, the coverage number was never the control you thought it was.

About the Author: Len Noe is a Solutions Architect at BeyondTrust, Transhuman, Podcaster, International Cyber Security Speaker, Author, Technical Evangelist, and Biohacker with 11 implanted microchips. A former blackhat with more than 30 years in technology, he has presented in over 70 countries and is featured in the documentary I Am Machine, which premiered at DEF CON 2025.