Infostealers and session hijacking: stealing the session, skipping the login

What happened

Across 2024 and 2025, infostealer malware (RedLine, Lumma, and successors) became one of the largest sources of identity compromise. Beyond passwords, these tools grab browser session cookies and tokens. With a stolen session cookie, an attacker imports it into their own browser and is logged in as the victim, with no password prompt and no MFA challenge, because the session is already authenticated.

Root cause

Sessions are long-lived bearer tokens. Most apps issue a cookie that stays valid for days or weeks and is not bound to the device that obtained it, so anyone who copies it inherits the session. MFA protects the login event, not the session that follows it.

The identity lesson

Stopping credential theft is not enough when the session itself is the prize. Defenders have to protect the post-authentication session, which is where ITDR and modern session controls come in. This is also why "we have MFA" is an incomplete answer to account takeover.

How to defend

• Shorten session lifetimes and re-evaluate risk continuously rather than trusting a long-lived cookie.
• Bind tokens to a device or client (DPoP, mutual TLS) so a copied cookie fails elsewhere.
• Enforce device posture and managed-device checks at sensitive actions.
• Deploy endpoint protection to stop infostealers, and use ITDR plus exposure intelligence to detect stolen-session use and credential leaks.

The 2026 confirmation

Two events in August 2026 closed the loop on this pattern. Connor Riley Moucka pleaded guilty in Seattle federal court over the Snowflake customer breaches, which reached at least 165 organizations and 100 million people using credentials harvested by infostealers years earlier, against accounts with MFA disabled and passwords that had gone unrotated for up to four years. There was no platform vulnerability at any point.

And ANY.RUN published analysis of Mirage2FA, a commercial phishing kit that has touched 4,532 organization domains since 2024 by capturing session cookies through legitimate Microsoft 365 login flows rather than attacking the factor at all.

Between them they establish the two supply chains: malware on the endpoint lifting what is already there, and real-time proxies capturing it at the moment of authentication. Both end with the attacker holding a valid session.

Incident response is different for stolen sessions

The instinct is to reset the password, and it does nothing. The session was issued before the reset and remains valid. The containment steps that matter:

1. Revoke sessions and refresh tokens explicitly. Most identity providers have a separate action for this. Find it before you need it.
2. Enumerate and remove attacker-added authentication methods, because a token with sufficient scope can enrol a new factor and survive everything else you do.
3. Check for registered devices you did not expect, which is the persistence step in the Entra attack chain.
4. Assume every downstream application behind SSO is in scope, since the session inherited them all.
5. Rotate credentials the compromised user could reach, including anything stored in a browser profile or password manager on that endpoint.

Reducing the value of a stolen session

Shorter lifetimes narrow the window. Sender-constraining with DPoP or mTLS removes the replay entirely by binding the token to a key the thief does not have. Device-bound sessions do the same at the platform level. Everything else is detection.

Related

Standards: FAPI and sender-constrained tokens. Glossary: token theft, session hijacking, infostealer. Vendors: ITDR. CVEs: Citrix Bleed, SharePoint JWT alg:none.