A new breed of phishing attack is automating the theft of Microsoft 365 access tokens—and it works by exploiting a single, often-overlooked setting in every Entra ID tenant. Security researchers have observed the tool “ConsentFix” being used in the wild to trick users into granting broad OAuth permissions to malicious applications, sidestepping multi-factor authentication and capturing session tokens that grant full access to email, files, and even SharePoint data. The fix isn’t complicated, but it requires admins to act immediately: restrict end-user consent for application permissions at the directory level.

The attack chain is deceptively simple. An attacker registers a rogue application in Entra ID, then generates a consent link that prompts the victim to review and accept a set of requested permissions. Often disguised as a legitimate productivity app—a PDF converter, a calendar helper, or a file-sharing tool—the link arrives via a crafted phishing email or a malicious redirect. Once the user clicks “Accept,” the app receives an OAuth 2.0 token scoped to precisely those permissions. ConsentFix, a PowerShell-based tool first documented by security researcher Andrew Robbins and refined by multiple red teams, automates this process: it registers the app, requests API permissions like Mail.Read, Files.ReadWrite.All, or even more dangerous delegated scopes, then captures the resulting refresh token. From there, an attacker can silently exfiltrate email, search SharePoint libraries, or move laterally across a tenant—all without triggering traditional credential theft alerts.

How ConsentFix Weaponizes Legitimate OAuth Flows

ConsentFix functions as a post-exploitation and initial access framework. Its default template requests permissions such as offline_access, Mail.Read, User.Read, Files.Read, and Sites.Read.All—enough to siphon sensitive corporate data. It can also be customized to include Mail.Send or Files.ReadWrite.All, opening the door to business email compromise or ransomware staging. After the victim grants consent, the tool exchanges the authorization code for a refresh token that remains valid for up to 90 days by default. That token is then used to call Microsoft Graph APIs quietly from attacker-controlled servers.

What makes ConsentFix particularly dangerous is its ability to bypass multi-factor authentication. Because the user is interacting with the legitimate Microsoft consent screen, MFA prompts, if configured, are surfaced normally. A user who routinely approves app requests may not pause to scrutinize the permissions list, especially when the phish is well-crafted. Even more concerning, ConsentFix can target guest users in a multi-tenant environment, exploiting trust relationships that many organizations haven’t fully locked down.

The Misconfiguration That Opens the Door

By default, many Microsoft Entra ID tenants allow users to consent to applications from any publisher for permissions that don’t require administrator approval. This includes low-privilege permissions like signing in and reading their own profile, but it often extends to delegated permissions across Exchange, SharePoint, and Teams if the publisher is classified as “verified.” The default setting—“Allow user consent for apps”—is a time bomb. It permits users to grant applications access to their own data and, critically, data they can access on behalf of the organization. When a user consents to Sites.Read.All, the resulting token can read any SharePoint site that user can access—often hundreds or thousands of sites.

Microsoft has been gradually tightening default consent settings in newer tenants, but existing tenants and those created several years ago frequently retain the permissive default. A survey by security vendor Spera found that 67% of organizations had at least one user who granted consent to a suspicious third-party application in the past 90 days, and ConsentFix abuses thrive in this environment. Once an attacker obtains a valid refresh token, they can persist for weeks without detection, especially if logging of consent events isn’t routed to a SIEM.

Break the ConsentFix Chain Immediately

Admin action must begin by disabling end-user consent entirely—or, at minimum, restricting it to permissions from verified publishers. The quickest path is through the Microsoft Entra admin center. Navigate to Identity > Applications > Enterprise applications > Consent and permissions > User consent settings. There, you’ll find the critical toggle: “Allow user consent for apps.” Set it to “Do not allow user consent”. This single change blocks all future user consent requests, including those initiated by a ConsentFix attack. Users attempting to grant permissions will see a message that approval is required from an administrator, effectively killing the phishing chain at step one.

