Browser Cookie and Token Theft: The Post-MFA Attack Your Endpoints Miss

You rolled out MFA everywhere. Every login prompts for a hardware key or an authenticator push. So why did an attacker log into your Microsoft 365 tenant from an IP in another country without triggering a single MFA challenge? Because they never logged in. They stole the session — the cookie your browser already holds after you authenticated — and replayed it. MFA protects the front door; session theft walks in through the window you left open after unlocking it.

This is the single most common post-exploitation move by modern infostealer malware (Lumma, RedLine, StealC, and their many forks). It is fast, quiet, and it neuters the control most orgs treat as their crown jewel. Here is how it works on Windows and, more importantly, what you can audit to shut it down.

The attack in three moves

An infostealer that lands on a workstation — usually via a malicious download, a cracked-software lure, or a poisoned search ad — does not bother with your keyboard. It goes straight for the browser profile directory:

%LOCALAPPDATA%\Google\Chrome\User Data\Default\Network\Cookies
%LOCALAPPDATA%\Microsoft\Edge\User Data\Default\Network\Cookies
%APPDATA%\Mozilla\Firefox\Profiles\*.default-release\cookies.sqlite

These are SQLite databases. The cookie values are encrypted, but historically the key sat right next to them in Local State, wrapped with the user's DPAPI key — trivially decryptable as that user. The three moves are:

1. Read the cookie store and Local State from disk (no admin needed — it is the user's own data).
2. Decrypt the AES key via DPAPI in the current user context, then decrypt every cookie.
3. Exfiltrate the live session and OAuth refresh tokens, then replay them from attacker infrastructure. Because the cookie already represents a fully authenticated, MFA-satisfied session, no second factor is requested.

Why "just enable MFA" does not save you

MFA is evaluated at authentication time. A session cookie or OAuth refresh token is issued after that check passes and remains valid for hours to weeks. Steal it inside that window and you inherit the authenticated identity wholesale — email, SharePoint, Teams, and any SSO-connected SaaS. Conditional-access policies help only if they re-evaluate device and network signals on token use; many tenants do not enforce that.

The uncomfortable truth: a stolen session token is a bearer credential. Possession is authorization. The only durable defenses bind the token to the device it was issued on.

Google's App-Bound Encryption (Chrome 127+) and Microsoft's Edge equivalent were direct responses to this — they tie the cookie-decryption key to a system-level service so a plain user-context read no longer yields plaintext. It raises the bar, but stealers have already adapted with elevation and injection techniques. The endpoint hygiene around the browser still matters enormously.

What to audit on every Windows endpoint

Session theft is an endpoint problem before it is an identity problem. The machine hardening that stops the initial infostealer execution is what actually breaks the chain. On each workstation, verify:

• Token-binding controls are on. Confirm Chrome/Edge are current enough for App-Bound Encryption and that policy has not disabled it. Enable Credential Guard so browser-adjacent credential theft has less to grab.
• Execution of stealer payloads is blocked. Attack Surface Reduction rules and application allowlisting stop the unsigned dropper before it can read a single cookie.
• DPAPI abuse is visible. Unusual process access to Local State and the Cookies SQLite files from non-browser binaries is a high-fidelity signal.
• Persistence is clean. Stealers often chain into autostart persistence to survive reboots and keep exfiltrating. Audit run keys, scheduled tasks, and startup folders.
• Browsers are patched. Out-of-date browsers reintroduce the old plaintext-key weakness. Patch latency on the browser is patch latency on your identity perimeter.

Detecting the theft in progress

The tell is a process that has no business touching a browser profile reading the cookie store. A quick manual hunt for recent access — and for copies of profile files outside the profile directory — surfaces staging behavior:

# Non-browser processes with handles to Chrome's Cookies DB
Get-Process | ForEach-Object {
  $_.Modules 2>$null | Where-Object { $_.FileName -like "*User Data*" }
}

# Look for cookie/Local State copies dropped outside the profile
Get-ChildItem $env:TEMP,$env:APPDATA -Recurse -Include "Cookies","Local State" -EA SilentlyContinue |
  Where-Object { $_.DirectoryName -notlike "*User Data*" }

Doing this by hand on one box is fine for triage. Doing it consistently across an estate is where it falls apart — which is exactly the gap automated auditing closes.

Where WinSentinel fits

Every check above is a first-class audit on a single machine with WinSentinel — free, all 33 modules, no limits. It flags outdated browsers, missing Credential Guard, weak ASR coverage, suspicious autostart entries, and the DPAPI/cookie-access patterns that indicate stealer activity, then scores the endpoint and tells you exactly what to fix.

For organizations, WinSentinel Pro takes that same posture and orchestrates it across the fleet: the central node rolls up which endpoints are missing token-binding controls, alerts on drift when a browser falls behind or Credential Guard gets turned off, and lets you dispatch remediation to the machines that need it — so a session-theft foothold on one laptop does not stay invisible across a hundred.

MFA was never meant to be your last line of defense. Harden the endpoint that holds the session, and the stolen cookie becomes worthless before it is ever exfiltrated.