How Attackers Use OAuth Apps to Bypass Your Password
OAuth consent phishing does not steal your password. It does not install malware. It asks for permission, and you click Allow.
1 Click
To grant full access
100%
Survives password resets
0
Malware files installed
The attack that skips your password entirely
Most phishing attacks try to steal credentials. OAuth consent phishing takes a different approach. Instead of tricking you into entering your password on a fake login page, the attacker tricks you into granting a malicious application access to your account. You authenticate with your real provider (Google or Microsoft), approve a permissions prompt, and the attacker's app receives a token that grants persistent access to your email.
No password is stolen. No malware is installed. MFA is never bypassed because it was never challenged. The user completed a legitimate authentication flow and voluntarily granted access to an application they did not recognize as malicious.
How the attack works
Step 1: The lure
The attacker sends a phishing email containing a link. The email might claim to be a shared document, a voicemail notification, a security alert, or a meeting invitation. The link does not go to a fake login page. It goes to the real Microsoft or Google authorization endpoint, with the attacker's application pre-registered as the requesting app.
Step 2: The consent prompt
The user clicks the link and sees a legitimate sign-in page from Microsoft or Google. They enter their real credentials, complete MFA if required, and are then shown a permissions prompt: "This app would like to read your email, send email on your behalf, and access your contacts. Allow?"
The prompt looks normal. The sign-in page is real. The URL is correct. Every security training the user has received tells them to check the URL and look for HTTPS. Both check out. The only red flag is the name and publisher of the requesting application.
Step 3: Persistent access
Once the user clicks Allow, the attacker's application receives an OAuth token. This token grants access to the user's mailbox according to the permissions that were approved. The attacker can now read all email, send email as the user, and access contacts, depending on which scopes were requested.
This access persists until the user explicitly revokes the application's permissions. Changing your password does not revoke it. Enabling MFA does not revoke it. The token operates independently of the user's credentials.
Step 4: Exploitation
With persistent mailbox access, the attacker follows the same playbook as any business email compromise. They monitor email for financial transactions, study communication patterns, identify high-value targets, and wait for the right moment to intervene with fraudulent payment instructions or data exfiltration.
Why this is worse than password theft
When an attacker steals a password, the remediation is straightforward: reset the password, enable MFA, revoke sessions. The compromise is contained.
OAuth consent phishing is harder to detect and harder to remediate for three reasons.
It survives credential resets.The OAuth token is not tied to the user's password. Resetting the password, rotating credentials, and forcing re-authentication do not invalidate the malicious app's access.
It bypasses MFA entirely. The user completed MFA during the consent flow. The resulting token does not require MFA for subsequent API access. There is no second factor to challenge.
It looks legitimate in logs.The sign-in event shows a successful authentication from the user's IP address and device. The consent grant appears as a normal application authorization. Security teams reviewing sign-in logs may see nothing suspicious.
The admin consent escalation
The most dangerous variant targets administrators. If an attacker tricks a Microsoft 365 global admin into granting consent, the app can request organization-wide permissions. A single click from one admin can grant a malicious app access to every mailbox in the organization.
Microsoft calls this "illicit consent grant." The attacker's app requests permissions like Mail.ReadWrite.All or Files.ReadWrite.All with the "consent on behalf of your organization" option. Once approved, the app has tenant-wide access that persists until an admin explicitly removes it.
This is not theoretical. Microsoft's own threat intelligence has documented multiple campaigns targeting admin consent flows, including Midnight Blizzard (formerly NOBELIUM) using OAuth apps for persistent access to government and enterprise email systems.
Signs of compromise
OAuth consent phishing leaves specific artifacts:
- A third-party application with mail or file permissions that the user does not recognize
- Multiple users in the same organization granting consent to the same unfamiliar app within a short timeframe
- An application with a generic or misleading name (e.g., "Document Viewer," "Mail Security Scanner")
- An unverified publisher in the app's registration details
- API access to the mailbox from an application rather than a user session
These artifacts are not visible in a standard inbox review. They require checking connected applications in account settings or using an API to query OAuth grants.
What InboxWatch detects
InboxWatch scans connected OAuth applications on every scan and flags four specific conditions:
Critical-risk applications. Any connected app with permissions that allow it to send email as you, read all your mail, or access all your files triggers a critical finding. These permissions (Mail.Send, Mail.ReadWrite, Files.ReadWrite.All) are the ones consent phishing attacks target.
High-risk applications. Apps with elevated but not critical permissions (mail read, calendar modify, contacts access) are flagged as high risk. The finding includes the app name, publisher verification status, and the specific permissions granted.
Multiple risky apps. When two or more high-risk or critical-risk apps are connected simultaneously, InboxWatch flags the aggregate attack surface. Each additional app is another potential entry point.
Organization-wide admin consent. For Microsoft 365 organizations, InboxWatch detects when an admin has granted tenant-wide consent to an app with sensitive permissions. This affects every user in the organization, not just the admin who clicked Allow.
InboxWatch also correlates OAuth findings with other signals. A new risky OAuth app appearing within hours of a suspicious sign-in triggers an attack chain alert. OAuth apps combined with new forwarding rules and new inbox filters (the classic persistence trifecta) trigger a critical multi-vector alert.
How to protect yourself
Review connected apps regularly. Check your connected applications at myaccount.google.com/permissions (Google) or myapps.microsoft.com (Microsoft). Remove any app you do not actively use.
Restrict consent to verified publishers. In Microsoft 365, admins can configure user consent settings to only allow apps from verified publishers, or to require admin approval for all consent requests.
Disable user consent for sensitive roles. For high-value accounts (executives, finance, IT admins), consider requiring admin approval for all third-party app consent requests.
Train users on consent prompts.Standard phishing training focuses on fake login pages. It rarely covers consent prompts. Users need to understand that clicking "Allow" on a permissions prompt grants persistent access that survives password changes.
Monitor with automated scanning. Manual review of connected apps does not scale. Regular automated scanning catches malicious apps before they have time to exfiltrate data or establish additional persistence mechanisms.
The permission you forgot you gave
OAuth consent phishing works because it exploits a mechanism people use every day. Granting app permissions is so routine that most users click through consent prompts without reading them. The attacker does not need to find a vulnerability in your email provider. They just need you to click a button you have clicked hundreds of times before.
InboxWatch scans your connected OAuth applications on every run. If a malicious app has been granted access to your email, you will see it in your next scan result, along with exactly what permissions it has and whether it affects just your account or your entire organization.
Check your connected apps for free
InboxWatch scans for rogue OAuth apps, dangerous permissions, unverified publishers, and admin consent grants. Free. 60 seconds. Metadata only.
Scan My Email Now15 free scans · No credit card · $0.10/scan after
Written by Nicholas Papadam, founder of InboxWatch. Senior Analyst with 6+ years in enterprise security operations.