Back to TechSplainer

    Token Theft: Why the Attacker Didn't Need Your Password at All

    TL;DR:

    Token theft is when an attacker steals the proof you already logged in -- instead of stealing your password.

    Think of it like pickpocketing a concert wristband. You did the work: showed your ID at the gate, bought the ticket, got the wristband. All the security checked out. But inside the venue, nobody asks for your ID again -- they just check the wristband. If someone slips it off your wrist on the way to the beer line, they're in the show.

    On a good day, your wristband stays on your wrist, your login session lives only on your device, and the system notices if someone tries to use it from a different machine. On a bad day, your wristband ends up on someone else's wrist and nobody notices until the merch bill hits your credit card.

    Beyond the Basics:

    Here's what a token actually is.

    When you successfully log in to Microsoft 365 -- enter your password, pass MFA, get approved by Conditional Access -- the identity system issues your browser or device a short-lived string of characters that says "this user is authenticated." Different platforms use different kinds: session cookies (stored in the browser), OAuth access tokens (used by apps to call APIs), refresh tokens (used to get new access tokens without re-prompting), and SAML assertions (used in SSO).

    They all do the same job: prove that authentication already happened, so the user doesn't have to type their password every time they click something.

    Token theft means an attacker gets a copy of one of those strings. Four common ways it happens:

    1. AiTM phishing. The attacker proxies the login (see the MITM techsplainer) and captures the session cookie Microsoft issues. This is the high-volume attack right now -- basically turnkey.
    2. Infostealer malware. Malware on the user's machine scrapes browser storage for session cookies. Lumma Stealer, Redline, and Raccoon are named examples -- they steal everything, but cookies are one of the crown jewels.
    3. Cross-site scripting (XSS). A vulnerable website executes attacker-controlled JavaScript that reads session cookies and ships them out. Less common for M365-class apps but still relevant for custom web apps.
    4. Exposed secrets. API keys and tokens accidentally committed to public GitHub repos, pasted in Slack, or left in a config file on a shared drive. The "stolen" part just means somebody with bad intent found it.

    Once stolen, the attacker replays the token from their own environment. To the application, it looks like a valid session that was already authorized. No password needed. No MFA prompt. No alarm.

    Defenses that work:

    • Short token lifetimes. Entra ID access tokens default to 1 hour; refresh tokens default to 90 days but can be shortened. Attackers with an expired token are out of luck.
    • Conditional Access token binding. Ties the session to specific device, IP range, or compliance state. A token presented from a different context gets rejected even if unexpired.
    • Phishing-resistant MFA. FIDO2 stops the phishing half of the attack chain before the token ever gets issued.
    • Continuous Access Evaluation (CAE). Entra ID can revoke tokens mid-session when risk signals change. User's risk score spikes, token dies.

    The attack only works when tokens are stealable AND replayable. Kill one side of that equation and the whole class of attacks stops being economic for attackers to pursue.

    Learn More: