OAuth consent phishing tricks a user into approving a malicious application on a genuine Microsoft consent screen. The app receives its own tokens and can read mail, files, and contacts independently of the user's session. MFA never intervenes, because the user is already authenticated when they consent, and resetting their password does not remove the grant. inforcer TDR detects these grants across every managed tenant and handles the full remediation from one platform.
|
Time to Read |
|
|
What You’ll Learn |
|
|
Next Steps |
|
Most phishing attacks are trying to take something from the user, like a set of credentials or a session token. OAuth consent phishing works differently. It asks the user for permission, and then waits for them to say yes.
The request arrives on a genuine Microsoft page, at a genuine Microsoft address, and it looks very much like the permission prompts that users already approve for legitimate business software. But once they approve it, an application controlled by an attacker holds standing access to their mailbox, files, and contacts. And that access continues to work even after the password is changed.
For MSPs, this is a difficult attack to get ahead of, because nothing about it looks broken from the outside. There is no compromised credential to reset, no failed MFA challenge in the logs, and no unfamiliar sign-in to investigate.
Read on to learn how OAuth consent phishing works, why MFA offers no protection against it, how it differs from session token theft attacks, and what MSPs can do to detect and respond to threats like this across a multi-tenant estate.
The mechanism that every OAuth consent attack abuses is completely legitimate. In fact, most MSPs see it working correctly dozens of times a week.
Business software constantly needs access to data held in other systems. Scheduling tools need to read calendars and CRMs need to send email on a salesperson's behalf.
In the early days of the web, the only way to arrange this was for the user to provide their username and password directly to the third-party product, which would then sign in on their behalf. But this made their login credentials less secure, and it stopped working entirely once MFA became standard.
OAuth 2.0 was designed to solve that problem. Rather than giving an application their credentials, the same user could simply authorize that application to act on their behalf within approved limits. In most Microsoft 365 tenants, that process works like this:
These are called scopes, and they are specific:
An app declares which scopes it needs, and it can only ever request them, never assign them to itself.
This is a page hosted by Microsoft, on a Microsoft domain, listing the permissions the application is asking for and the name of the publisher requesting them. It is the same screen users see when they connect any legitimate third-party tool to their account.
Depending on how the tenant is configured, a standard user may be able to approve permissions for themselves, or the request may be routed to an administrator. By default, Microsoft allows users to consent to apps requesting a limited set of permissions on their own behalf.
Approving an app creates an object in Entra ID called an enterprise application, along with a consent grant recording exactly what was approved and by whom. That grant is a standing permission, so it stays in place until someone explicitly revokes it.
Microsoft issues the app an access token, which is used to call the Microsoft Graph API and retrieve data, and a refresh token, which the app uses to obtain new access tokens as the old ones expire. These tokens belong to the application. They are separate from anything issued to the user's browser.
The kind of attack that takes advantage of OAuth consent has five stages.
There is one more distinction worth understanding, because it determines how much damage an attack can do. Delegated permissions let an app act on behalf of a specific signed-in user, and limit it to data that user can already reach. Application permissions let an app act on its own across the entire tenant, and always require administrator approval. Consent phishing campaigns overwhelmingly target delegated permissions, because a standard user can approve them without involving anyone else.
None of the above is a flaw in the way the tenant is managed. The authorization system is working exactly as designed. The attack simply tricks a user into authorizing the wrong application.
MFA only answers one question: is the person signing in genuinely who they claim to be? In an OAuth consent attack, the answer is yes.
The user really is the account holder. They really did sign in to Microsoft. They may well have completed an MFA challenge moments earlier as part of that sign-in, and it would have succeeded, because there was nothing wrong with it. The consent prompt then appears as a separate step afterwards, and approving it is a decision the authenticated user is entitled to make.
There is no second challenge at the point of consent, because from Microsoft's perspective nothing suspicious has happened. A verified user has granted permissions to an application. That is a supported action, performed correctly, by the right person.
Learn More: Mastering Microsoft 365 Security: Standard MFA vs. Conditional Access
The application's access does not depend on the user's session in any way. Once the grant exists, the app holds its own refresh token and can request new access tokens on its own schedule, whether or not the user is signed in, working, or even still employed.
This is why identity-based incident response often misses these attacks. Resetting the user's password does not remove the grant. Neither does re-registering their MFA method. The consent grant is a separate object within the tenant, and it stays in place until an administrator explicitly revokes it and removes the enterprise application. An MSP can secure the account completely and leave the attacker's access entirely intact.
These attacks do leave traces, but they appear in places most MSPs are not routinely watching.
As with session token theft, these signals mean far more together than separately. Businesses adopt new software all the time, and standard users grant consent for legitimate reasons every week. What identifies an attack is the combination: an unfamiliar app, granted permissions out of proportion to its purpose, by a user who does not normally approve software, followed by API activity that does not resemble anything a person would do.
In principle, an MSP could catch this by reviewing tenants manually. But in practice, consider what that involves.
For each managed tenant, someone would need to open the enterprise applications list in Entra ID and identify anything new since the last review. They would then need to examine each new app's requested permissions, check the publisher, look up who granted consent and when in the audit logs, and decide whether the app is legitimate. Anything ambiguous requires further investigation into what the app has actually been doing through the Graph API activity logs.
That is already a full-time job for one tenant. Three factors make it practically impossible for MSPs managing multiple tenants at once:
OAuth consent phishing and Adversary-in-The-Middle (AiTM) attacks are both intended to bypass MFA and let the attacker inside a Microsoft 365 tenant, which is why they are often discussed together. But they target different parts of the identity system and they require different responses.
The distinction is between authentication and authorization. Authentication is the process of proving who you are, which is what happens when you sign in and complete an MFA challenge. Authorization is the process of determining what you, or something acting on your behalf, is permitted to do once that identity has been established.
Adversary-in-the-Middle attacks target authentication. A reverse-proxy server sits between the user and the real Microsoft login page during sign-in, relays the credentials and MFA challenge in real time, then copies the session token that Microsoft issues once authentication succeeds. We covered how this works in detail in our previous article: MFA Token Theft: New Risks & Responses.
OAuth consent phishing does not interfere with authentication at all. It lets the user authenticate perfectly, then targets authorization by obtaining a legitimate grant for an application that should never have had one.
|
OAuth consent phishing |
Adversary-in-the-Middle |
|
|
Layer targeted |
Authorization |
Authentication |
|
Primary goal |
Register and authorize a persistent malicious application |
Steal an active user session cookie or token |
|
Involves a fake login page? |
No. Uses the real consent screen on a legitimate Microsoft domain |
Yes. Traffic is routed through an intercepting reverse proxy |
|
How MFA is bypassed |
Never challenged at the app layer, because the user is already authenticated when they consent |
Bypassed after the fact, by stealing the token issued once MFA succeeds |
|
What the attacker holds |
The application's own access and refresh tokens, issued directly to it |
The user's session cookie, copied in transit |
|
Scope of access |
Limited strictly to the permissions the user approved |
Mirrors everything the compromised user account can reach |
|
How long access lasts |
Until the grant is explicitly revoked |
Until the hijacked session expires or is revoked |
|
What shuts it down |
Revoking the consent grant and removing the enterprise application |
Revoking the session, with conditional access preventing replay |
The practical implication for MSPs is that the two attacks require different remediation efforts. Revoking sessions and resetting credentials will end an AiTM attack, but will leave a malicious application from an OAuth consent attack running. Ending an OAuth consent attack requires the removal of the application as well.
inforcer TDR is the threat detection and response software our team built to complement our multi-tenant management platform, which is rebranding to 365 Manager. MSPs can use it to monitor every managed tenant for signs of an attack and correlate them using deep Microsoft telemetry, which helps separate genuine attacks from everyday events and reduce false positive alerts caused by normal business activity.
An MSP using inforcer TDR to protect tenants against OAuth consent attacks can place permissions granted to applications in context alongside the way those applications behave to identify patterns of behaviour likely associated with threat actors.
But detection alone is not enough, because remediating this attack properly means completing several distinct actions in the right order. inforcer TDR closes that gap by allowing an MSP to handle the entire response from the same platform:
inforcer TDR is also designed to support our existing multi-tenant management platform by allowing MSPs to instantly remediate the policies or configurations that allowed a given breach to take place.
Here's an example:
Learn More: Why We Built inforcer Threat Detection and Response
OAuth consent phishing is difficult to defend against precisely because it does not break anything. The user authenticates correctly, Microsoft behaves correctly, the consent screen is real, and the resulting grant is a normal object in the tenant. There is no alarm to respond to, and the standard credential reset that resolves most account compromises does nothing at all.
The practical answer is to stop treating enterprise applications as background noise. That means continuous visibility into which applications exist across every managed tenant and what they are permitted to do, the ability to revoke a grant everywhere it appears rather than one tenant at a time, and consent settings that keep users from approving software on the business's behalf in the first place. Pairing 365 Manager with inforcer TDR covers all three.
OAuth consent phishing is an attack that tricks a user into granting a malicious application permission to access their cloud data. The user approves the request on a genuine Microsoft consent screen, which creates an enterprise application and consent grant in the tenant. The application then receives its own access and refresh tokens, allowing it to read mail, files, and contacts through the Microsoft Graph API.
MFA verifies that the person signing in is who they claim to be, and in an OAuth consent attack that verification succeeds legitimately. The user really is the account holder and really did sign in to Microsoft. The consent prompt appears as a separate step after authentication, and approving an application is an action an authenticated user is entitled to take, so no second challenge is issued.
No. The consent grant is a separate object in the tenant and does not depend on the user's session or credentials. The application holds its own refresh token and can request new access tokens whether or not the user is signed in. Removing the access requires an administrator to revoke the consent grant and remove the enterprise application.
OAuth consent phishing targets the authorization layer, while Adversary-in-the-Middle phishing targets the authentication layer. An AiTM attack proxies the real login page and steals the session token issued after MFA succeeds, giving the attacker access for as long as that session remains valid. OAuth consent phishing involves no fake login page and no stolen token, and the access persists until the grant is explicitly revoked.
The clearest indicator is an enterprise application in Entra ID that nobody at the business recognizes or requested. Other signals include permissions disproportionate to what the app claims to do, consent granted by a standard user rather than an administrator, an unverified publisher or an unfamiliar reply URL, and unusual Microsoft Graph API activity such as bulk mailbox reads or mass file enumeration.
The most effective control is restricting user consent so standard users cannot approve applications on the business's behalf, and enabling the admin consent workflow so requests are reviewed instead. Alongside this, MSPs need continuous visibility into which applications exist in every managed tenant and what permissions they hold, since campaigns are typically run against many organizations at once.