The attack is deceptively simple. A user clicks "Allow", and it's done. No password stolen. No MFA prompt triggered. No conditional access policy bypassed through brute force. The attacker simply asked the victim to open the door, and the victim did, believing they were installing a productivity tool. This is an illicit consent grant attack, and it remains one of the most underestimated intrusion techniques in Microsoft 365 environments.
How OAuth abuse works in Microsoft 365
OAuth 2.0 is the protocol that allows a third-party application to act on behalf of a user without that user ever handing over their credentials. Legitimately, this is what lets a project management tool access your Outlook calendar or OneDrive. The protocol itself is not the vulnerability. The vulnerability is the consent policy: by default, Microsoft 365 allows any user to approve a third-party application requesting permissions over their data.
An attacker registers an application in Azure AD (or in a tenant they control), gives it a reassuring name, configures the desired permission scopes, then sends a crafted OAuth consent link to their target, typically via phishing. When the user clicks and approves, the application receives a valid OAuth access token, often paired with a long-lived refresh token. That token grants access to emails, files, contacts, and calendar data, depending on the scopes requested, with no further authentication required from anyone.
The permission scopes that cause the most damage
The impact depends entirely on what scopes were requested. The most dangerous in this scenario are Mail.Read, Mail.ReadWrite, Files.ReadWrite.All, and offline_access. That last one is particularly harmful: it allows the application to refresh its tokens indefinitely, creating persistent access that survives password resets and MFA session revocations.
Why MFA does not protect against this attack
This is the point most IT teams miss. MFA protects the user's authentication step. It does not protect the tokens that applications accumulate after consent is granted. Once a valid OAuth token has been issued, the attacker uses it directly against the Microsoft Graph API. There is no login page involved, so MFA simply never enters the picture. Even if the victim changes their password the next day, those tokens remain valid until they expire or are explicitly revoked.
For SOC teams, this means that alert rules built around suspicious login attempts will see nothing. The attacker operates through a legitimate application session, using a valid token, calling perfectly normal Graph endpoints. The traffic looks like any other SaaS integration.
Consent policies to restrict first
The primary defense is removing the ability for end users to approve applications on their own. In the Azure AD portal, under Enterprise Applications > Consent and permissions, the user consent policy should be set to disallow user consent entirely, centralizing all approvals through an admin consent workflow. That workflow routes application requests to a designated administrator before any permission is granted.
The next step is auditing what has already been consented. Most organizations discover dozens of third-party applications approved by users over the years during this audit, some of which no longer exist or have changed ownership. The PowerShell combination of Get-AzureADServicePrincipal and Get-AzureADOAuth2PermissionGrant extracts this list efficiently. The Entra ID portal also provides a graphical view of enterprise applications filtered by consent type for teams who prefer a dashboard approach.
Classifying applications by risk level
Not all third-party applications carry the same risk. A solid policy distinguishes between applications published by Microsoft-verified publishers (Publisher Verified badge) and unverified ones. Unverified applications deserve far greater scrutiny, or outright blocking by default. The permissionGrantPoliciesAssigned setting within consent policies allows building exactly this kind of granular control.
Detecting abuse through Microsoft Purview audit logs
Microsoft Purview centralizes audit logs across Microsoft 365 workloads. To detect an illicit consent grant, the key events to monitor are Consent to application and Add OAuth2PermissionGrant in the unified audit log. Any consent granted by a standard user to an application not listed in your internal approved catalog should trigger an immediate alert.
KQL queries in Microsoft Sentinel can automate this detection. The pattern to hunt for: a user consenting to an application for the first time, during unusual hours, from an IP address outside the organization's expected geolocation. Building and validating these detection scenarios for abnormal cloud identity access is exactly the kind of work SOC teams should be doing in a controlled lab before facing a real incident.
Monitoring post-consent activity
Detection cannot stop at the moment of consent. Once an application is approved, activity through Microsoft Graph generates records under Azure AD's Service Principal Sign-ins logs. Bulk email access via Graph, particularly outside business hours, is a strong signal. Correlating those API calls with unusual SharePoint or OneDrive download activity through Purview audit logs completes the picture.
What Red Teams test and Blue Teams should anticipate
Offensive teams use frameworks like GraphRunner or custom Python scripts built on top of MSAL to simulate exactly this attack chain in test environments. The full flow — registering a fake application, sending the consent link, using the token to exfiltrate emails — can be completed in under an hour on a test tenant. If your team has never run this scenario against your own detection stack, you genuinely do not know whether your alerts would fire. Practicing this kind of exercise through a dedicated cloud identity attack lab in an isolated environment is the only way to validate your defenses without putting production systems at risk.
The good news is that this attack does leave traces. The consent event is logged. Graph activity is logged. Refresh tokens have a configurable lifetime. The challenge is not a lack of data. It is the absence of policies that restrict what users can consent to, and the absence of detection rules that turn that data into actionable alerts.
Frequently asked questions
Can a user revoke consent they already granted to an OAuth application?
Yes. Through the myapps.microsoft.com portal, users can view and revoke applications they have authorized. However, this self-service option is rarely known to end users, and revocation does not guarantee immediate invalidation of access tokens the attacker may have already cached or used to generate downstream sessions.
Does restricting consent to admins-only break existing tools?
Not for tools already approved. Applications that were consented before the policy change continue to function normally. Only new consent requests get routed to an administrator. The operational impact is limited, provided you set up a clear process for handling incoming requests so you do not create a bottleneck that frustrates legitimate tool adoption.
Does MFA actually stop illicit consent grant attacks?
No. That is precisely what makes this technique effective. It exploits OAuth to obtain access without going through interactive authentication at all. MFA protects the user's login. It does not protect the tokens issued to third-party applications after the user has consented, regardless of how strong the authentication method is.
Which logs should be enabled first to detect these attacks in Microsoft 365?
The two highest-priority sources are the unified audit log in Microsoft Purview, specifically filtering for Consent to application and Add OAuth2PermissionGrant events, and the Azure AD Service Principal Sign-in logs. Without both of these sources active and forwarded to a SIEM or Sentinel, post-incident investigation becomes extremely difficult and real-time detection is essentially impossible.