For organizations that still need to allow limited self-service for low-privacy-impact apps, select the middle option: “Allow user consent for apps from verified publishers, for selected permissions.” This setting forces users to only approve permissions classified by Microsoft as “low impact,” and only from publishers whose identity has been verified. Verification requires a Microsoft Partner Network account, adding a friction layer for criminals. While not foolproof—verified publisher status can be obtained fraudulently—it raises the bar significantly.

  1. Sign in to the Microsoft Entra admin center (https://entra.microsoft.com) with at least the Privileged Role Administrator role.
  2. Expand Identity and select Applications, then Enterprise applications.
  3. Under the Security section, click Consent and permissions.
  4. Choose User consent settings.
  5. Under User consent for applications, select Do not allow user consent.
  6. Click Save.

After saving, the change is effective immediately. All existing consented tokens remain valid until revoked, so the next critical step is to review and remove existing grants. In the same Consent and permissions blade, select Review permissions granted to applications. Filter by permission classification to identify high-impact grants, especially any assigned to unusual or unrecognized application names. Suspicious entries can be revoked by selecting the application and choosing Revoke consent. This operation invalidates existing refresh and access tokens, forcing the attacker to re-request consent—which will now be blocked.

Disabling user consent is the emergency brake, but a sustainable security posture requires a structured approval workflow. The admin consent workflow (found under Admin consent settings in the same console) lets users submit requests that are routed to designated reviewers. Enable it by toggling Users can request admin consent to apps they are unable to consent to. Add a group of reviewers—these can be security admins, help desk leads, or application approvers. The workflow ensures legitimate business needs aren’t permanently blocked while still closing the door to automated consent grabs.

For even finer control, organizations with Microsoft Entra ID P2 licenses can implement application consent policies. These policies let admins create conditions under which users may consent—for example, only apps published in a specific tenant, or only those that request specific permissions. A policy like “Allow user consent only for applications from the corporate tenant with permissions User.Read and offline_access” provides a tight boundary for internal tools without exposing the tenant to third-party risk.

Extend Defenses Across the Stack

Blocking front-end consent is only one layer. Mature security strategies also include:

  • Enable the Microsoft Entra ID Consent Grant Report. This pre-built workbook visualizes all consented permissions across the tenant, spotlighting high-risk categories. Find it in the Monitoring & health section of the Entra admin center under Usage & insights.
  • Integrate with Microsoft Defender for Cloud Apps. Create an app governance policy that alerts on OAuth apps requesting high-privilege permissions from unverified publishers. MDCA can also automatically revoke suspicious OAuth grants.
  • Deploy Conditional Access. While OAuth tokens are obtained via consent, you can require multi-factor authentication for all app registration changes, or block consent attempts based on risk signals. A Conditional Access policy targeting the resource "Microsoft Graph" and sign-in risk level “high” can prevent a stolen refresh token from being used, though it won’t stop the initial consent.
  • Harden publisher verification. In App registrations > Verified publisher, ensure your own apps are marked as verified. This creates a baseline of trust and allows your users to distinguish internal tools from external unknowns, should you opt for the verified-publisher consent model.
  • Monitor consent activity via Sentinel or SIEM. Forward the Entra ID audit logs (specifically the Add OAuth2PermissionGrant event) and set alerts for grants with excessive scopes, abnormal app names, or first-time publisher consent from users in high-value roles.

Real-World Impact and the Clock That’s Ticking

Organizations that have fallen prey to consent phishing often don’t realize it for weeks. In one incident, a financial services firm discovered that a consent-based attack had exfiltrated six months of executive emails before a routine audit flagged the app. The refresh token obtained via ConsentFix was still active because user consent settings allowed all apps, and nobody was reviewing consent grants. The cleanup required not only revoking the grant but also investigating which mailboxes and files had been read, scoping a breach notification, and resetting all impacted user sessions.

Security researcher Dr. Nestori Syynimaa, who first detailed the AADInternals toolkit that inspired ConsentFix, warns that the attack surface remains enormous because automation lowers the cost of abuse. “You don’t need to be a sophisticated attacker to pull this off,” he noted in a recent Defcon talk. “A single misconfiguration and a single click are all it takes.” The sole requirement is a valid Microsoft Entra ID tenant—even a free one—and a phishing lure that lands in the right inbox.

Immediately after switching user consent to “Do not allow,” you should see a drop in new OAuth grants. But don’t stop there. Conduct a full inventory of existing applications and their granted permissions. Look for:
- Apps with names resembling generic productivity tools (e.g., “PDF Converter Online”, “Calendar Helper”, “Document App”).
- Permissions including Mail.Read, Files.ReadWrite.All, or Sites.Search.All.
- Consent dates within the last 90 days.
- Apps whose publisher domain doesn’t align with the expected service (e.g., a SharePoint-related app publishing from randomcloudservice.onmicrosoft.com).

Revoke these grants and then initiate a token revocation for the affected users. The easiest way to force a full token reset is to revoke the user’s refresh tokens via PowerShell: Revoke-AzureADUserAllRefreshToken -ObjectId <user>.

Finally, launch an internal awareness campaign. Teach employees that a consent screen is the new login prompt—they must verify the app name, publisher domain, and requested permissions before clicking “Accept.” A simple rule: if you didn’t initiate the request, never grant consent.

The ConsentFix technique is not going away. As long as OAuth remains the backbone of cloud authentication, consent phishing will evolve. However, by breaking the chain at the consent setting—and layering on monitoring, governance, and user education—you transform a severe threat into a manageable risk. The configuration change takes less than two minutes. Every hour you wait is another hour an attacker could be reading your company’s email.