Infostealer to access broker: why a password reset does not end a session-cookie intrusion
RedLine and Lumma stealer logs sell live session cookies to access brokers who sign into your SaaS with no password and no MFA prompt. Here is how it works, why a reset does not fix it, and how to contain it.
Infostealers are a supply chain now. A stealer on one employee laptop feeds a marketplace, a marketplace feeds an access broker, and the broker signs into your corporate SaaS. The part that catches teams out is the last mile: the broker never types a password and never sees an MFA prompt, because what they bought was not a password. It was a live session.
How it works
A user runs a trojanized installer from a search ad or a fake update. A RedLine or Lumma class stealer executes and reads the browser’s saved-password store and, more importantly, its cookie store. Saved passwords are useful. Live session cookies are better, because a session cookie is proof that the browser already authenticated, MFA included.
The stealer ships that log to attacker infrastructure, and it gets listed for sale. An access broker buys it, imports the cookies into their own browser, and requests your identity provider. The IdP sees a valid, unexpired session and lets it through. No password entry. No MFA challenge. The stolen session already satisfied MFA, so there is nothing left to challenge. This is T1539, Steal Web Session Cookie, followed by T1550.004, using that cookie as alternate authentication material, landing as T1078, a valid account.
Why a password reset does not end it
Here is the trap. The incident looks like a credential compromise, so the reflex is to reset the password and reimage the laptop. Both are worth doing. Neither ends the intrusion.
A session cookie and its refresh token are independent of the password. A live session does not re-check the password on every request; that is the whole point of a session. So you can reset the password, and the attacker’s existing session keeps working. You can wipe the malware off the endpoint, and the attacker’s session keeps working, because the token was copied out hours or days earlier and now lives in someone else’s browser. Killing the malware without revoking the session just leaves the attacker quietly logged in.
How to detect it
The detection tell is session replay with impossible travel. Look for a session that appears already authenticated from a new device fingerprint and a new ASN, with MFA satisfied and no interactive credential entry, running at the same time as the user’s genuine session from their normal egress. A traveling user explains a new location. It does not explain two live sessions hundreds of miles apart within minutes, one of which never showed a login prompt.
Because a replayed cookie carries the prior MFA state, you will not see a failed MFA or a fresh challenge to alert on. The signal is the concurrency and the absence of interactive auth, not a failed factor. Access brokers also favor residential-proxy ASNs to blend in, so treat a new-device, new-ASN, MFA-satisfied session with no interactive auth as the pattern to hunt.
Contain and shut it down
Order matters. Revoke first, then rotate, then clean.
- Revoke the account’s active sessions and refresh and OAuth tokens. Sign-out-everywhere and revoke refresh tokens is what actually invalidates the stolen cookie so it stops working. Do this before anything else.
- Rotate the exposed credentials and force phishing-resistant reauthentication before restoring access.
- Scope what the session did. Pivot on the attacker’s session id across the IdP sign-in logs and the SaaS audit logs, and enumerate mail read, files accessed, and any OAuth apps consented or app passwords minted for persistence. A broker will often plant a durable token while they have the session.
- Then clean the endpoint. Remove the stealer and reimage after the session is dead, not before.
- Rotate the full exposure. One stealer log usually contains many accounts, so reset every credential in it, not just the one you caught. Then bind tokens to the device and shorten token lifetimes so a copied cookie cannot replay from a different machine.
Practice it
Reading the containment order is not the same as running it while an attacker is live in your tenant. We built this incident in GraphLattice Range so teams work the detection and the revoke-then-rotate-then-clean sequence under the clock, and get scored on the call they make.