OAuth Phishing via First-Party Microsoft Apps

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.

Once the user consents to a malicious or abused OAuth flow using a first-party Microsoft app, the attacker receives a refresh token. This token can be used to request access tokens for other Microsoft services the app is authorised to access — including Exchange Online, SharePoint, Teams, and OneDrive.

If the attacker leverages FOCI, they may be able to use the refresh token from one first-party app to obtain access tokens for other FOCI-eligible apps, significantly broadening their access. All of this activity can appear in logs as normal, legitimate application access by the user — making it very difficult to detect after the fact.

The attacker can read emails, access files, enumerate the directory, and use the access for reconnaissance or lateral movement, all while the user remains unaware their account is compromised.

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