Why Password Resets Do Not Stop OAuth Phishing Attacks

Why password resets do not stop OAuth phishing attacks

When phishing campaigns switched from stealing passwords to stealing OAuth tokens, the standard incident response playbook became obsolete. If a user grants a malicious app access to their Microsoft 365 or Google Workspace account, changing their password afterward does not log the attacker out. The token survives the reset because it was issued at a different layer of the authentication system.

This is not a new class of attack. OAuth consent phishing has been documented since at least 2016, and practitioner reports suggest it has become more frequent recently. What has not changed is the standard containment response - and that is the problem.

This article explains how OAuth consent phishing works, why password resets are ineffective, what an attacker can do with a stolen token, and what to do instead.

What is OAuth consent phishing?

OAuth is an open standard for authorization. When you sign into a third-party app using your Microsoft or Google account, OAuth is what asks you "this app wants access to your mailbox - do you approve?" The approval grants the app a token, not your password.

Consent phishing exploits this flow. The attacker crafts an email with a link to a permission request screen. The screen is real - it is hosted by Microsoft, Google, or whichever provider the victim uses. The permission being requested is also real. The attacker is simply asking the victim to hand over access voluntarily.

This is why it is so effective: there is no fake login page, no captured password, and no second factor to intercept. The victim reads a standard permission prompt and approves it. Nobody asked them to sign into anything new.

The attack sequence step by step

1. The victim receives an email that looks routine - perhaps an invitation to view a document, a calendar request, or a notification from a trusted service.
2. The email contains a link. The link opens a legitimate permission consent screen hosted by Microsoft, Google, or another major identity provider.
3. The screen requests access to the victim"s account. The requested permissions might include reading email, sending on behalf of the user, accessing files, or managing contacts.
4. The victim approves. The identity provider issues a token to the attacker"s app.
5. The attacker redeems the token. They now have programmatic access to the victim"s account as long as the token or refresh token remains valid.
6. The organization detects the compromise. The incident response runbook says "force password reset."
7. The victim changes their password. The attacker"s token remains active.
8. The attacker continues accessing the account. Nothing has been revoked.

What can an attacker do with an OAuth token?

A valid OAuth token gives the attacker the specific permissions the victim approved. In practice, this often means:

• Reading incoming and outgoing email
• Sending email from the compromised account
• Accessing files stored in connected cloud services
• Reading contact lists to fuel further phishing attempts
• Acting on behalf of the user in any integrated third-party apps

The attacker does not have the password. They cannot authenticate as the user directly. But the token grants most of the same capabilities, and it persists independently of the password.

Why password resets do not revoke OAuth grants

OAuth tokens and passwords live on separate planes. When you change your password, the authentication layer is updated. OAuth grants exist at the authorization layer - above authentication - and are not tied to the password.

Think of it like a gym membership. If you cancel your credit card, the gym does not automatically cancel your membership. You authorized the gym directly, and only a specific revocation to the gym revokes the access. OAuth grants work the same way.

To revoke an OAuth token, you must revoke it at the authorization layer - in the account"s connected apps or app settings. A password change does not touch that layer.

How to revoke OAuth app access properly

Microsoft 365 / Entra ID:

1. Log into myaccount.microsoft.com
2. Go to Privacy -> Connected apps
3. Find the suspicious or unfamiliar app
4. Click Revoke permissions
5. Check for additional unauthorized apps - attackers often request multiple tokens at once

Alternatively, use the Entra Admin Center:
1. Go to Protection -> Identity -> Enterprise applications -> Consent and permissions
2. Review user consent requests
3. Remove unfamiliar or unapproved app registrations

Google Workspace:

1. Go to myaccount.google.com
2. Select Third-party apps with account access
3. Find the app and select Remove access
4. Check for additional unexpected apps - as with Microsoft, attackers often request multiple scopes in a single consent prompt

After revoking access, check the audit log for any actions the attacker may have taken while the token was active.

How to detect OAuth consent phishing

Detection before revocation is preferable to detection after. Look for these signals:

• Unexpected consent events in the Unified Audit Log (Microsoft) or Admin console audit log (Google)
• New third-party app registrations that were not initiated by IT
• Mail forwarding rules added without a corresponding IT ticket
• Sign-in activity from unexpected geographic locations shortly after a consent event
• Unusual inbox rules such as automatic forwarding or deletion of specific messages

Microsoft Sentinel and Defender for Office 365 can be configured to alert on consent grant events for non-gallery applications. Google Workspace admins can enable alerts for new third-party app authorizations.

OAuth phishing is also an email authentication problem at scale. When attackers compromise a legitimate user"s account this way, they can send email that passes DMARC alignment checks - because it originates from an authenticated source within your own domain. This means a compromised OAuth account can be used to bypass your existing email authentication controls, making DMARC reports harder to interpret during an incident.

That is where DMARCFlow fits: it monitors your authentication baseline across SPF, DKIM, and DMARC, so you can spot when the pattern of authenticated senders from your domain changes unexpectedly. If your DMARC reports suddenly show new sending sources or unusual volume from a specific account, that is a signal worth investigating - even if the messages themselves are DMARC-aligned. DMARCFlow cannot detect the OAuth consent event directly, but it can surface the email authentication anomalies that follow when a compromised account is used to send at scale.

What belongs in an incident response runbook for OAuth phishing

Standard runbooks that include only password reset as a containment step are incomplete. An updated runbook should include:

1. Identify all active OAuth grants for the affected account
2. Revoke all unfamiliar or unauthorized OAuth grants immediately
3. Review and remove any mail forwarding rules or inbox rules created since the compromise window
4. Check your email authentication baseline for anomalous sending patterns
5. Check the audit log for activity during the compromise window
6. Rotate any application secrets or API keys that may have been exposed
7. Notify security stakeholders - the attacker may have accessed data beyond email
8. Review other users who may have received similar phishing invitations

FAQ

Does changing my password revoke OAuth app access?

No. Password changes and OAuth grants operate on separate layers of the authentication system. Revoking OAuth access must be done through the account"s connected apps or enterprise application settings.

What is the difference between OAuth phishing and credential phishing?

Credential phishing captures a password directly - typically through a fake login page. OAuth phishing tricks a user into granting an attacker-controlled application access to their account. The victim provides credentials to the legitimate identity provider, not to the attacker.

How do I see which OAuth apps have access to my Microsoft 365 account?

Go to myaccount.microsoft.com -> Privacy -> Connected apps. You will see every third-party app with active access to your account and the specific permissions each app holds.

Can DMARCFlow detect OAuth phishing attacks?

No. DMARCFlow monitors email authentication records (SPF, DKIM, DMARC) and cannot detect OAuth consent events directly. However, it can surface email authentication anomalies that occur when a compromised account is used to send DMARC-aligned email through your infrastructure - giving your team a signal that something in your email sending patterns has changed.

What should an incident response runbook include for OAuth phishing?

At minimum: revoke OAuth grants directly, remove mail forwarding rules, check your email authentication baseline for anomalies, check audit logs for activity during the compromise window, and rotate any exposed secrets. Password reset alone is insufficient.