The Cookie That Walks Past Your MFA

An attacker holding your session cookie never sees your login page. There is no password prompt, no approval request on your phone, nothing to deny. The session was already approved — by you, an hour earlier, on a screen you had every reason to trust.

This is the part of the identity story most companies skipped. The MFA rollout was run as a project with an end date. It finished. A green square went onto a board slide. What did not stop was the search for the cheapest way in, and that path now runs through the artifact multi-factor authentication produces after it succeeds.

A token is a signed statement that the argument is over

When someone authenticates to Microsoft 365 or any modern cloud application, the platform does not re-verify identity on every click. That would be unusable. Instead it issues a token: a signed statement that this browser, for a defined window, is that person. The browser holds it. Every subsequent request presents it. The identity provider honors it without asking again.

The design is correct. It is also the exposure. A password is a secret you know; a token is a secret your device holds. Steal the token and you inherit the answer to a question that was already asked and already approved. Multi-factor authentication protects the asking. It has nothing to say about the answer once that answer is in someone else's hands.

Security teams have understood this for years. What has changed is how ordinary the attack has become.

The change is industrial, not technical

Session hijacking is old. Two well-documented routes now make it routine rather than specialized, and they converge on the same outcome.

The first is adversary-in-the-middle phishing. Rather than a fake login page harvesting credentials, the attacker's infrastructure relays the victim's traffic to the real login page in real time. The password is typed into a genuine Microsoft page, rendered through a proxy. The push notification is approved. Authentication actually succeeds — and the proxy captures the resulting session cookie on the way back. Analysis, not fact: the meaningful shift here is packaging rather than invention. The technique did not get smarter; it got easier to operate.

The second is information-stealing malware, delivered through a browser extension, a cracked utility, or a convincing installer served by a search ad. The payload's purpose is not encryption or persistence. It copies browser cookie stores, saved tokens and credential databases, then leaves. Defenses tuned to ransomware behavior have comparatively little to catch.

Both routes end in the same place: a valid session, replayed from attacker infrastructure, presenting a token your identity provider issued and still trusts.

MFA is an event. Access is a state.

That distinction is the correction worth making at executive level, because it changes what you buy and what you measure.

Multi-factor authentication is an event at a point in time. Access is a state that persists afterward, extended quietly by refresh cycles. Nearly every identity investment of the past decade targeted the event. Very little targeted the state.

The consequences are easy to underrate from a slide deck. Someone inside a live Microsoft 365 session does not need to escalate privilege. They already have the mailbox, the files that user can reach, the chat history, the SharePoint sites, the group memberships. They can read the thread about a pending wire transfer before writing into it. And where an AI assistant has been deployed to answer questions using whatever the signed-in user can already access, it will serve a stolen session as willingly as a real one. The assistant is behaving correctly. Nothing in the request tells it otherwise.

A prediction, labeled as one: machine identity is where this widens next. As agents and automation platforms accumulate long-lived OAuth grants on behalf of employees, organizations create durable access that outlives the laptop, the browser session, and sometimes the employment. Few businesses can produce an inventory of those grants on request. Gaps like that tend to be discovered rather than closed.

Revocation latency is the number nobody measures

Stop asking whether MFA is enabled everywhere. Assume it is. Then assume it will be bypassed, and ask a harder question: from the moment we suspect a session is compromised, how long until that session is dead everywhere?

For many organizations the honest answer runs through a ticket, a business-hours queue, an administrator who knows where the revocation control lives, and an assumption worth testing rather than trusting — that a password reset by itself terminates sessions already in flight. Whatever that elapsed time turns out to be, it is the attack.

Four changes shorten it. None is exotic. Most are configuration and operational discipline rather than new tooling, though your licensing tier determines what is available to you.

• Phishing-resistant credentials. Passkeys and FIDO2 keys are bound by design to the origin of the legitimate site, so a relay proxy has nothing usable to relay. The credential will not sign for a domain it was never registered to.
• Device as a condition of access. Conditional Access policies requiring a managed, compliant device mean a token replayed from unmanaged infrastructure fails policy even though the token itself is valid. In our assessment this is the single most effective control most Microsoft tenants already own and have not enabled.
• Continuous evaluation instead of fixed lifetimes. Re-check risk signals mid-session and force reauthentication when device posture, location or risk score changes, rather than waiting for a token to expire on schedule.
• A rehearsed revocation path. Someone must be able to terminate every session for an account, at any hour, without escalation. If that capability lives only in one person's memory, it does not exist.

The fourth is operational rather than technical, which is why it is usually the weakest. Revocation is a race, and a phone tree loses it. The Pro Link Systems help desk is in-house, US-based and staffed 24/7, with calls answered live and an average ticket first-response time of 15 minutes — relevant here for one narrow reason: minutes are the unit of measurement when a stolen session is live.

Three questions before your next security renewal

Token theft does not reward more awareness training. The user in this scenario did nothing detectably wrong; they authenticated successfully to a real Microsoft page. What it rewards is architecture — binding sessions to devices, replacing shared secrets with origin-bound credentials, watching for valid tokens arriving from implausible places, and being able to end a session in minutes rather than by morning.

Three questions will locate you:

• Can we require a managed device for access to email and files, and do we?
• What is our measured elapsed time from suspicion to full session revocation?
• Who holds long-lived tokens to our data that is not a human being?

An organization that can answer those has stopped treating identity as a checkbox. One that cannot has an MFA deployment and an inflated sense of what it covers — the more common position, and not an embarrassing one, provided it is temporary. It is also, increasingly, what separates a functioning managed IT program from one that merely looks compliant.

Pro Link Systems has worked on identity and access with Los Angeles businesses from Woodland Hills since 1999. If you want an honest read on how your session controls would hold up, our cybersecurity team will walk your tenant configuration with you.