Token theft: when attackers skip the password entirely

The highest-volume route is infostealer malware, commodity tooling sold on subscription and delivered through cracked software, malicious ads and poisoned search results. Within seconds of executing it reads the browser's cookie store, saved passwords and any locally cached tokens, bundles the lot into an archive and ships it out. Those archives are sold in bulk, so the person who infected the machine and the person who later walks into your tenant are usually different people. The machine most likely to be infected is the one you do not manage: the home PC where a staff member signed into webmail once, or the contractor laptop with no endpoint agent on it.

The second route is the adversary-in-the-middle kit. The victim signs in through a reverse proxy dressed as the real login page, completes MFA genuinely, and the proxy keeps a copy of the session cookie the identity provider issues. The sign-in log records a success.

The third route needs no malware at all. An attacker who convinces a user, or a hijacked session, to consent to an attacker-controlled application receives OAuth tokens through a completely legitimate grant. Those tokens refresh silently in the background and survive a password reset, which is why consent-grant attacks are prized: they are persistence that looks like an integration.

MFA is a gate on token issuance. It decides whether the identity provider will mint a session at all. Once the session exists, the cookie or token representing it is a bearer credential in most deployments: whoever presents it is treated as the user, from whatever machine and network they present it. A stolen cookie replays cleanly from attacker infrastructure on the other side of the world, because the thing MFA proved, that a person with two factors was present, was proved at issuance and never again.

This is also why detection built around authentication failures misses these attacks entirely. Every log line involved says success. The real signals live one layer down: a session identifier suddenly appearing from a new network, a token presented from infrastructure the user has never touched, an inbox rule created minutes after a sign-in from a new country. Entra ID Protection ships detections for anomalous token behaviour, and sign-in risk policies can respond by forcing reauthentication or blocking outright. If your licensing includes those features and no policy consumes them, that is the first gap to close.

Not all tokens are equal, and the difference is lifetime. Access tokens are short-lived, typically around an hour in Entra ID, and expire on their own. Refresh tokens and browser session cookies are the prize: they can live for weeks or months, extend as they are used, and quietly mint fresh access tokens on demand. An attacker holding a valid refresh token does not need to touch the sign-in page again for as long as it stays valid.

That window is wide enough for everything that matters. Mailbox rules that hide replies while an invoice conversation is redirected. A quiet pull of files and contacts through the same APIs your legitimate apps use. New MFA methods registered so the attacker survives a competent response. The reach also extends past your identity provider: every SaaS product where the user held a session has its own cookies with their own lifetimes and its own revocation switch, and in many organisations nobody has ever located those switches.

The structural fix is to stop tokens being bearer credentials. Token protection in Entra ID conditional access binds the sign-in session to the device it was issued on, so a copied token fails when replayed from anywhere else; coverage is still expanding across workloads, so switch it on where supported and treat it as a layer rather than the whole answer. Conditional access policies requiring a compliant, managed device achieve a similar effect one level up, because the cookie can be copied but the device claim it must travel with cannot. Continuous access evaluation shortens the tail further by revoking access in near real time when a user is disabled or a risk event fires, instead of letting issued tokens ride until expiry.

The theft side responds to plain endpoint discipline, which is territory the Essential Eight already covers: application control exists precisely to stop commodity malware like infostealers from executing on managed machines. Keeping work sign-ins off unmanaged devices keeps corporate session cookies off the home PC in the first place, whether you block those sign-ins outright or strip them down to browser sessions with no persistent cookie. Phishing-resistant factors close the adversary-in-the-middle issuance path, as the earlier MFA note covers. And user consent to unverified applications can simply be turned off at the tenant level, with an admin consent workflow carrying the legitimate requests.

Most teams discover during their first token-theft incident that resetting the password did not end it. A reset stops new sign-ins with the old password. It does not, by itself, sign the attacker out of sessions that already exist, and OAuth grants to third-party applications keep refreshing regardless. Ending a hijacked session is a specific sequence, and it is worth rehearsing before you need it.

Three questions give a fast read on your exposure. Could a session cookie copied from a staff laptop be replayed from an unknown network today, or would a device requirement stop it? If Entra ID Protection flagged an anomalous token right now, does any policy act on that signal, or does it land in a report nobody reads? And if you had to end one user's every session in the next ten minutes, could you name each step without looking anything up?

Organisations that answer all three confidently are rare. The gap between having these controls licensed and having them hold under test is where the real work sits, and it is the exact seam we examine in Microsoft 365 and Azure security reviews.