OAuth phishing — sometimes called illicit consent grant attacks — tricks users into authorising malicious or abused applications to access their Microsoft 365 data. Unlike credential phishing which steals passwords, OAuth phishing captures a persistent access token that grants the attacker ongoing access to the user's account without needing their credentials or bypassing MFA.

First-party Microsoft applications are particularly dangerous in this context because they are trusted by default in most tenants and are less likely to trigger security warnings during the consent flow. Attackers can abuse the Family of Client IDs (FOCI) mechanism — a feature in the Microsoft identity platform that allows certain first-party apps to share refresh tokens — to escalate from a low-privilege app consent to broader access across multiple Microsoft services.

This technique allows attackers to maintain persistent access that survives password resets, because the OAuth token is independent of the user's credentials.

• User directed to a legitimate-looking OAuth consent page via phishing link and authorises a malicious or abused application
• Attacker receives a refresh token granting persistent access to the user’s account, entirely independent of their password or MFA
• Using FOCI (Family of Client IDs), attacker escalates from a low-privilege app token to access tokens for other Microsoft services the user is authenticated to
• All activity appears in logs as normal application access by the user — distinguishing it from legitimate app use requires specific analysis of the consent event
• Persistent access survives a password reset because the OAuth token is not invalidated when credentials change unless the app consent is explicitly revoked
• Attacker reads emails, accesses files, enumerates the directory, and conducts reconnaissance while appearing as a legitimate app accessing a legitimate user’s data
• Bulk consent phishing campaign targeting multiple users creates multiple simultaneous access channels from a single operation
• Admin consent grant abused to apply the same broad permission set across the entire tenant, giving attacker access to all users’ data from a single event

OAuth consent flows using first-party Microsoft apps are routine in normal M365 usage. Legitimate scenarios include:

• Users consenting to Microsoft Teams, Outlook, OneDrive, or other Microsoft apps accessing their account data
• IT-deployed enterprise applications using Microsoft Graph permissions for legitimate automation or integration tasks
• Third-party tools that use Microsoft's OAuth infrastructure for authentication (e.g., Slack, Zoom, or other M365-integrated products)

The alert becomes suspicious when: the consent was triggered by an unusual OAuth redirect URI, the application involved is not one the user would typically interact with, the consent grant happened outside business hours or from an unusual location, or the application requests permissions significantly broader than its stated purpose.

• In Entra ID > Enterprise Applications, locate the application involved and review its permissions, publisher, and consent history
• Check the redirect URI used in the OAuth flow — legitimate Microsoft apps use known Microsoft-owned domains; unusual redirect URIs are a red flag
• Review the sign-in logs for the affected user around the time of the consent grant — look for associated phishing email delivery or suspicious link clicks
• Check whether the application has been granted permissions that allow reading email, accessing files, or enumerating the directory
• Search Entra ID audit logs for other users who may have consented to the same application — OAuth phishing campaigns typically target multiple users simultaneously
• If the app is publisher-verified and well-known, confirm the consent request came from a legitimate source (e.g., the user navigated to the app directly rather than via a phishing link)

1. Revoke the OAuth consent grant for the affected application in Entra ID > Enterprise Applications > select app > Permissions > revoke grants for the affected user
2. Revoke all active sessions for the affected user and reset their credentials as a precaution
3. Review the user's mailbox, OneDrive, and SharePoint activity during the period the malicious token was active to assess what data may have been accessed
4. Search for other users in the tenant who may have consented to the same application and remediate their access as well
5. If the application was granted tenant-wide admin consent, revoke the enterprise application entirely and review how that consent was granted
6. Enable the admin consent workflow in Entra ID to require administrator approval before users can consent to third-party applications — this prevents future illicit consent grants
7. Consider restricting user consent to verified publisher applications only, or disabling user consent entirely and centralising it through the admin consent workflow

Overe Auto-Response: The OAuth Phishing via First-Party Microsoft Application alert can be configured in Overe to trigger automatic session revocation or account block when suspicious OAuth activity is detected. Review your Auto-Response settings under Org Config > Auto-Response to ensure an appropriate automated response is configured.

Microsoft: Configure how users consent to applications

Microsoft: App consent grant investigation playbook

Microsoft: Configure the admin consent workflow

After investigating an OAuth phishing alert, review these related risk areas:

• Apps with Risky Permissions — review all applications with broad Graph API permissions that may have been consented to by users
• Apps with Admin Roles — check whether the affected application was granted admin-level permissions
• Phishing URL Clicked — OAuth phishing flows typically begin with a phishing link; check for related URL click alerts
• Session Hijack via Unusual IP Change — if the OAuth token was used from an unusual location, session anomalies may be visible
• Dormant Apps — after revoking the malicious consent, verify there are no other dormant applications with similar permissions in the tenant