OAuth Consent Phishing: The Login That Needs No Password

OAuth consent phishing (the illicit consent grant attack) abuses the authorization flow rather than authentication. The attacker registers a malicious OAuth application — often multi-tenant — and lures a user with a legitimate-looking vendor consent screen requesting delegated permissions such as Microsoft Graph Mail.Read, offline_access or file access. When the user clicks “Accept,” the app receives access and refresh tokens for that user’s data; no password or MFA is captured. Because the grant persists independently of the user’s password, a reset does not revoke it — giving durable, token-based access and a stealthy persistence foothold in Microsoft 365 or Google Workspace. MITRE ATT&CK tracks the core as T1528.

How It Works

The lure (delivered by T1566.002 spearphishing link) leads to a genuine identity-provider consent page for the attacker’s app. The user authorises it, and the app is granted delegated access and refresh tokens it can reuse (T1528 T1550.001). Attackers extend persistence by adding service-principal credentials or cloud roles (T1098.001 T1098.003).

MITRE ATT&CK Mapping

Detection & Mitigation

• Restrict user consent: require admin consent for apps requesting sensitive or privileged permissions, enable the admin-consent workflow, and block consent to apps from unverified publishers.
• Enforce phishing-resistant MFA on all accounts, including legacy and test tenants, and eliminate accounts without MFA.
• Audit OAuth app grants and service-principal credential additions (“Consent to application” events); hunt for apps with broad mailbox/Graph scopes, unverified publishers or unexpected redirect URIs.
• On incident, revoke the app’s grants and service-principal tokens, remove added credentials, and review mailbox access by app identities.