OAuth Consent Phishing — How Attackers Steal Mailbox Access Without Stealing Passwords

A senior marketing manager at a Dutch enterprise software firm receives an email Monday morning: 'eSign the Q2 partnership agreement — opened by your colleague Mark'. The link goes to the genuine Microsoft sign-in flow on login.microsoftonline.com — exactly the page she expects. She enters her credentials, completes her FIDO2 passkey challenge, and is redirected to a Microsoft-styled permissions screen titled 'Accept permissions — Partnership Document Reader needs:'. The four permission lines read like reasonable e-signature scopes: 'View your basic profile', 'Sign you in and read your profile', 'Read your mail', 'Have full access to your files'. She clicks Accept. The page redirects to a plausible-looking PDF. Behind the scenes, the attacker's enterprise application — registered six months earlier in an unrelated Azure tenant and named 'Partnership Document Reader' — now has a refresh token authorising read access to her entire mailbox and OneDrive. The attacker uses the Microsoft Graph API to pull six years of correspondence over the next four hours. Password rotation does not stop it. MFA re-enrolment does not stop it. The only fix is to revoke the OAuth grant from the user's My Apps panel and from the tenant Enterprise applications list. Detection time in the average enterprise: 23 days.

OAuth is the standards-compliant way third-party applications request access to your data — Calendly to your calendar, Slack to your inbox, the e-signature platform to your files. Every legitimate enterprise depends on OAuth grants. The attack abuses the same protocol: the attacker registers an application in an Azure or Google tenant they control, gives it a credible name (something like 'Document Sync', 'Calendar Helper', or impersonating a known SaaS brand), requests broad scopes (Mail.Read, Files.Read.All, full_access_as_user), and then phishes a user into completing the consent flow. Crucially, the user is asked to sign in to their own legitimate Microsoft or Google account — there is no spoofed login page. The phish is on the consent screen itself, not the sign-in. Once consent is granted the attacker receives an access token plus a refresh token; the refresh token survives most password rotations and remains valid until the OAuth grant is revoked or the application is removed. MITRE ATT&CK techniques: T1528 (Steal Application Access Token), T1098.001 (Account Manipulation: Additional Cloud Credentials), T1550.001 (Use Alternate Authentication Material: Application Access Token). The defensive playbook is identity admin-side: restrict third-party-app consent to admin-approved apps only, monitor consent grants in audit logs, and review enterprise applications quarterly. The user-side defence is harder — the consent screen looks legitimate because it IS legitimate; the user must read the scope lines and understand what they mean.

• A permissions screen ('App XYZ needs the following permissions') for any app you did not deliberately install or sign up for
• Scope requests like 'Read your mail', 'Send mail as you', 'Have full access to your files', 'Read and write all groups' — any broad-scope ask from an unfamiliar app should be a hard stop
• App names that closely impersonate well-known SaaS (e.g. 'Microsoft Document Sync' is not a real Microsoft product; 'DocuSign Sign' versus the real 'DocuSign' brand)
• Publisher field marked as unverified, or showing as an organisation you have never heard of
• Consent prompts appearing during what was supposed to be a sign-in or document-open flow — legitimate document opens do not require additional consent each time
• Unsolicited 'a document has been shared with you, click to view' emails that route through a third-party signing or viewing app
• Unexpected app permissions listed under 'My applications' (https://myapps.microsoft.com) or your Google 'Third-party apps with account access' panel that you did not authorise

1. Read every consent screen — every time — and reject any broad-scope request from an unfamiliar appTreat 'Read your mail' or 'Full access to files' as flashing-red unless you signed up for an app that genuinely needs that scope (rare).
2. If you accidentally consented, revoke immediatelyMicrosoft: https://myapps.microsoft.com → click the app → Remove. Google: https://myaccount.google.com/permissions → Remove access. Then notify security so they can audit the rest of the tenant.
3. Review your installed third-party apps quarterlyAnything you do not recognise, do not use, or no longer use — revoke. Both Microsoft and Google make this a one-click action.
4. Never sign in to a 'document' that requests new permissions on a flow you have done before without themIf the publisher is asking for new scopes mid-flow, that is the attack. Stop and verify with the sender out-of-band.
5. Escalate every unfamiliar consent prompt to security — even if you rejected itA consent-phish attempt is reconnaissance evidence. Security needs to know who else may have been targeted.

• Microsoft — Illicit consent grants and OAuth consent phishing[primary]
• Microsoft Entra — Consent and permissions settings[primary]
• MITRE ATT&CK — T1528 Steal Application Access Token[primary]
• OWASP — OAuth 2.0 Threat Model[primary]
• Mandiant — APT28 / Pawn Storm OAuth campaign analyses[secondary]
• Microsoft Threat Intelligence — Storm-0558 case studies[secondary]

• Microsoft 365 Phishing in 2026 — AiTM, Token Theft, and the End of TOTP

  10 min read