# OAuth token theft (multilogin + consent phishing)

When most users hear "Google account compromised," they reach for "change password + reset sessions" and consider the incident closed. That mental model stopped being correct in late 2023. Two attack classes — both well-deployed in mainstream commodity malware and phishing kits by 2024–2025 — bypass the password flow entirely. Cited as part of [[smart-ape-dont-sign-in-with-google|the_smart_ape's "don't sign in with google" thread]].

## 1. Multilogin / refresh-token replay

In late 2023 researchers found an undocumented Google OAuth endpoint called `multilogin`. Given a valid refresh token, it regenerates fresh session cookies — including cookies the user thought were invalidated when they reset their password. Within months, ten-plus malware families had integrated the technique: Lumma, Rhadamanthys, and several other commodity infostealers all ship it.

The attack flow:

1. Infostealer reaches the victim's machine via the normal commodity vectors (cracked software, malicious npm package, browser extension supply-chain compromise, etc.).
2. It scrapes Chrome's local storage for Google refresh tokens.
3. Tokens are exfiltrated.
4. Even after the victim resets their Google password and signs out everywhere, the attacker hits `multilogin` with the stolen refresh token and gets fresh, valid session cookies. The session keeps working.

The only mitigation is to manually revoke every active session *and* every third-party OAuth grant from the Google security page (`myaccount.google.com/security` → "Your devices" and "Third-party apps with account access"). Password reset alone does not invalidate already-issued refresh tokens by default. Most users don't know that distinction exists.

This is the modern shape of the [[long-lived-keys|long-lived-key]] problem: refresh tokens are long-lived credentials whose lifecycle is decoupled from the password's. Resetting the password feels final but isn't.

## 2. Consent phishing

The deeper bypass. Consent phishing doesn't try to authenticate as the victim — it asks the victim to *authorize* the attacker.

The attacker registers a Google OAuth app with a name like "Mail Backup Pro" or "Drive Sync Helper." When the target follows a phishing link, they land on the *real* Google consent screen — actual `accounts.google.com` domain, valid TLS cert, their own account already authenticated. The screen reads: "Mail Backup Pro is requesting access to read your email." The user, trained that phishing means fake login pages, sees a real Google page and taps Allow.

Now the attacker holds a Google-signed OAuth token granting the exact permission they asked for — `gmail.readonly`, `drive.full`, whatever — valid for months. The password never came up. 2FA never came up. *They were never asked to authenticate. They were asked to authorize.* Completely different mechanism.

Why this defeats the standard defenses:

- **Password manager** — never prompted, because the user was already signed in.
- **2FA / hardware key** — never prompted, because no fresh login is occurring.
- **TLS / domain validation** — real Google, real cert, would pass any inspection.
- **Phishing-resistant 2FA (FIDO2)** — still doesn't help, because authentication isn't the step being attacked.

The only mitigation again lives in `myaccount.google.com/connections`: audit which apps have access, revoke unknown or unused grants. Few users have ever opened that page.

## Industry numbers

The thread cites three data points (no primary source linked; reproduce before quoting):

- **31% of Microsoft 365 breaches in 2025** were token-theft-shaped.
- **March 2025**: attackers pivoted device-code phishing (long-known on M365) to Google.
- **August 2025**: the Salesloft / Drift breach harvested OAuth tokens for Salesforce and Google Workspace integrations at scale.

The trend the numbers support is that token theft has displaced credential phishing as the dominant compromise vector for identity-provider-fronted ecosystems.

## Why this matters for the SSO argument

Both attack classes are properties of OAuth, not of Google specifically. Apple, Microsoft, Okta, Auth0 — anyone issuing refresh tokens has the multilogin-equivalent problem if their refresh-token revocation model is decoupled from password reset. Anyone with a consent flow has the consent-phishing problem.

But the *blast radius* of either compromise scales with how much you've stacked behind that one identity. A consent-phished `gmail.readonly` token leaks years of email and is the master key to every password-reset link you've ever received. A multilogin-replayed Google session is the entry point into every downstream SaaS that accepts "Sign in with Google" — which, per [[sso-concentration-risk]], is often the entire operational stack.

The thread's recommended mitigation is the same as for the broader [[sso-concentration-risk|SSO concentration]] argument: don't put money- or work-critical services behind a single IdP, and periodically audit `myaccount.google.com/connections` for unknown or stale grants.

## See also

- [[smart-ape-dont-sign-in-with-google]] — source thread.
- [[sso-concentration-risk]] — the umbrella concept.
- [[google-oauth-domain-takeover]] — different vector (identity transfer via domain purchase), same broader pattern.
- [[long-lived-keys]] — the underlying credential-lifecycle problem.
- [[supply-chain-security]] — how infostealers reach the machine in the first place.